Serial ATA, which is the next evolutionary step for consumer and desktop computers, will not suffer from this hardware limitation.
The spec includes a four-wire interface, meaning we can finally say goodbye to filling our cases with cables, lower voltages (= less power drain since ATA requires 5V while SerialATA doesn't.) Plus, of course, plenty of transfer oomph. The first version is 1.5Gbps, scaling up to 6Gbps. Of course, it still doesn't try to replace SCSI. It never will.
As a sidenote to the "advertising gone out of control" discussion, perhaps the following numbers could be of interest:
Since 20 sept 1999, my ad filtering proxy reports the following:
41470 connections made, in total
23408 non-ad images loaded (or at least not recognized as such)
12990 ad images filtered
This means that roughly a third of all the images on the sites I visit are ads!
Now, these numbers aren't the absolute truth (numbers rarely are). For one, ads are mostly cache inhibited, thus getting a higher proxy rating than site "chrome" images. Also, I mostly browse with images turned off, so my average image/page rate is very low (around three images per page). And of course my choice of sites to visit affects the turnout. Nevertheless, the 1/3 ad/image rate was a bit of a shock.
If the managers at VA fail to compete effectively against all rivals, stock holders will rightly demand they be fired and replaced by people deemed capable.
It appears many people believe stockholders will invariably demand immoral or near illegal behaviour from the companies they own. How come?
Successful companies enjoy near total freedom as far as the stock holders go. And VA Linux is so very very successful. Remember, most stock owners don't understand VA Linux' or Red Hats' business case anyway - they just enjoy the booming stock. The idea that they would, en masse, turn around and demand the resignation of the board or the CEO because some nerd site doesn't post propaganda is absurd.
Now when/if the bubble bursts and the stock takes a nose-dive, that's when we're in trouble (or, rather, Slashdot). Nobody likes to lose money, and if enough stock holders think the board/CEO has substantially mishandled the company, there may be some ruckus. But not many people are going to rock the boat now, when they don't even know what's making the magic carpet fly!
I'd really like to see some cases where a company that was trying to do "the right thing" was lambasted by their stock holders for it. Until then, I'll put this tired argument down as yet another FUD issue.
> You cannot write portable programs if your basic data types are not defined.
This has to be one of the most widespread, and possibly destructive, myths about C programming. The truth is, if you write code that depends on the size of your basic types, your code will be less portable. The next generation machines will always handle your types in ways you will fail to predict.
> And it also doesnt give todays hardware any advantage.
Have you ever worked with a PowerPC processor? Some of these cores do not have 16-bit integers, only 32-bits. Yet, lots of people reasoning like you use them anyway (because "16 bits is enough for this value"). This forces the compiler to insert 16-bit emulation code, thus increasing code size and decreasing execution speed. Had these people ignored the size of their integers and just used 'int', the code would have been both faster and more portable!
Take a look at a few of the most widely ported software packages around. How many of these redefine the types in order to "know the size of their types"? Not many, I can tell you.
Writing portable code has little to do with worrying about the size of your integers, and lots to do with not trying to optimize your code to whatever system you happen to write the code on (by, for example, worrying about what the size of your integers are...)
Even if you found a free Utopia, untouchable by outside forces, you still need pipes between Utopia and the rest of the non-free world.
The non-free side of these pipes would be subject to lawsuits faster than you can blink. And then you'd have a data haven alright, but not on the Internet...
All in all, I think it's more fair to the employees and clients to only bill for hours worked.
Ah, but then we enter the foggy realm of "work speed". Simply charging for (and paying for, if you're a customer) flat hourly rates completely ignores the concept of value-for-money.
This is an old problem -- how do we charge for the work we do?
Flat hourly rate is horribly skewed. As we all know, different people work at different speed, with different resulting quality. Yet most rates differ no more than 50%! Naturally, paying one contractor twice as much for a job, simply because he's half as fast (assuming equal quality) is a poor deal. And 2x is a low factor. Yet, this is by far the most common practice.
Fixed price never works. Nearly all development is iterative (i.e. nobody knows in the beginning what the result is supposed to be in the end) which means it's practically impossible to calculate a price without littering the contract with "but-if" clauses.
Employee-only development doesn't work either. People, especially the good ones, tend to move around and often end up as contractors (go back to 1).
Differing hourly rates is a somewhat utopian idea. It is, of course, rather difficult to quantify peoples' qualities enough to actually put a price on everyone's head. Which is why we're in this situation in the first place! (Go back to 1...)
Another problem I noticed is that the rest of the spam came from major 'legit' domains like yahoo.com, aol.com, and hotmail itself.
Actually, almost no spam originates from these domains. They are, however, among the top favourites for fake From: addresses in spam messages.
You need to know that the From: address in an email is purely cosmetic. The old postcard analogy can be used again when saying that the From: line says no more about the sender of a message than the signature (or lack thereof) on a postcard.
Instead, as on a postcard you look at the stamp to derive information of the true origins, in an email you look at the "Received:" lines. Or you can simply download some script to automatically extract the information and complain to the proper addresses on the guilty relays.
Bottom line: Ignore the From:-line and instead complain to the real senders! It works. I routinely notify the relays of all the spam I get (it's a one-key operation with scripts like the above) and that results in the closing of about one open mail server per week. Less open servers means more difficulties for the spammers, which is a Good Thing.
This camera, with a 66MHz PPC chip, is more powerful that 3 of the 7 computers that are on my home network.
Don't bet on it. The MPC823, while certainly faster than your old calculator, is by no means any powerhouse. It contains a stripped ("embedded") PowerPC core with no floating point unit, only 1KB data cache and 2KB instruction cache (that's a whopping 512 instructions!) and also has some limitations in the out-of-order execution and branch folding department.
Motorola likes to say that this thing runs 99MIPS @75MHz, but I'm tempted to call that "benchmarketing". The core can't fetch more than one instruction per clock (due to the data bus being only 32 bits wide), so you're hard pressed to squeeze your actual MIPS up anywhere beyond your MHz.
The MPC823 is, however, ideal for this kind of application, because it contains pretty much everything you need in a single chip, except for some RAM and an oscillator. It's got the CPU, the memory controller, the LCD controller, the USB controller, the IrDA controller, the timers, the realtime clocks, the DSP, the DMA and the PCMCIA controller (plus a bunch of other stuff that the camera doesn't appear to use). All in one teeny 256-pin package, costing not much at all.
Conclusion: Don't compare the "MHz" of the camera to that of your Mac, or whatever. It's not the same chip.
UNL is designed with the following aims: (1) UNL is to be capable of exactly representing all the information expressed in any language. (2) UNL expression must be defined not only as rigorous but also as general as possible in order to be understood by any people who are engaged in the development of "enconverters" and "deconverters" in each language.
Not only is point one completely and utterly impossible for reasons well discussed here already (slang, local expressions, evolvement of languages etc.), point two actually contradicts point one! They want UNL to be an exact representation of the meaning expressed in the native language, while simultaneously having it to be generic enough so everybody (or at least all "enconverter" developers) can understand what is being said. Assuming the average "enconverter" developer will be as technically (il)literate as the authors of this document, there's no way they are going to understand what technical people are talking about even when using his native language. No way is UNL going to help with that. So how, then, is he going to understand that very same conversation translated from a language he doesn't understand in the first place? Forget it!
Nice idea. Store it in the bin with all the other equally nice ideas: "Health and food for all" and "Can't we all just get along?".
Excuse me, but these compaines you mention file thousands of patents every year. Don't believe for a second that they choose not to patent something if have the chance. If they don't have a patent for a design, it's because either the patent application was rejected or someone beat them to it! Go search www.patents.ibm.com and you'll see (IBM gives >20K hits...)
It worries me because I think the Linux community did a very good job of refuting the ridiculous results of the test, but if they redo them and can claim that Linux lost even with the help of Linus and Alan Cox
Don't worry. If/when they complete the "test" and publish it, naming Linus and Alan as "helpers", the first thing the news media is going to do is to call Linus and Alan to get a comment about it and thereby get the real story. In fact, having Linus and Alan involved in this actually helps us prove the point that MindCraft is not interested in obtaining decent Linux performance.
Slashdot Mirror
The spec includes a four-wire interface, meaning we can finally say goodbye to filling our cases with cables, lower voltages (= less power drain since ATA requires 5V while SerialATA doesn't.) Plus, of course, plenty of transfer oomph. The first version is 1.5Gbps, scaling up to 6Gbps. Of course, it still doesn't try to replace SCSI. It never will.
(This has been discussed on slashdot before.)
Since 20 sept 1999, my ad filtering proxy reports the following:
This means that roughly a third of all the images on the sites I visit are ads!
Now, these numbers aren't the absolute truth (numbers rarely are). For one, ads are mostly cache inhibited, thus getting a higher proxy rating than site "chrome" images. Also, I mostly browse with images turned off, so my average image/page rate is very low (around three images per page). And of course my choice of sites to visit affects the turnout. Nevertheless, the 1/3 ad/image rate was a bit of a shock.
It appears many people believe stockholders will invariably demand immoral or near illegal behaviour from the companies they own. How come?
Successful companies enjoy near total freedom as far as the stock holders go. And VA Linux is so very very successful. Remember, most stock owners don't understand VA Linux' or Red Hats' business case anyway - they just enjoy the booming stock. The idea that they would, en masse, turn around and demand the resignation of the board or the CEO because some nerd site doesn't post propaganda is absurd.
Now when/if the bubble bursts and the stock takes a nose-dive, that's when we're in trouble (or, rather, Slashdot). Nobody likes to lose money, and if enough stock holders think the board/CEO has substantially mishandled the company, there may be some ruckus. But not many people are going to rock the boat now, when they don't even know what's making the magic carpet fly!
I'd really like to see some cases where a company that was trying to do "the right thing" was lambasted by their stock holders for it. Until then, I'll put this tired argument down as yet another FUD issue.
This has to be one of the most widespread, and possibly destructive, myths about C programming. The truth is, if you write code that depends on the size of your basic types, your code will be less portable. The next generation machines will always handle your types in ways you will fail to predict.
> And it also doesnt give todays hardware any advantage.
Have you ever worked with a PowerPC processor? Some of these cores do not have 16-bit integers, only 32-bits. Yet, lots of people reasoning like you use them anyway (because "16 bits is enough for this value"). This forces the compiler to insert 16-bit emulation code, thus increasing code size and decreasing execution speed. Had these people ignored the size of their integers and just used 'int', the code would have been both faster and more portable!
Take a look at a few of the most widely ported software packages around. How many of these redefine the types in order to "know the size of their types"? Not many, I can tell you.
Writing portable code has little to do with worrying about the size of your integers, and lots to do with not trying to optimize your code to whatever system you happen to write the code on (by, for example, worrying about what the size of your integers are...)
The non-free side of these pipes would be subject to lawsuits faster than you can blink. And then you'd have a data haven alright, but not on the Internet...
Ah, but then we enter the foggy realm of "work speed". Simply charging for (and paying for, if you're a customer) flat hourly rates completely ignores the concept of value-for-money.
This is an old problem -- how do we charge for the work we do?
Anybody with some bright ideas?
Actually, almost no spam originates from these domains. They are, however, among the top favourites for fake From: addresses in spam messages.
You need to know that the From: address in an email is purely cosmetic. The old postcard analogy can be used again when saying that the From: line says no more about the sender of a message than the signature (or lack thereof) on a postcard.
Instead, as on a postcard you look at the stamp to derive information of the true origins, in an email you look at the "Received:" lines. Or you can simply download some script to automatically extract the information and complain to the proper addresses on the guilty relays.
Bottom line: Ignore the From:-line and instead complain to the real senders! It works. I routinely notify the relays of all the spam I get (it's a one-key operation with scripts like the above) and that results in the closing of about one open mail server per week. Less open servers means more difficulties for the spammers, which is a Good Thing.
Don't bet on it. The MPC823, while certainly faster than your old calculator, is by no means any powerhouse. It contains a stripped ("embedded") PowerPC core with no floating point unit, only 1KB data cache and 2KB instruction cache (that's a whopping 512 instructions!) and also has some limitations in the out-of-order execution and branch folding department.
Motorola likes to say that this thing runs 99MIPS @75MHz, but I'm tempted to call that "benchmarketing". The core can't fetch more than one instruction per clock (due to the data bus being only 32 bits wide), so you're hard pressed to squeeze your actual MIPS up anywhere beyond your MHz.
The MPC823 is, however, ideal for this kind of application, because it contains pretty much everything you need in a single chip, except for some RAM and an oscillator. It's got the CPU, the memory controller, the LCD controller, the USB controller, the IrDA controller, the timers, the realtime clocks, the DSP, the DMA and the PCMCIA controller (plus a bunch of other stuff that the camera doesn't appear to use). All in one teeny 256-pin package, costing not much at all.
Conclusion: Don't compare the "MHz" of the camera to that of your Mac, or whatever. It's not the same chip.
Not only is point one completely and utterly impossible for reasons well discussed here already (slang, local expressions, evolvement of languages etc.), point two actually contradicts point one! They want UNL to be an exact representation of the meaning expressed in the native language, while simultaneously having it to be generic enough so everybody (or at least all "enconverter" developers) can understand what is being said. Assuming the average "enconverter" developer will be as technically (il)literate as the authors of this document, there's no way they are going to understand what technical people are talking about even when using his native language. No way is UNL going to help with that. So how, then, is he going to understand that very same conversation translated from a language he doesn't understand in the first place? Forget it!
Nice idea. Store it in the bin with all the other equally nice ideas: "Health and food for all" and "Can't we all just get along?".
Excuse me, but these compaines you mention file thousands of patents every year. Don't believe for a second that they choose not to patent something if have the chance. If they don't have a patent for a design, it's because either the patent application was rejected or someone beat them to it! Go search www.patents.ibm.com and you'll see (IBM gives >20K hits...)
Hello? Can you say VxWorks? pSOS? OS-9? VRTX? There is more to operating systems than just the behemoths used on peoples desktops...
Don't worry. If/when they complete the "test" and publish it, naming Linus and Alan as "helpers", the first thing the news media is going to do is to call Linus and Alan to get a comment about it and thereby get the real story. In fact, having Linus and Alan involved in this actually helps us prove the point that MindCraft is not interested in obtaining decent Linux performance.