So, as http://en.wikipedia.org/wiki/MMX says, MMX was the first SIMD extension to x86. People were not abusing the FPU - MMX instructions were present in every processor that was SIMD-capable.
The fact MMX shared the FPU registers in a different way does not make pre-MMX CPUs SIMD-capable.
Not to mention the fact that with both Caldera and Novell having common roots Caldera could easily have been the Linux company that Novell snapped up, had it not been for the fact that the two companies were already locked in litigation.
To be locked in litigation is not a problem. Remember - it's about money and power, not honour.
In fact, buying some litigant to make the lawsuit go away is acceptable business practice.
You can compress the memory dump so it takes up less space. If you achieve a 2 to 1 ratio, you can cram 512 megs of RAM into 256 megs of flash. You also invalidate any buffers and caches you may have active so that only programs and data is dumped.
If Munin is right about my computer, there are 341 megs serving as caches and 51 megs used as buffers. If I am reading the graph correctly, I am using just over 400 megs for programs and working data. I am not touching the swap file.
Another optimization would be to give more importance to foreground programs than to servers and restart them after you can safely restart the more interactive parts.
Of course, if Linux can't do this, these drives are useless to me.
There is one brief moment in the movie, when Pris tries to break Deckard's neck (or crush his head, I can't remember exactly) and she looks puzzled as how he just doesn't die like other humans do.
Thanks for the pointers. Nothing like a market to set things straight.
Still, e-boook readers (with big screens) are pretty much dead. That's sad.
I really wanted one that could double as a printer (attach to the computer - usb or wireless - print to it and, maybe later, attach to printer and produce hard-copy). Can't be that hard.
The main problem with e-Books is not the screen. It's the publishers that are so scared everyone will pirate their goods they boost their profit margins - setting the price for the electronic-only book at just about the same as the printed version thus ignoring the savings in production and transport - and cripple them with DRM that would piss off even a RIAA lawyer who had to use one.
Incremental compilation and inspecting the contents of a "live" object are fine - I remember them from my Smalltalk days. Unfortunately, the kind of IDE that allows it is huge (right now, Eclipse is taking 146 megabytes of RAM on my development box) and completely beyond what I expect to be available to OLPC computers.
Consistency is a strong point for Java. It is less consistent than some other languages - I like the "everything is an object" approach for teaching. I wouldn't want to explain primitive types.
And moving some library calls inside the language may be a good thing. Just think how regexp support within Perl or list/set/dictionary support in Python make them easy to use languages for many purposes (altough I wouldn't want to do a huge thing in Perl).
I am not sure what you call soft typing. If you are talking about "Duck-typing", I advise you to play with Python or Ruby a little. Duck typing (as in "if it walks like a duck") may make spotting problems at compile time difficult, but they make for more natural development on many other instances. With Java I often spend 50% of the time setting up "safety nets" for typing, potential problems and such.
By all means, grab one of these "newer" languages (Python is older than Java, AFAIK and Smalltalk is the granddaddy of OOP) and play with them. Always keep your mind set on how a child migh relate to what is on screen.
You will realise there are many better tools to teach programming just like there are many ways to teach how to cut trees better (and safer) than a chainsaw.
Honestly, I think that the edit-compile-test cycle is scary and the verborragic syntax does little to help. IDEs make it bearable, but it does not lend itself to experimentation. Java may be a much better way to start programming than basic, but I think that teaching the simple concepts with a language better suited fot tinkering is a better approach. I too learned with Basic (on the Apple II). I did some programming with a TI-55 calculator before, but I consider Applesoft Basic my baptism.
Those who want to go deeper can learn Java, C++ or whatever they want afterwards.
And, besides that, when you learn a different language, you become a better programmer. IIRC, Eric Raymond recomends Lisp - and I agree it is a deeply enlightening experience. I recommend Python because I can do a lot of experimentation from within the runtime and being able to watch inside objects is crucial when you are learning to program.
I am sure that if you can picture a version of yourself who only saw Java. I am also sure that alter-you would be a very bad programmer.
We are talking about teaching kids, not building complex programs with huge teams, unless you want to employ child-labor in developing countries;-)
Every programming language we mentioned in this thread has specific strenghts and weaknesses. I like the way you can express some low-level concepts and to naturally build up your program with FORTH. I love the way you can inspect just about everything in Smalltalk and the clever way you can add and remove attributes of a live object in Python. Java is a natural choice for huge teams and a much more comfortable C++ than C++.
But the OLPC is an educational tool. We should keep that in mind.
Oh, and on top of that, to say something like java will scare kids away reveals much more about what kind of a programmer you are than I'd personally be comfortable with myself.
I am the kind of programmer that would prefer kids not to be introduced to a write-compile-test cycle that only an IDE makes bearable.
Java is primitive by most modern standards. It even looks primitive if you compare it to the Smalltalk we had in the 80s. Go teach them Python, Boo or Ruby. Or start them up with something simple like Forth or Logo. Then, if they really want it, let them go the Java/C/C++ route.
Java is very powefull (I use it every day), but it evidently is not the best way to teach programming to a kid.
I seriously doubt the current implementation of Java would fit inside a 400 MHz x86 computer that's designed more to be energy-efficient and small than to be fast.
If Java is to run on the OLPC computer, it needs a smaller, simpler implementation. Sun provides all information neccessary to build one. It's up to Red Hat or any one other than them to make it.
And, BTW, teaching Java to kids?! What do you want? To scare them away?
Re:Some monetary reasons to return to the moon
on
Back to the Moon
·
· Score: 3, Insightful
Do you have any idea of how much regolith you would have to process in order to get a ton of He3?
And by "process" I mean "extract it, transport it to H3 extraction facilities, grind it, bake it and get rid of the waste". Those facilities will need to be huge (because they have to process a huge amount of rock), built there with local materials (which, in turn, will have to be made there in factories built here), supplied with power, and, unless we advance robotics substantially, manned.
All that assuming we can do He3 fusion on industrial scale at all.
Re:Where do you GET the Hydrogen?
on
"H-Prize" Announced
·
· Score: 4, Insightful
Right on the spot.
You can't grow hydrogen trees or dig the ground looking for it. Just about all the hydrogen around us (and yes, there is a lot of it) is combined to Oxygen or Carbon. In order to burn it (a fuel-cell is sort of like burning, without flames) we must first apply energy to get it loose (and, probably, release some carbon to the atmosphere in the process).
Unless they are talking table top (or "under hood") fusion, this is only an act of "look, we are concerned with the environmental"-type misdirection.
I am not sure there is a market for Unix workstations.
There are few things that spot opportunities as well as companies competing for space. The lack of offerings indicates the lack of a consumer market - it indicates that those who want non x-86 Unix-like desktops (and I would love to see a Niagara, MIPS, XCPU, Cell or ARM-based desktop computer - I love diversity) are very few.
Modern x86 PCs, as dull as they are, are quite capable Unix workstations and, in many respects, are well beyond any desktop system SGI ever made.
Slashdot Mirror
I remember how I got worried when 2 leaders with lots of nukes each argued about a spy-plane like two 8-year-old boys.
- It fell on my backyard, so it's mine
- No. It's mine. Give it back to me.
http://news.bbc.co.uk/1/hi/in_depth/asia_pacific/So, as http://en.wikipedia.org/wiki/MMX says, MMX was the first SIMD extension to x86. People were not abusing the FPU - MMX instructions were present in every processor that was SIMD-capable.
The fact MMX shared the FPU registers in a different way does not make pre-MMX CPUs SIMD-capable.
Can you clarify this? You mean SIMD functionality was available in some (which?) CPUs _before_ SIMD instructions were added to the specs?
To be locked in litigation is not a problem. Remember - it's about money and power, not honour.
In fact, buying some litigant to make the lawsuit go away is acceptable business practice.
You can compress the memory dump so it takes up less space. If you achieve a 2 to 1 ratio, you can cram 512 megs of RAM into 256 megs of flash. You also invalidate any buffers and caches you may have active so that only programs and data is dumped.
If Munin is right about my computer, there are 341 megs serving as caches and 51 megs used as buffers. If I am reading the graph correctly, I am using just over 400 megs for programs and working data. I am not touching the swap file.
Another optimization would be to give more importance to foreground programs than to servers and restart them after you can safely restart the more interactive parts.
Of course, if Linux can't do this, these drives are useless to me.
I wonder how much Steve Ballmer charges for this
How long until Google ERP or Google CRM?
And probably invade a country or two and run for a third (gulp) term.
Maybe I should stop giving them ideas.
There is one brief moment in the movie, when Pris tries to break Deckard's neck (or crush his head, I can't remember exactly) and she looks puzzled as how he just doesn't die like other humans do.
Sci-fi (at least good sci fi) is not about predicting the future.
;-)
It's about avoiding it
Thanks for the pointers. Nothing like a market to set things straight.
Still, e-boook readers (with big screens) are pretty much dead. That's sad.
I really wanted one that could double as a printer (attach to the computer - usb or wireless - print to it and, maybe later, attach to printer and produce hard-copy). Can't be that hard.
The main problem with e-Books is not the screen. It's the publishers that are so scared everyone will pirate their goods they boost their profit margins - setting the price for the electronic-only book at just about the same as the printed version thus ignoring the savings in production and transport - and cripple them with DRM that would piss off even a RIAA lawyer who had to use one.
I think DrivesSpace's lifetime even extended well into the Windows 9x era.
Disk Doubler was Macintosh stuff. Microsoft bundled DriveSpace and DiskSpace (I never know which one came first).
;-)
If you will pretend to be ancient, do it right
Loved that
Incremental compilation and inspecting the contents of a "live" object are fine - I remember them from my Smalltalk days. Unfortunately, the kind of IDE that allows it is huge (right now, Eclipse is taking 146 megabytes of RAM on my development box) and completely beyond what I expect to be available to OLPC computers.
Consistency is a strong point for Java. It is less consistent than some other languages - I like the "everything is an object" approach for teaching. I wouldn't want to explain primitive types.
And moving some library calls inside the language may be a good thing. Just think how regexp support within Perl or list/set/dictionary support in Python make them easy to use languages for many purposes (altough I wouldn't want to do a huge thing in Perl).
I am not sure what you call soft typing. If you are talking about "Duck-typing", I advise you to play with Python or Ruby a little. Duck typing (as in "if it walks like a duck") may make spotting problems at compile time difficult, but they make for more natural development on many other instances. With Java I often spend 50% of the time setting up "safety nets" for typing, potential problems and such.
By all means, grab one of these "newer" languages (Python is older than Java, AFAIK and Smalltalk is the granddaddy of OOP) and play with them. Always keep your mind set on how a child migh relate to what is on screen.
You will realise there are many better tools to teach programming just like there are many ways to teach how to cut trees better (and safer) than a chainsaw.
Honestly, I think that the edit-compile-test cycle is scary and the verborragic syntax does little to help. IDEs make it bearable, but it does not lend itself to experimentation. Java may be a much better way to start programming than basic, but I think that teaching the simple concepts with a language better suited fot tinkering is a better approach. I too learned with Basic (on the Apple II). I did some programming with a TI-55 calculator before, but I consider Applesoft Basic my baptism.
Those who want to go deeper can learn Java, C++ or whatever they want afterwards.
And, besides that, when you learn a different language, you become a better programmer. IIRC, Eric Raymond recomends Lisp - and I agree it is a deeply enlightening experience. I recommend Python because I can do a lot of experimentation from within the runtime and being able to watch inside objects is crucial when you are learning to program.
I am sure that if you can picture a version of yourself who only saw Java. I am also sure that alter-you would be a very bad programmer.
Bill,
;-)
We are talking about teaching kids, not building complex programs with huge teams, unless you want to employ child-labor in developing countries
Every programming language we mentioned in this thread has specific strenghts and weaknesses. I like the way you can express some low-level concepts and to naturally build up your program with FORTH. I love the way you can inspect just about everything in Smalltalk and the clever way you can add and remove attributes of a live object in Python. Java is a natural choice for huge teams and a much more comfortable C++ than C++.
But the OLPC is an educational tool. We should keep that in mind.
How can it be full-featured and still run Windows? ;-)
I am the kind of programmer that would prefer kids not to be introduced to a write-compile-test cycle that only an IDE makes bearable.
Java is primitive by most modern standards. It even looks primitive if you compare it to the Smalltalk we had in the 80s. Go teach them Python, Boo or Ruby. Or start them up with something simple like Forth or Logo. Then, if they really want it, let them go the Java/C/C++ route.
Java is very powefull (I use it every day), but it evidently is not the best way to teach programming to a kid.
I seriously doubt the current implementation of Java would fit inside a 400 MHz x86 computer that's designed more to be energy-efficient and small than to be fast.
If Java is to run on the OLPC computer, it needs a smaller, simpler implementation. Sun provides all information neccessary to build one. It's up to Red Hat or any one other than them to make it.
And, BTW, teaching Java to kids?! What do you want? To scare them away?
Do you have any idea of how much regolith you would have to process in order to get a ton of He3?
And by "process" I mean "extract it, transport it to H3 extraction facilities, grind it, bake it and get rid of the waste". Those facilities will need to be huge (because they have to process a huge amount of rock), built there with local materials (which, in turn, will have to be made there in factories built here), supplied with power, and, unless we advance robotics substantially, manned.
All that assuming we can do He3 fusion on industrial scale at all.
Right on the spot.
You can't grow hydrogen trees or dig the ground looking for it. Just about all the hydrogen around us (and yes, there is a lot of it) is combined to Oxygen or Carbon. In order to burn it (a fuel-cell is sort of like burning, without flames) we must first apply energy to get it loose (and, probably, release some carbon to the atmosphere in the process).
Unless they are talking table top (or "under hood") fusion, this is only an act of "look, we are concerned with the environmental"-type misdirection.
And a remarkably dumb one.
After all, why try other energy sources when you can always invade oil producers searching for their weapons of mass destruction?
I am not sure there is a market for Unix workstations.
There are few things that spot opportunities as well as companies competing for space. The lack of offerings indicates the lack of a consumer market - it indicates that those who want non x-86 Unix-like desktops (and I would love to see a Niagara, MIPS, XCPU, Cell or ARM-based desktop computer - I love diversity) are very few.
Modern x86 PCs, as dull as they are, are quite capable Unix workstations and, in many respects, are well beyond any desktop system SGI ever made.