One could simply say "if what you see is the OS itself, then why the hell can I use the same GUI, window manager, browser and IM client on a dozen different Linux distros (on CPUs ranging from x86 to Cell), half a dozen BSD ones, Solaris and AIX?"
Back in 2001 or so I used to run Gnome on a SGI O2 under IRIX. In 97 I was using the same fvwm in x86 PCs running Linux and on a Powermac 9500 running MkLinux.
I have been using ZODB for a couple years now and one thing that bothers me with systems that store objects directly instead of "dehydrated" representations of them is that when the underlying code for the object changes significantly all sort of weird things occur
I kind of like dehydrating/serializing objects to a simpler representation when persisting them. This uncomfortable step is nice because it shoehorns the data into a brand new instance.
Sorry, but you are wrong (as your moderation points out).
You can buy a PS3 to do numerics and the Cell inside it is an average performer. Not bad at all for under $1000.
But, if you need to upgrade (and consider your workload is heavily parallelized and optimized for the SPUs because it already runs on your PS3's SPUs) you can buy one or more IBM QS21 blades and a suitable chassis. It's obvious these new Cells will be in these blades as soon as they become available. In the blades, the Cell is not limited as it is in the PS3, there is plenty of memory for the PPUs and you can run all your SPUs at full throttle if your data and programs demand it. And, while you are at it, you can add POWER or x86 blades to the chassis as well as Linux does not run particularly fast on the Cell PPUs and you may want a fast machine to feed the Cell node.
Sorry if you wanted current supercomputer power on the cheap. The PS3 is good enough for a lot of stuff and a lot cheaper than anything that approaches its numeric performance.
"i wonder if the same theory was applied to space travel would a mars mission be logically manned or not?"
Manned missions are unbeatable for inspiring people.
We still talk and make movies about astronauts who went to the moon, but we make very few movies (I can only remember "Andromeda Strain") about space probes.
Do not underestimate the will of someone who badly wants some very nasty radioactive materials.
Still, a lot of radioactive stuff can simply be stolen from the average medical facility (years ago, here in Brazil several people were killed in a mishap with Ce 137 when an abandoned - IIRC - radio-therapy machine was found by some very dumb people). I bet those are the low hanging fruit we should worry about.
"but that just means you need to have a "virtual machine" that emulates a CISC on top of the RISC"
Erm... No.
You can do pretty well with a translation unit that breaks down complex instructions into simpler ones and sends those simple ones to the execution units (CISC on RISC style) instead of executing complex instructions directly (CISC-style).
It's sure more complex than a textbook RISC machine would be and, probably, gets some kind of performance hit (it will take more than one cycle to perform a more complex instruction), but that should be offset because back when RISC was the hottest thing memory bandwidth was cheap compared to megahertz. Getting one instruction from memory that keeps the CPU active for the next few cycles is better than getting a simple instruction from memory and having to wait a few cycles before you can get the next one.
I am very staisfied with my iPod touch. It's the perfect über-PDA. I take mine to places where I would otherwise need a notebook. It's great for web browsing and news reading. If it weren't for the copy-paste thing, it would also be my chosen e-mail thing when I am on the road.
I only wish Apple didn't screw us, early adopters, with the January Upgrade. Having to pay $20 for the apps that were bundled with every later model really did hurt.
"I think all techies I know in microsoft would welcome the abolition of patents"
In fact, a complete abolition of patents would benefit large companies and penalize small R&D outfits (and patent trolls, but nobody feels sympathy towards them).
Patents do protect the small inventor who comes up with something from being ripped off by a bigger outfit that learns what he is doing and is capable of bringing the product to a larger market than the original inventor. As ineffective they are - try suing a Chinese manufacturer - they are the only protection small inventors have.
The real problem is not the patent system. It's good and it works properly. What is desperately needed is a way to prevent the issue or, if needed, invalidate bad patents. The process of invalidating a patent should be very simple if someone can produce prior art or demonstrate the patent is obvious to anyone skilled in the art.
The problem with _software_patents_, which is what we are really discussing here, is that neither a computer program nor a business process is a machine - both are ideas and ideas should not be patentable. A software patent is the very textbook example of a bad patent.
These days, people find clever ways to phrase an idea and receive a patent for it.
This, and only this, has to stop. The patent offices should be held liable for any bad patents they issue.
I distinctly remember a very expensive box with a lot of hard disks inside called Abekas. It was the end-all digital recorder of the early 90s. Pretty cool stuff.
When the only tool you have is a hammer, everything looks like a nail.
Both C and C++ are useful for what they were designed. But that's it. If you find yourself using them for problems they were not designed to handle, I strongly suggest trying other tools.
And, BTW, C++ is plain ugly. Objective-C got it right.
"So, what exactly is Python missing here, oh wise and mighty smartass C programmer?"
You know... Bragging about knowing C is the telltale sign of a very limited programmer. People brag about Lisp or Smalltalk or even Objective-C. Knowing C is not a reason to brag - it's the bare minimum one should know to be called a programmer.
Far too many people regard C as the end of the path. It's only when you have passed it that you realize it lays pretty much in the beginning.
This is absolutely painless in any modern Linux distro. Here I have both python2.4 and python2.5 in/usr/bin and a symlink at/usr/bin/python leading to one of them. All I had to do was to install the "python-2.4" (or something like it) package. Nothing broke. If I had something that broke under 2.5, I could change the #! line to read "python2.4" instead of "python" and everybody would be happy again.
It wouldn't be painful even if I were to hand-compile my own versions - some masochistic thing I am not inclined to do.
There is no need to panic. The Python crew knows fairly well what they are doing.
Still, nobody is forcing you to adopt 3.0 the day it's released. I run Python 2.4 and 2.5 on the same box (along about half a dozen combinations of Zope and Plone) and they seem to play very, very well together.
the fact 3.0 will become available will not break 2.x code overnight. No need to panic.
- Dell pretty much invented the large-scale direct sales built-to-order PC business. - Compaq did invent the PC-compatible - different enough not to get sued out of existence, similar enough it runs the same software - HP did invent a lot of stuff in the personal computer arena - Apple did invent lots of stuff in the GUI arena. Have you seen Smalltalk 80 and how Lisa is different from that?
Microsoft did invent a lot too. It's unfair to judge the value of all company's contributions by its current delinquent behaviour (the one you call "smart").
A couple years back, I got, for my birthday, a book called "Programmers at Work", edited by Microsoft Press. The book is a collection of interviews of programmers ranging from Andy Hertzfeld, Gary Kildall and Butler Lampson all the way to Bill Gates.
I strongly suspect it's not available today and never again will be printed in this form, mainly because in his interview, Bill Gates said:
Interviewer: Is studying computer science the best way to prepare to be a programmer? Bill Gates: No. the best way to prepare is to write programs, and to study great programs that other people have written. In my case, I went to the garbage cans at the Computer Science Center and I fished out listings of their operating system. You got to be willing to read other people's code, then write your own, then have other people review your code. You've got to want to be in this incredible feedback loop where you get the world-class people to tell you what you're doing wrong.
I am sure one of the design goals of QNX was to resemble Unix as much as possible without compromising the real-time features. Being unix-ish made it a lot easier to program for.
Besides that, it had "vi", "cc" and lots of the nice stuff you would expect on a Unix box.
And, BTW, Unix was really spartan those days. The next two Unix-likes I used were on green-screen text-only terminals on multi-user boxes that had a serial console port. GUIs were something reserved for high-end workstations costing tens of thousands of dollars.
"Now, contemporaneous with the C64 in the Apple stable was the IIGS"
Well... The 64 was launched years before the IIGS. By that time, I think Apple had the III (///?) which was not suitable for any games. Heck - it was not suitable for many Apple II software titles.
The 64 was a really amazing machine for the time. 64 KB and color graphics was amazingly cool.
Slashdot Mirror
One could simply say "if what you see is the OS itself, then why the hell can I use the same GUI, window manager, browser and IM client on a dozen different Linux distros (on CPUs ranging from x86 to Cell), half a dozen BSD ones, Solaris and AIX?"
Back in 2001 or so I used to run Gnome on a SGI O2 under IRIX. In 97 I was using the same fvwm in x86 PCs running Linux and on a Powermac 9500 running MkLinux.
"the only things the user should ever have to see are the task switcher, task launcher, and their programs."
Not even that. All those functions should be performed by programs that run on top of the OS.
No user interacts directly with the OS, unless the OS is unbelievably crude and monolithic (for current standards).
And the Amiga did not have a microkernel-based OS. It was nicely modular, but that does not make a microkernel.
I have been using ZODB for a couple years now and one thing that bothers me with systems that store objects directly instead of "dehydrated" representations of them is that when the underlying code for the object changes significantly all sort of weird things occur
I kind of like dehydrating/serializing objects to a simpler representation when persisting them. This uncomfortable step is nice because it shoehorns the data into a brand new instance.
But that may be just me.
Here I am, replying to AC... Slow day indeed.
Sorry, but you are wrong (as your moderation points out).
You can buy a PS3 to do numerics and the Cell inside it is an average performer. Not bad at all for under $1000.
But, if you need to upgrade (and consider your workload is heavily parallelized and optimized for the SPUs because it already runs on your PS3's SPUs) you can buy one or more IBM QS21 blades and a suitable chassis. It's obvious these new Cells will be in these blades as soon as they become available. In the blades, the Cell is not limited as it is in the PS3, there is plenty of memory for the PPUs and you can run all your SPUs at full throttle if your data and programs demand it. And, while you are at it, you can add POWER or x86 blades to the chassis as well as Linux does not run particularly fast on the Cell PPUs and you may want a fast machine to feed the Cell node.
Sorry if you wanted current supercomputer power on the cheap. The PS3 is good enough for a lot of stuff and a lot cheaper than anything that approaches its numeric performance.
"i wonder if the same theory was applied to space travel would a mars mission be logically manned or not?"
Manned missions are unbeatable for inspiring people.
We still talk and make movies about astronauts who went to the moon, but we make very few movies (I can only remember "Andromeda Strain") about space probes.
Do not underestimate the will of someone who badly wants some very nasty radioactive materials.
Still, a lot of radioactive stuff can simply be stolen from the average medical facility (years ago, here in Brazil several people were killed in a mishap with Ce 137 when an abandoned - IIRC - radio-therapy machine was found by some very dumb people). I bet those are the low hanging fruit we should worry about.
"but that just means you need to have a "virtual machine" that emulates a CISC on top of the RISC"
Erm... No.
You can do pretty well with a translation unit that breaks down complex instructions into simpler ones and sends those simple ones to the execution units (CISC on RISC style) instead of executing complex instructions directly (CISC-style).
It's sure more complex than a textbook RISC machine would be and, probably, gets some kind of performance hit (it will take more than one cycle to perform a more complex instruction), but that should be offset because back when RISC was the hottest thing memory bandwidth was cheap compared to megahertz. Getting one instruction from memory that keeps the CPU active for the next few cycles is better than getting a simple instruction from memory and having to wait a few cycles before you can get the next one.
I wonder what a 45nm CADR would be like.
I am very staisfied with my iPod touch. It's the perfect über-PDA. I take mine to places where I would otherwise need a notebook. It's great for web browsing and news reading. If it weren't for the copy-paste thing, it would also be my chosen e-mail thing when I am on the road.
I only wish Apple didn't screw us, early adopters, with the January Upgrade. Having to pay $20 for the apps that were bundled with every later model really did hurt.
"I think all techies I know in microsoft would welcome the abolition of patents"
In fact, a complete abolition of patents would benefit large companies and penalize small R&D outfits (and patent trolls, but nobody feels sympathy towards them).
Patents do protect the small inventor who comes up with something from being ripped off by a bigger outfit that learns what he is doing and is capable of bringing the product to a larger market than the original inventor. As ineffective they are - try suing a Chinese manufacturer - they are the only protection small inventors have.
The real problem is not the patent system. It's good and it works properly. What is desperately needed is a way to prevent the issue or, if needed, invalidate bad patents. The process of invalidating a patent should be very simple if someone can produce prior art or demonstrate the patent is obvious to anyone skilled in the art.
The problem with _software_patents_, which is what we are really discussing here, is that neither a computer program nor a business process is a machine - both are ideas and ideas should not be patentable. A software patent is the very textbook example of a bad patent.
These days, people find clever ways to phrase an idea and receive a patent for it.
This, and only this, has to stop. The patent offices should be held liable for any bad patents they issue.
Actually, I can't imagine why they wouldn't.
Slashdot is, by definition, slashdotted all the time.
What is different from most sites that get slashdotted is that it can withstand the load.
I distinctly remember a very expensive box with a lot of hard disks inside called Abekas. It was the end-all digital recorder of the early 90s. Pretty cool stuff.
"VCR single tasking != DVR multitasking"
So, they patented having two VCRs (or a double-deck).
I am sure my video rig of the early 90s could be considered prior art.
When the only tool you have is a hammer, everything looks like a nail.
Both C and C++ are useful for what they were designed. But that's it. If you find yourself using them for problems they were not designed to handle, I strongly suggest trying other tools.
And, BTW, C++ is plain ugly. Objective-C got it right.
I am sorry for your suffering. I too have used Irix, HP-UX, AIX and Solaris (and OSX without Fink) a lot.
It's next to unbearable.
Aw... Come on... Can't be much less painful than "apt-get install python2.4"
"So, what exactly is Python missing here, oh wise and mighty smartass C programmer?"
You know... Bragging about knowing C is the telltale sign of a very limited programmer. People brag about Lisp or Smalltalk or even Objective-C. Knowing C is not a reason to brag - it's the bare minimum one should know to be called a programmer.
Far too many people regard C as the end of the path. It's only when you have passed it that you realize it lays pretty much in the beginning.
This is absolutely painless in any modern Linux distro. Here I have both python2.4 and python2.5 in /usr/bin and a symlink at /usr/bin/python leading to one of them. All I had to do was to install the "python-2.4" (or something like it) package. Nothing broke. If I had something that broke under 2.5, I could change the #! line to read "python2.4" instead of "python" and everybody would be happy again.
It wouldn't be painful even if I were to hand-compile my own versions - some masochistic thing I am not inclined to do.
There is no need to panic. The Python crew knows fairly well what they are doing.
Still, nobody is forcing you to adopt 3.0 the day it's released. I run Python 2.4 and 2.5 on the same box (along about half a dozen combinations of Zope and Plone) and they seem to play very, very well together.
the fact 3.0 will become available will not break 2.x code overnight. No need to panic.
You forgot PC-DOS ;-)
Sorry to burst your bubble, but:
- Dell pretty much invented the large-scale direct sales built-to-order PC business.
- Compaq did invent the PC-compatible - different enough not to get sued out of existence, similar enough it runs the same software
- HP did invent a lot of stuff in the personal computer arena
- Apple did invent lots of stuff in the GUI arena. Have you seen Smalltalk 80 and how Lisa is different from that?
Microsoft did invent a lot too. It's unfair to judge the value of all company's contributions by its current delinquent behaviour (the one you call "smart").
Interesting...
:-)
I am sure it was not there a couple hours ago. Also, the availability was quite different.
OTOH. It seems I helped sell a couple books.
Only used ones. It's no longer in print.
The cover picture was snapped from a seller's copy.
A couple years back, I got, for my birthday, a book called "Programmers at Work", edited by Microsoft Press. The book is a collection of interviews of programmers ranging from Andy Hertzfeld, Gary Kildall and Butler Lampson all the way to Bill Gates.
I strongly suspect it's not available today and never again will be printed in this form, mainly because in his interview, Bill Gates said:
Interviewer: Is studying computer science the best way to prepare to be a programmer?
Bill Gates: No. the best way to prepare is to write programs, and to study great programs that other people have written. In my case, I went to the garbage cans at the Computer Science Center and I fished out listings of their operating system. You got to be willing to read other people's code, then write your own, then have other people review your code. You've got to want to be in this incredible feedback loop where you get the world-class people to tell you what you're doing wrong.
You have to love the fine irony.
I am sure one of the design goals of QNX was to resemble Unix as much as possible without compromising the real-time features. Being unix-ish made it a lot easier to program for.
Besides that, it had "vi", "cc" and lots of the nice stuff you would expect on a Unix box.
And, BTW, Unix was really spartan those days. The next two Unix-likes I used were on green-screen text-only terminals on multi-user boxes that had a serial console port. GUIs were something reserved for high-end workstations costing tens of thousands of dollars.
"Now, contemporaneous with the C64 in the Apple stable was the IIGS"
Well... The 64 was launched years before the IIGS. By that time, I think Apple had the III (///?) which was not suitable for any games. Heck - it was not suitable for many Apple II software titles.
The 64 was a really amazing machine for the time. 64 KB and color graphics was amazingly cool.
And, well, before the 64 they had the VIC-20.