Sourcerer is a brilliant idea, but may be ahead of its time. Downloading everything from source and compiling requires a lot of CPU horsepower (not a problem nowadays) but also lots of bandwidth. Many people still do not have the bandwidth so binary distributions are invaluable. However, I must admit that over the years I have used Slackware as a base OS and then built all my updates from source as and when they appear. This guy has the right idea. It would be a shame to see it fail.
And in other news, Roy Orbison and AmigaOS were seen staggering in a decomposed fashion along a disused mining railway in the Back of Beyond whilest sharing a ghostly joint and sipping from a half-empty bottle of bourbon.
Well, there's one obvious bug. It should at least be int main(void) if you don't want to check for command-line paramenters. ANSI C requires this. It is a side-effect of C++ compilers that this compiles without warnings (in C++ you don't need an explicit void).
Pyramids and ruins? Oh dear, you've been had by the screaming hedgemonkies. I'm sure they've tried selling you some healing crystals and Ayurvedic herbal piles healing cusions. http://www.skepdic.com/faceonmars.html
This sounds very interesting. I have a little itch-scratcher on-going at http://libsimd.sourceforge.net and I'd be interested in any little tricks you have:-)
I am perfectly aware of what a pointer is for, and what 128-bit addressing means. You are correct. 64-bit MMX registers do not a 64-bit pentium make, neither does 128-bit AltiVec registers make the G4 a "128-bit" processor. I could implement 20-bit addressing on an 8086 using 32-bit pointers (segment:offset) which is a 16-bit processor, not a 32-bit or 20-bit one.
Correct, but a "128-bit processor" doesn't mean one with a 128-bit address bus. Conventionally, when we speak of a processor being x-bit, we are referring to its natural machine word size. The old CDC 6600 was a 60-bit machine, but it had 18-bit addressing, for example. Hammer is 64-bit, but it only has a theoretical maximum of 48-bit address bus (in hardware), but at first, not all 48-bits will be useable. Yes, the internal address registers will be 64-bits wide, but like in the old days of 68000 Apples (internally 32-bit - all registers - externally 16-bit data bus (cf. 386sx) and 24-bit address bus, the top bits will be ignored by the hardware.
128 bits is useful when doing Single Instruction Multiple Data stuff, i.e. in a 128-bit register you can have 2 double-precision (64-bit) floats or 4 single-precision (32-bit) floats. So, if you have two 4-vectors of single-precision floats you can add the elements or multiply them together in a single clock cycle. This is what SSE and SSE2 and AltiVec do. 3DNow! is similar, but with 64-bit registers.
I suppose it may originally have been to provide a single, consistent Windows-95-like front end to the user on whatever OS it was running on. Most people are familiar with that kind of front end, and it saves them having to learn something new. Even relatively intelligent people used to Windows get very annoyed when they have to use something different. They perceive it to be "wrong" if it doesn't look and feel like Windows. Sad but true.
It doesn't have to "triumph". What matters it that there is a decent alternative out there for people who want one and it's stimulating innovation by providing competition. Just look at all the M$ licensing fiasco problems at the moment. People are considering turning away from M$ in droves.
If it's such a problem, just ditch GNOME and move over to GNUstep which is all GPL/LGPL and can't be taken away. Oh, and you get a bit of MacOS X compatibility thrown in too.
...and I was starting to do something similar with 3DNow!, eventually hoping to go cross-platform by having conditional compiles for SSE and Velocity Engine/AltiVec.
"That is absolute bullshit." No it isn't. I'm talking about significant changes in large numbers of organisms, not one huge change in one organism, like the case where parents can produce an offspring of a completely different (ie incompatible) species. "Natural selection will breed out HARMFUL mutations in the population, but what about POSITIVE mutations." By excatly the same method, it does indeed breed out positive mutations. Occasionally a mutation does get passed on. "How do you think we evolved out of the nothing?" Lots and lots of changes over a very long time.
....and another thing. There is evidence from the aftermath of the Chernobyl disaster that natural selection weeds out the worst of the genetic mutants and over time the ecosystem adjusts itself to cope. Yes, it's not ideal, but evolution in action does tend to right things by itself. ....and the amount of radiation necessary to cause many major mutations in a population is relatively large, much larger than anything that leaks out into the environment (accidentally or intentionally) from civillian nuclear power. (That was the basis of my point about Blinky). Yes, I'm about to start ranting, but that's because I'm sick of the ill-informed scare-mongering and down-right lies perpetrated by the anti-nuclear people. I'm pro-nuclear for scientific, environmental and economic reasons. I am a qulaified Reactor Physics Engineer.
"You remember the Simpsons cartoon with a 3-eyed fish near the nuclear power plant? Well that's no joke. That's what radiation does."
Methinks you are getting fantasy and reality muddled up. Or else, nice troll! (Especially since most people out there know diddly-squat about matters Nuclear)
I don't know. You can get a mobile phone for £30 that has voice-activated dialing. IMHO I reckon something with the power of a humble pentium 100 could do it easily.
Sourcerer is a brilliant idea, but may be ahead of its time. Downloading everything from source and compiling requires a lot of CPU horsepower (not a problem nowadays) but also lots of bandwidth. Many people still do not have the bandwidth so binary distributions are invaluable. However, I must admit that over the years I have used Slackware as a base OS and then built all my updates from source as and when they appear. This guy has the right idea. It would be a shame to see it fail.
And in other news, Roy Orbison and AmigaOS were seen staggering in a decomposed fashion along a disused mining railway in the Back of Beyond whilest sharing a ghostly joint and sipping from a half-empty bottle of bourbon.
Well, there's one obvious bug.
It should at least be int main(void)
if you don't want to check for command-line
paramenters. ANSI C requires this.
It is a side-effect of C++ compilers that this
compiles without warnings (in C++ you don't need an explicit void).
Pyramids and ruins? Oh dear, you've been had by the screaming hedgemonkies. I'm sure they've tried selling you some healing crystals and Ayurvedic herbal piles healing cusions.
http://www.skepdic.com/faceonmars.html
This sounds very interesting. I have a little itch-scratcher on-going at http://libsimd.sourceforge.net and I'd be interested in any little tricks you have :-)
I am perfectly aware of what a pointer is for, and what 128-bit addressing means.
You are correct. 64-bit MMX registers do not a 64-bit pentium make, neither does 128-bit AltiVec registers make the G4 a "128-bit" processor.
I could implement 20-bit addressing on an 8086 using 32-bit pointers (segment:offset) which is a 16-bit processor, not a 32-bit or 20-bit one.
It has nothing to do with the size of pointers. It has everything to do with the size of the registers.
t ml #CDC6600
How did you get to be posting at +2 with a clue of this size?
http://www3.sk.sympatico.ca/jbayko/cpuAppendA.h
Correct, but a "128-bit processor" doesn't mean one with a 128-bit address bus. Conventionally, when we speak of a processor being x-bit, we are referring to its natural machine word size. The old CDC 6600 was a 60-bit machine, but it had 18-bit addressing, for example.
Hammer is 64-bit, but it only has a theoretical maximum of 48-bit address bus (in hardware), but at first, not all 48-bits will be useable. Yes, the internal address registers will be 64-bits wide, but like in the old days of 68000 Apples (internally 32-bit - all registers - externally 16-bit data bus (cf. 386sx) and 24-bit address bus, the top bits will be ignored by the hardware.
I was only trying to make the point that 128-bits is useful in some niche applications, and it has already been done. I don't disagree with you.
128 bits is useful when doing Single Instruction Multiple Data stuff, i.e. in a 128-bit register you can have 2 double-precision (64-bit) floats or 4 single-precision (32-bit) floats. So, if you have two 4-vectors of single-precision floats you can add the elements or multiply them together in a single clock cycle. This is what SSE and SSE2 and AltiVec do. 3DNow! is similar, but with 64-bit registers.
What are you on? The 64-bit x86 is 100% backwards compatible (even at the OS level) with the 32-bit x86 and it runs the code at full speed.
Solaris comes with a GNOME CD in the media kit, and KDE is on the Freeware Companion CD.
I suppose it may originally have been to provide a single, consistent Windows-95-like front end to the user on whatever OS it was running on. Most people are familiar with that kind of front end, and it saves them having to learn something new.
Even relatively intelligent people used to Windows get very annoyed when they have to use something different. They perceive it to be "wrong" if it doesn't look and feel like Windows. Sad but true.
It doesn't have to "triumph". What matters it that there is a decent alternative out there for people who want one and it's stimulating innovation by providing competition. Just look at all the M$ licensing fiasco problems at the moment. People are considering turning away from M$ in droves.
If it's such a problem, just ditch GNOME and move over to GNUstep which is all GPL/LGPL and can't be taken away. Oh, and you get a bit of MacOS X compatibility thrown in too.
...and I was starting to do something similar with 3DNow!, eventually hoping to go cross-platform by having conditional compiles for SSE and Velocity Engine/AltiVec.
http://libsimd.sourceforge.net
Arse!
http://www.talkorigins.org/faqs/faq-intro-to-biolo gy.html
"That is absolute bullshit."
No it isn't. I'm talking about significant changes in large numbers of organisms, not one huge change in one organism, like the case where parents can produce an offspring of a completely different (ie incompatible) species.
"Natural selection will breed out HARMFUL mutations in the population, but what about POSITIVE mutations."
By excatly the same method, it does indeed breed out positive mutations.
Occasionally a mutation does get passed on.
"How do you think we evolved out of the nothing?"
Lots and lots of changes over a very long time.
....and another thing.
There is evidence from the aftermath of the Chernobyl disaster that natural selection weeds out the worst of the genetic mutants and over time the ecosystem adjusts itself to cope. Yes, it's not ideal, but evolution in action does tend to right things by itself.
....and the amount of radiation necessary to cause many major mutations in a population is relatively large, much larger than anything that leaks out into the environment (accidentally or intentionally) from civillian nuclear power. (That was the basis of my point about Blinky).
Yes, I'm about to start ranting, but that's because I'm sick of the ill-informed scare-mongering and down-right lies perpetrated by the anti-nuclear people. I'm pro-nuclear for scientific, environmental and economic reasons. I am a qulaified Reactor Physics Engineer.
I was not denying that. All I was saying is that the Blinky the 3-Eyed Fish was a piece of fiction.
Can I come too, and I'll bring 17 friends!
"You remember the Simpsons cartoon with a 3-eyed fish near the nuclear power plant? Well that's no joke. That's what radiation does."
Methinks you are getting fantasy and reality muddled up. Or else, nice troll! (Especially since most people out there know diddly-squat about matters Nuclear)
I don't know. You can get a mobile phone for £30 that has voice-activated dialing. IMHO I reckon something with the power of a humble pentium 100 could do it easily.
Look here:m l#Sec4P art5
http://www3.sk.sympatico.ca/jbayko/cpu4.ht
MIPS (applied to the processor family) originally stood for Microprocessor without Interlocked Pipeline Stages.
Mod this guy up.
He speaks sense.