The ideal scenario would be to recompile on the new platform without changing a line of code - will this type of portability be possible?
It certainly is possible, though you'll almost certainly want to have separate Makefiles for the two platforms. You also have to either use ifdefs, platform specific static libraries, or platform specific shared libraries/dlls.
My one suggestion is that you at the least compile on both platforms early and often. I say at the least, because you'd be better off doing at least some unit testing and QA on both platforms. You will run into problems if you don't, and you probably will run into problems even if you do. This is even true in java, trust me, I know from experience that some platforms are going to have bugs even if you do everything by the book. And other times you'll notice bugs in one platform that are bugs in the other platform, but just don't show up in your tests.
Hmm, I find that quite interesting. I am currently writing a linux program in GTK+. I downloaded the source code into Windows, compiled, ran, and... it crashed...
Then I changed two places where I was calling free(), and changed it to g_free(). Recompiled, and the app runs perfectly on Windows and Linux.
Yes, a network connection is usually slower than your hard drive. Video definately is not.
Video may be faster, but it is commonly the bottleneck. Just as a slow network doesn't always slow down a hard drive, a slow hard drive doesn't always slow down a video card. In the case of gaming, everything is typically already stored in ram and disk accesses are a minimal. The bottleneck, if any, is the video card and/or the CPU (and/or the ram/cache, though I doubt it).
As for hard drives, an OS like Win2k can easially take up half of your 1Gig of memory, but even with an infinite ammount of RAM, it still does have to write to the disk soon after, which usually conflicts with the next portion of data your are trying to read from the disk...
Well, as for Win2k, I know very little about it. I'm considering a unix system here. As I said, disk writes are generally asynchronous, which are not a bottleneck. You write it to the buffer cache, and go on your merry way. Eventually, when there's time, you get it to disk. Even with synchronous writes there is little to no advantage from most SCSI drives in today's day and age, since they are written directly to the journal, which has no fragmentation and generally requires no seek time. Unless you're writing more data than can be handled by the disk (in which case you should be using RAID anyway), you're not going to have a bottleneck there.
I'm a professional, you aren't going to just convince me that hard drives aren't a bottleneck in almost every single aspect of PCs. It's something I know, and anyone that uses a computer could deduce the same quite easially.
And I've been a kernel programmer on the performance team for an operating system company, so I don't have to deduce shit, I've seen the bottlenecks. Unless you need massive amounts of storage accessible on a single CPU (tremendously high volume databases which can't be broken out into multiple machines), or massive data transfer rates (the only thing I can think of is live video processing), you can do the same or better with IDE.
My claim was never that SCSI was cheaper than IDE, just that it is comparable in price if you match feature for feature (and it is cheaper in many circumstances).
My claim is that for 99% of the SCSI applications in use today, there is an equivalently performing system that can be built for a lower cost, using IDE. The drives themselves may not have the exact same features, but the application will perform as well or better.
Somehow, I think you're just going to go on in your current mindset of wanting only the interfaces Intel gives you, and not acknowledge that SCSI is better.
I'll acknowledge that SCSI is better. But so is a 600 Mhz computer better than a 500 Mhz computer. But if the 500 Mhz computer costs $500 and the 600 Mhz computer costs $2000, for 99% of the applications out there you're better off buying two 500 Mhz computers than one 600Mhz one. Oddly enough two exceptions would be the same two as I presented for SCSI vs. IDE.
After you design hardware, you've also got to have it built, and if you're earning enough to be able to pay that out of your own pocket, you won't have the spare time to design your own laptop...
I guess I implied that it was the same amount of work to build the two. What I was more getting at is that one isn't intrinsicly more difficult to understand than the other. Hardware is more expensive, but if you have the money for the parts it's just as simple as software. Woz may have spent more money than Linus, but I'm fairly certain they each could have done the other's job if they were interested in it.
I'm not sure "no longer" is true, but it's certainly true that engineering schools are not teaching the real-world aspects of getting from a schematic to working hardware.
I say "no longer" because I am under the impression that at one time there essentially was no software. Programming was done with a trusty soldering iron, and whatever you programmed was there pretty much forever.
Perhaps we'll see the same thing with regard to low level programming languages, like C. We already are seeing it to a small extent with assembly. Personally I like to know what's going on from the top to the bottom before I write anything, but I certainly do see the benefit in not teaching all the details of the hardware to someone who's never going to see anything other than Visual Basic.
Re:Already discussed stupid hd buses w/ ATA133 sto
on
Firewire and Linux?
·
· Score: 1
He isn't saying that Firewire is bad for storage, rather that it is, at the moment, overkill for this application and that USB is good enough, cheaper, and better supported under Linux. In the original question, aozilla specifically says that speed is not an issue, which is the only advantage I can see Firewire has over USB in this application.
Makes me wish I had rephrased the question. I mentioned that speed is not a big issue to try to get rid of the "go with SCSI" crowd. USB 1.1 would be out of the question, however USB 2.0 is getting a good look now. I guess I must have missed the big USB 2.0 revolution, because every time I read "USB hard drive" I read "900Kb/sec transfer limit". I'm looking for something at least close to the speed and cost I'm getting now with IDE.
After reading the answers to my question (thank you very much everyone), I've pretty much decided that firewire would be preferable to yet another IDE (is it ATA) drive. I haven't yet looked into USB 2.0, but I'm guessing that decision is going to come down to which one would I rather have 2, 3 years down the road.
Sounds good to me. I've had zero problems with my 5400, considering the drive is mainly just there for mp3s, rpms, isos, backups, and when I shut the computer off at night, wiping out my half gig of ram. And once I get the firewire drives up and running I'll probably be making a server to stick in the closet or basement and not have to deal with the shutting down at night part anyway.
Spending some karma to get this Score:0 post looked at. Mod the parent up.
Ob on topic section: The mobile racks are absolutely wonderful. I use them all the time to move drives around. One problem in addition to them not being hotswappable is that you have to change the master and slave setting by opening up the drawer if you need a different setting in the two different locations. Another reason it would be great to have a firewire mobile rack.
It's too bad that the price gap between SCSI and IDE drives has widenned so much, because they are essentially the same drives with slightly different electronics.
Presumably it's the economies of scale that are causing this one. Apple may have a niche market, but it's a fairly large niche. The SCSI market is still primarily for servers.
I am aware that SCSI has all I was looking for, but the price is simply not something I can handle (especially for external drives, which is what I'm really looking for).
Re:Already discussed stupid hd buses w/ ATA133 sto
on
Firewire and Linux?
·
· Score: 1
(and the ability to add more than 3 HDs at all, besides my CD-rom).
Actually, now that I think about it, that's probably one of the biggest issues. Right now I have 4 old hard drives laying around, just because it's not worth the trouble hooking them up for the 2-8 gigs I'll get out of them. Who knows that in 2 years I won't be saying the same thing about my 40 or 80 gig drives.
So for say 3 80 gig HDs for random access, what would be the performance of IDE vs. USB 2.0 vs. Firewire, assuming the same 5400 RPM IDE drive as the actual drive? This is pretty much the scenario I'm looking at, though I can only afford to replace my one IDE drive at the moment.
Re:Already discussed stupid hd buses w/ ATA133 sto
on
Firewire and Linux?
·
· Score: 3, Insightful
I think firewire is cool as hell, but not for this application. It's got bandwidth galore, to move video data back and forth, but this doesn't translate to "bandwidth galore for storage".
Why not? Are the seek times more? What are the practical problems with firewire vs. IDE?
Hot plugability is an issue? How many times will you actually use this?
Four times a day, Monday through Friday, at the very least. Sharing with 2 PCs... I'd also use it for backup purposes if it really worked well. Why bother with tape backups when I can spend $200 and back up 80 gigs?
If speed isn't an issue, what's wrong with IDE?
As I said, hot swappability, and the ability to add more than two devices without a significant speed detriment (and the ability to add more than 3 HDs at all, besides my CD-rom).
Another advantage is that I won't have to spend 2 hours installing the drives in my parents' computers when I give the old drives to them and buy new ones.
Or even external scsi? A decent scsi card, and external drive are no more expensive than the 1384 drives I've seen. There are plenty of dumb/slow/external drive solutions, and in every case they're cheaper than firewire.
My rough estimate would be $250x3 for 3 80 gig drives, plus $100 for the 1384 card. What hot swappable reasonably fast (no tape drives) solution do you know of for $850 for 240 gigs?
There's a considerable difference between rolling your own software and rolling your own hardware.
Only because we're no longer taught hardware as well as we're taught software. Woz was a smart guy, but he wasn't any more brilliant than the top software designers out there.
Err... what? I see this technology as wonderful. By deferring the censorship process until all material is in the hands of the consumer, you're creating a system that allows people to still sanitize what they want to sanitize without corrupting the purity of the film that's on the DVD the consumer gets.
If any of the versions of the DVD are rated R, you still can't rent it if you're under 18. I'm sure if any of the versions of the DVD are rated NC-17, Blockbuster will continue to not carry it.
Remember that editting and censorship already exist. Before now, such editting and censorship would entail releasing a version of the film with those edits permanently applied. If this technology gains wide-spread acceptance, that will no longer be the case.
For the reasons I give above, I believe that still will be the case. At best (worst) you'll have a special CSS key to unlock the R rated stuff, which will pretty much lock out anyone who doesn't have the latest (non-cracked) version of the players.
The top 1,000 Web sites agree that everyone will switch over to a penny per page on a specific date under a unified system.
Can you say "anti-trust"?
The sites need to work together. If some sites switch and others don't, you will get the same problem that happens now when a site decides to unilaterally charge for its content. If there is not a uniform and super-simple billing model (so that users get one simple, easy-to-understand bill), the thing just won't work.
Yes, it's called collusion. Of course a cartel is going to have artificially raised prices, this is precisely why such a thing is illegal.
What if all the gas stations in your state decided to raise gas prices to $2 a gallon? They'd make a hell of a lot of money, is what would happen, and then the owners would go to jail.
Perhaps so, but you are leaving quality and value out of the equation. I hit about 200 Google pages per day and I would gladly pay 2.00 USD for that service if Google agreed to maintain the same level of quality they have today.
Quality is partially where the patents come in. But if Google started charging a penny a page, and people actually paid it, I'd start making an alternative to Google just so I could charge $0.005 a page (and make $150 million/year). I'm sure others would do the same, and two of us are bound to eventually come up with equal or better quality to google. It would only take two search engines of equal quality to Google to drive the prices down to the actual cost of the less efficient one. That's microeconomics.
I agree with you that Google is the best search engine, today, but that's only because no one has any incentive to compete and undercut them (since they're already making near minimal profits). That and the patent, which IMHO isn't too hard to get around and still have quality.
Yes, directors voluntarily choose to destroy their movies for the sake of the censors, but there still is pressure put on them from the studios. While I don't have a particular problem with this technology (it's technology, therefore it's morally neutral), I do see this as a negative for the film industry. This is especially true for films where the director (or some other single visionary) doesn't have the final say on post-production. I think of "Eyes Wide Shut", a film which was bastardized in large part by Blockbuster and the major movie theatres which refuse to show NC-17 films.
Again, it's technology, it's voluntary, so there's not much you can do about it, but it's by no means a positive thing.
Google.com gets about 100 million page impressions per day right now. With a penny per page, Google would make $1 million a day, or something like $350 million per year.
Umm, no, sorry, that's not how it works. With a penny per page, Google would make $1 a day, or something like $350 per year, because people would use alternatives. Anyone who has taken Microeconomics knows that in an efficient capitalistic model businesses make zero profits. The internet isn't perfectly efficient (we still have patents, in the case of Google), but the fact of the matter is that I have instant access to competition. I need only type in a word, a dot, and com into my browser.
That by the way is the biggest difference between TV and web. With TV, I watch "The Tick" because it's the only damn thing on at the time. Even if I had cable, my choices would still be limited to the hundreds. With the internet, I have literally millions of choices, and there are almost zero barriers to entry (any Yahoo can pay $20 a month and start her own website). That is the difference with the internet, and it's not one that is ever going to be "fixed" (short of massive government regulation, anyway).
Would people pay for content? I think the answer is "yes". But a penny a page is simply too high. The only business model I see working is an AOL-like one where you pay a flat fee (say $30/month. Half the fee goes to the connection/bandwidth provider, half goes to the content providers. Sort of like ASCAP for webmaster.
Well, you could have argumentativly said 'cheaper' most of the time, but what of the rest? IDE drives are notorious for being unreliable, so I don't even think there is an argument. And faster?
Reliability comes from replication of data onto multiple drives. Speed also comes from proper use of multiple drives.
What is atypical is a system where disk I/O becomes the limiting factor.
What are you smoking? Disk I/O is THE ONLY limiting factor in modern PCs.
The limiting factor in modern PCs is generally network I/O (for those using the internet), or video I/O/CPU (for gaming). Considering that a gig of ram costs less than $100, most disk accesses are asynchronous writes.
That's fine... But you really didn't make a point there. You took one example, stripped it of everything but bare RPM and GB ratings and expect it to mean something?
You made the comment that for comparable speed there is little difference in price. I guess I should just respond with "nuh-uh", since you aren't interested in a counter-example, and I don't have the time to iterate through every single combination currently in existance to show you that 99.999% of the time there is a cheaper, faster, more reliable solution utilizing IDE.
First off, dual ATA hard drives is the maximum you can have in a typical system, with 4 being the absolute max (and dual controllers rarely get along together). Whereas with SCSI you could have ~ 30.
OK, so we max out at 160 gigs... At that point we've saved what, $600? Enough to buy another whole computer and network it in.
You said nothing of the cache, seek time, warranty, quality, etc.
I was being kind. The cache is 2Mb*2 for the IDE vs. 1Mb for the SCSI. The seek times are 9/2=4.5ms for IDE vs. 7.4 for SCSI. The warranty and quality are irrelevant regarding your point of speed. In any case, with the money left over you can buy a few spares.
You took one single example and want people to think it's typical.
Again, I was being kind. I started out with my own personal setup 2x40 gigs, but that was way too rediculously in favor of IDE, so I tried to gather one more in favor of SCSI. It most certainly was typical, though. What is atypical is a system where disk I/O becomes the limiting factor. I challenge you to come up with a SCSI drive which I couldn't match with IDE. Or if you want to go with multiple drives, then a whole a la carte system (along with a benchmark to perform).
There are hundreds of combinations you could have come up with, and given a more reasonable assesment of the prices.
If you noticed I picked the 25Mb IDE drives, which are exactly the same price on pricewatch as the 40Mb ones. Hell, I tried my best to give SCSI a fighting chance, but still failed.
This is not to mention that pricewatch has a very limited selection of SCSI drives (I know, I've looked many times).
So if pricewatch doesn't have a good selection, beat those 25 gig IDE drives with SCSI for under $200. Or show me a SCSI drive which I can't beat for less money with IDE. I don't think you can do it.
Maybe... Mile for mile, driving is 4 times as likely to result in death as flying. But males are twice as likely to die in a car accident as females. And 50% of accidents are caused by drunk drivers. And 2/3 of people who die in accidents are not wearing seatbelts. So if you are a female, and you aren't drunk, and you wear your seatbelt, driving is safer than flying.
Slashdot Mirror
The ideal scenario would be to recompile on the new platform without changing a line of code - will this type of portability be possible?
It certainly is possible, though you'll almost certainly want to have separate Makefiles for the two platforms. You also have to either use ifdefs, platform specific static libraries, or platform specific shared libraries/dlls.
My one suggestion is that you at the least compile on both platforms early and often. I say at the least, because you'd be better off doing at least some unit testing and QA on both platforms. You will run into problems if you don't, and you probably will run into problems even if you do. This is even true in java, trust me, I know from experience that some platforms are going to have bugs even if you do everything by the book. And other times you'll notice bugs in one platform that are bugs in the other platform, but just don't show up in your tests.
Forget java, use wine.
Plus, unlike java, you're not running an emulator.
Writing cross platform GUI applications is hard.
Hmm, I find that quite interesting. I am currently writing a linux program in GTK+. I downloaded the source code into Windows, compiled, ran, and... it crashed...
Then I changed two places where I was calling free(), and changed it to g_free(). Recompiled, and the app runs perfectly on Windows and Linux.
Yes, a network connection is usually slower than your hard drive. Video definately is not.
Video may be faster, but it is commonly the bottleneck. Just as a slow network doesn't always slow down a hard drive, a slow hard drive doesn't always slow down a video card. In the case of gaming, everything is typically already stored in ram and disk accesses are a minimal. The bottleneck, if any, is the video card and/or the CPU (and/or the ram/cache, though I doubt it).
As for hard drives, an OS like Win2k can easially take up half of your 1Gig of memory, but even with an infinite ammount of RAM, it still does have to write to the disk soon after, which usually conflicts with the next portion of data your are trying to read from the disk...
Well, as for Win2k, I know very little about it. I'm considering a unix system here. As I said, disk writes are generally asynchronous, which are not a bottleneck. You write it to the buffer cache, and go on your merry way. Eventually, when there's time, you get it to disk. Even with synchronous writes there is little to no advantage from most SCSI drives in today's day and age, since they are written directly to the journal, which has no fragmentation and generally requires no seek time. Unless you're writing more data than can be handled by the disk (in which case you should be using RAID anyway), you're not going to have a bottleneck there.
I'm a professional, you aren't going to just convince me that hard drives aren't a bottleneck in almost every single aspect of PCs. It's something I know, and anyone that uses a computer could deduce the same quite easially.
And I've been a kernel programmer on the performance team for an operating system company, so I don't have to deduce shit, I've seen the bottlenecks. Unless you need massive amounts of storage accessible on a single CPU (tremendously high volume databases which can't be broken out into multiple machines), or massive data transfer rates (the only thing I can think of is live video processing), you can do the same or better with IDE.
My claim was never that SCSI was cheaper than IDE, just that it is comparable in price if you match feature for feature (and it is cheaper in many circumstances).
My claim is that for 99% of the SCSI applications in use today, there is an equivalently performing system that can be built for a lower cost, using IDE. The drives themselves may not have the exact same features, but the application will perform as well or better.
Somehow, I think you're just going to go on in your current mindset of wanting only the interfaces Intel gives you, and not acknowledge that SCSI is better.
I'll acknowledge that SCSI is better. But so is a 600 Mhz computer better than a 500 Mhz computer. But if the 500 Mhz computer costs $500 and the 600 Mhz computer costs $2000, for 99% of the applications out there you're better off buying two 500 Mhz computers than one 600Mhz one. Oddly enough two exceptions would be the same two as I presented for SCSI vs. IDE.
After you design hardware, you've also got to have it built, and if you're earning enough to be able to pay that out of your own pocket, you won't have the spare time to design your own laptop...
I guess I implied that it was the same amount of work to build the two. What I was more getting at is that one isn't intrinsicly more difficult to understand than the other. Hardware is more expensive, but if you have the money for the parts it's just as simple as software. Woz may have spent more money than Linus, but I'm fairly certain they each could have done the other's job if they were interested in it.
I'm not sure "no longer" is true, but it's certainly true that engineering schools are not teaching the real-world aspects of getting from a schematic to working hardware.
I say "no longer" because I am under the impression that at one time there essentially was no software. Programming was done with a trusty soldering iron, and whatever you programmed was there pretty much forever.
Perhaps we'll see the same thing with regard to low level programming languages, like C. We already are seeing it to a small extent with assembly. Personally I like to know what's going on from the top to the bottom before I write anything, but I certainly do see the benefit in not teaching all the details of the hardware to someone who's never going to see anything other than Visual Basic.
He isn't saying that Firewire is bad for storage, rather that it is, at the moment, overkill for this application and that USB is good enough, cheaper, and better supported under Linux. In the original question, aozilla specifically says that speed is not an issue, which is the only advantage I can see Firewire has over USB in this application.
Makes me wish I had rephrased the question. I mentioned that speed is not a big issue to try to get rid of the "go with SCSI" crowd. USB 1.1 would be out of the question, however USB 2.0 is getting a good look now. I guess I must have missed the big USB 2.0 revolution, because every time I read "USB hard drive" I read "900Kb/sec transfer limit". I'm looking for something at least close to the speed and cost I'm getting now with IDE.
After reading the answers to my question (thank you very much everyone), I've pretty much decided that firewire would be preferable to yet another IDE (is it ATA) drive. I haven't yet looked into USB 2.0, but I'm guessing that decision is going to come down to which one would I rather have 2, 3 years down the road.
Sounds good to me. I've had zero problems with my 5400, considering the drive is mainly just there for mp3s, rpms, isos, backups, and when I shut the computer off at night, wiping out my half gig of ram. And once I get the firewire drives up and running I'll probably be making a server to stick in the closet or basement and not have to deal with the shutting down at night part anyway.
Spending some karma to get this Score:0 post looked at. Mod the parent up.
Ob on topic section: The mobile racks are absolutely wonderful. I use them all the time to move drives around. One problem in addition to them not being hotswappable is that you have to change the master and slave setting by opening up the drawer if you need a different setting in the two different locations. Another reason it would be great to have a firewire mobile rack.
It's too bad that the price gap between SCSI and IDE drives has widenned so much, because they are essentially the same drives with slightly different electronics.
Presumably it's the economies of scale that are causing this one. Apple may have a niche market, but it's a fairly large niche. The SCSI market is still primarily for servers.
I am aware that SCSI has all I was looking for, but the price is simply not something I can handle (especially for external drives, which is what I'm really looking for).
(and the ability to add more than 3 HDs at all, besides my CD-rom).
Actually, now that I think about it, that's probably one of the biggest issues. Right now I have 4 old hard drives laying around, just because it's not worth the trouble hooking them up for the 2-8 gigs I'll get out of them. Who knows that in 2 years I won't be saying the same thing about my 40 or 80 gig drives.
So for say 3 80 gig HDs for random access, what would be the performance of IDE vs. USB 2.0 vs. Firewire, assuming the same 5400 RPM IDE drive as the actual drive? This is pretty much the scenario I'm looking at, though I can only afford to replace my one IDE drive at the moment.
I think firewire is cool as hell, but not for this application. It's got bandwidth galore, to move video data back and forth, but this doesn't translate to "bandwidth galore for storage".
Why not? Are the seek times more? What are the practical problems with firewire vs. IDE?
Hot plugability is an issue? How many times will you actually use this?
Four times a day, Monday through Friday, at the very least. Sharing with 2 PCs... I'd also use it for backup purposes if it really worked well. Why bother with tape backups when I can spend $200 and back up 80 gigs?
If speed isn't an issue, what's wrong with IDE?
As I said, hot swappability, and the ability to add more than two devices without a significant speed detriment (and the ability to add more than 3 HDs at all, besides my CD-rom).
Another advantage is that I won't have to spend 2 hours installing the drives in my parents' computers when I give the old drives to them and buy new ones.
Or even external scsi? A decent scsi card, and external drive are no more expensive than the 1384 drives I've seen. There are plenty of dumb/slow/external drive solutions, and in every case they're cheaper than firewire.
My rough estimate would be $250x3 for 3 80 gig drives, plus $100 for the 1384 card. What hot swappable reasonably fast (no tape drives) solution do you know of for $850 for 240 gigs?
There's a considerable difference between rolling your own software and rolling your own hardware.
Only because we're no longer taught hardware as well as we're taught software. Woz was a smart guy, but he wasn't any more brilliant than the top software designers out there.
Err... what? I see this technology as wonderful. By deferring the censorship process until all material is in the hands of the consumer, you're creating a system that allows people to still sanitize what they want to sanitize without corrupting the purity of the film that's on the DVD the consumer gets.
If any of the versions of the DVD are rated R, you still can't rent it if you're under 18. I'm sure if any of the versions of the DVD are rated NC-17, Blockbuster will continue to not carry it.
Remember that editting and censorship already exist. Before now, such editting and censorship would entail releasing a version of the film with those edits permanently applied. If this technology gains wide-spread acceptance, that will no longer be the case.
For the reasons I give above, I believe that still will be the case. At best (worst) you'll have a special CSS key to unlock the R rated stuff, which will pretty much lock out anyone who doesn't have the latest (non-cracked) version of the players.
The top 1,000 Web sites agree that everyone will switch over to a penny per page on a specific date under a unified system.
Can you say "anti-trust"?
The sites need to work together. If some sites switch and others don't, you will get the same problem that happens now when a site decides to unilaterally charge for its content. If there is not a uniform and super-simple billing model (so that users get one simple, easy-to-understand bill), the thing just won't work.
Yes, it's called collusion. Of course a cartel is going to have artificially raised prices, this is precisely why such a thing is illegal.
What if all the gas stations in your state decided to raise gas prices to $2 a gallon? They'd make a hell of a lot of money, is what would happen, and then the owners would go to jail.
Perhaps so, but you are leaving quality and value out of the equation. I hit about 200 Google pages per day and I would gladly pay 2.00 USD for that service if Google agreed to maintain the same level of quality they have today.
Quality is partially where the patents come in. But if Google started charging a penny a page, and people actually paid it, I'd start making an alternative to Google just so I could charge $0.005 a page (and make $150 million/year). I'm sure others would do the same, and two of us are bound to eventually come up with equal or better quality to google. It would only take two search engines of equal quality to Google to drive the prices down to the actual cost of the less efficient one. That's microeconomics.
I agree with you that Google is the best search engine, today, but that's only because no one has any incentive to compete and undercut them (since they're already making near minimal profits). That and the patent, which IMHO isn't too hard to get around and still have quality.
Yes, directors voluntarily choose to destroy their movies for the sake of the censors, but there still is pressure put on them from the studios. While I don't have a particular problem with this technology (it's technology, therefore it's morally neutral), I do see this as a negative for the film industry. This is especially true for films where the director (or some other single visionary) doesn't have the final say on post-production. I think of "Eyes Wide Shut", a film which was bastardized in large part by Blockbuster and the major movie theatres which refuse to show NC-17 films.
Again, it's technology, it's voluntary, so there's not much you can do about it, but it's by no means a positive thing.
Google.com gets about 100 million page impressions per day right now. With a penny per page, Google would make $1 million a day, or something like $350 million per year.
Umm, no, sorry, that's not how it works. With a penny per page, Google would make $1 a day, or something like $350 per year, because people would use alternatives. Anyone who has taken Microeconomics knows that in an efficient capitalistic model businesses make zero profits. The internet isn't perfectly efficient (we still have patents, in the case of Google), but the fact of the matter is that I have instant access to competition. I need only type in a word, a dot, and com into my browser.
That by the way is the biggest difference between TV and web. With TV, I watch "The Tick" because it's the only damn thing on at the time. Even if I had cable, my choices would still be limited to the hundreds. With the internet, I have literally millions of choices, and there are almost zero barriers to entry (any Yahoo can pay $20 a month and start her own website). That is the difference with the internet, and it's not one that is ever going to be "fixed" (short of massive government regulation, anyway).
Would people pay for content? I think the answer is "yes". But a penny a page is simply too high. The only business model I see working is an AOL-like one where you pay a flat fee (say $30/month. Half the fee goes to the connection/bandwidth provider, half goes to the content providers. Sort of like ASCAP for webmaster.
Well, you could have argumentativly said 'cheaper' most of the time, but what of the rest? IDE drives are notorious for being unreliable, so I don't even think there is an argument. And faster?
Reliability comes from replication of data onto multiple drives. Speed also comes from proper use of multiple drives.
What is atypical is a system where disk I/O becomes the limiting factor.
What are you smoking? Disk I/O is THE ONLY limiting factor in modern PCs.
The limiting factor in modern PCs is generally network I/O (for those using the internet), or video I/O/CPU (for gaming). Considering that a gig of ram costs less than $100, most disk accesses are asynchronous writes.
9.10GB SCSI ULTRA2 LVD 3.5LP 5.6MS 10K CHEETAH LC 80PIN Storage $71.95
2x6.04GB EIDE ULTRA-ATA 5300RPM AP200 = 2x$28.95 = $57.90
That's fine... But you really didn't make a point there. You took one example, stripped it of everything but bare RPM and GB ratings and expect it to mean something?
You made the comment that for comparable speed there is little difference in price. I guess I should just respond with "nuh-uh", since you aren't interested in a counter-example, and I don't have the time to iterate through every single combination currently in existance to show you that 99.999% of the time there is a cheaper, faster, more reliable solution utilizing IDE.
First off, dual ATA hard drives is the maximum you can have in a typical system, with 4 being the absolute max (and dual controllers rarely get along together). Whereas with SCSI you could have ~ 30.
OK, so we max out at 160 gigs... At that point we've saved what, $600? Enough to buy another whole computer and network it in.
You said nothing of the cache, seek time, warranty, quality, etc.
I was being kind. The cache is 2Mb*2 for the IDE vs. 1Mb for the SCSI. The seek times are 9/2=4.5ms for IDE vs. 7.4 for SCSI. The warranty and quality are irrelevant regarding your point of speed. In any case, with the money left over you can buy a few spares.
You took one single example and want people to think it's typical.
Again, I was being kind. I started out with my own personal setup 2x40 gigs, but that was way too rediculously in favor of IDE, so I tried to gather one more in favor of SCSI. It most certainly was typical, though. What is atypical is a system where disk I/O becomes the limiting factor. I challenge you to come up with a SCSI drive which I couldn't match with IDE. Or if you want to go with multiple drives, then a whole a la carte system (along with a benchmark to perform).
There are hundreds of combinations you could have come up with, and given a more reasonable assesment of the prices.
If you noticed I picked the 25Mb IDE drives, which are exactly the same price on pricewatch as the 40Mb ones. Hell, I tried my best to give SCSI a fighting chance, but still failed.
This is not to mention that pricewatch has a very limited selection of SCSI drives (I know, I've looked many times).
So if pricewatch doesn't have a good selection, beat those 25 gig IDE drives with SCSI for under $200. Or show me a SCSI drive which I can't beat for less money with IDE. I don't think you can do it.
So the same stupid comment isn't in the Fox article. Mea culpa. Look that one up. :)
Actually, I do know what plagiarism is, and copying a stupid comment out of an article without atrributing it would fall under definition number 2.
For example, an editor might cut out stupid comments from a post, such as "Fold up pocket monitors?".
The same stupid comment is in the Fox article.
So it's not only stupid, it's plagiarism.
Flying is still safer than driving
Maybe... Mile for mile, driving is 4 times as likely to result in death as flying. But males are twice as likely to die in a car accident as females. And 50% of accidents are caused by drunk drivers. And 2/3 of people who die in accidents are not wearing seatbelts. So if you are a female, and you aren't drunk, and you wear your seatbelt, driving is safer than flying.
For comparable speed there is little difference in price.
Hmm, looking at pricewatch, I see that 1 50 gig 7200 RPM drive is $500. 2 25 gig 5400 RPM drives (equivalent to 50 gigs at 10800 RPM), is $150.