Tim Sweeney's View of Programming Languages
on
Beyond Java
·
· Score: 1
At the POPL 2006 (Symposium on Principles of Programming Languages, an academic conference) last month, Tim Sweeney (of Epic Games and Unreal Engine fame) gave an invited talk on the future of programming languages. You can read his slides online.
It is worth noting that he seems to think that static types, particularly an expressive dependent type system, is the way to go for the future of game development.
Anyone with half a brain knows he was being sarcastic and I see nothing wrong with the informative moderation. Why do you think one can't use sarcasm to inform?
Because "Informative" indicates that the comment conveys accurate and useful information, and here sarcasm involves making false statements deliberately as a taunt.
Sure, if you already know about Turing Award, you can recognize the comment as sarcastic, but then the comment would not be very informative (since you know all that already). If you have never heard of the Turing Award before, then you would get the wrong idea from that comment. Informing only people already in the know hardly qualifies as Informative.
Please also keep in mind that not everyone reading Slashdot is a computer scientist or in the IT business. Recognizing the original comment as sarcastic has nothing to do with brains... either you have heard of Turing Award before, or you have not.
Suppose you see a comment "Sora components are so much better than Dura-Ace" in a cycling forum marked as Informative. Can you really tell that the comment is meant as a joke? I think a Funny moderation would be more appropriate.
Who the heck moderated parent as informative? The Turing Award, issued by ACM, is the most highly regarded award in the computer science field, which means it is about as prestigious as the Nobel Prize in the physics and chemistry. This is definitely not a minor award, and whoever get it (people like Knuth and Hoare) are definitely not slackers.
(Okay, the parent post may be intentionally sarcastic, but the Informative moderation is still misleading, to say the least.)
You do not need to install a Haskell compiler or interpreter if you just want to use darcs: the Haskell code is compiled into an ELF binary executable just like any other program; thus the user will not even be able to tell that it is written in Haskell.
As far as user contributions are concerned, I agree with your point that using a less mainstream language will pose some additional difficulties and limitations. But this is entirely different from your original thesis that "Haskell just won't cut it". Whether using Haskell is a wise choice depends on whether these difficulties can be offset by other technical advantages, and from the interview, so far the developer seems to think so.
(arguments that Haskell will not cut it because it does not have a large user community)
I have to say that I am troubled by this kind of attitude, especially on Slashdot. True, open source is mostly about freedom, but it is also about diversity, about innovation, and about trying to do things the right way. Since when do we condemn a project to failure just because it makes a non-mainstream choice, even if the choice was preferred by the developers due to technical superiority?
How do you feel when PHBs assure you that bringing Linux into the server room is sure to fail because it is not mainstream like Windows?
This is the introductory computer programming textbook used at MIT, and had been featured on slashdot here. However it is very different from what you would expect from such kind of books, with Scheme as the implementation language, it really does not teach readers how to code in a specific programming language, but how to program computers in a large variety of paradigms, what are the trade-offs in program design, how to manage complexity, and how the basics of computing works, by stretching the flexibility of the Lisp family of languages to the maximum. I first read it four years ago as a freshman, and it was a real eye opener. And it never ceased to amaze me through all these years, as I continue to discover new insights in the passages.
You can almost find a full undergrad CS program concentrated in this book, with topics including language design and computing paradigms (object-oriented, functional, imperative, non-deterministic and logic programming, as well as lazy evaluation), operating systems (issues of concurrency), architecture (the design of a register machine), and compiler construction (the reader is asked to build a Scheme compiler in the end). Instead of being filled with buzzwords, here you are shown how the basics of everything works, in ways that you can really understand. Working through this book will teach you concepts that many people with a CS degree had never heard of.
Hell, if I could only save one CS book when the world comes to an end, this would be the one. And the best part is: you can get the full-text online here at MIT Press. Definitely a must read.
That still sounds like awfully lots of energy, and I don't think we are going to harvest that much energy from the ocean -- ever. It is like saying "if we could harvest 0.1% of all the energy output of our sun..."; the problem is not that collecting that much energy will harm the environment or something like that (which may still be possible, since energy circulation in the ocean is tightly coupled with the weather patterns on the planet), it is that we simply cannot do that due to the energy distribution in the sea. My $.02.
What about information storage?
on
Quantum Security
·
· Score: 1
All the talk that quantum physics can help us build ultra secure communication channels solved just half of our problems -- it can only be used for communication, but in practice encryption is used to keep data secure through both space (i.e., secure communication) and time (i.e., secure data storage). All quantum cryptography literatures I have seen seemed to have said nothing about building the ultra secure data storage system. And let's not forget, unless information exchange is always done in real time, they got to be stored somehow, somewhere in the process of communication. Anybody have insights into this one?
Has anyone ever come up with the mods to Linux or one of the BSDs to allow for OS-level triggers on the filesystem? I would much prefer to have a syslog entry get fired off the moment that anyone opens/bin/login in O_RDWR mode than have tripwire discover it minutes later.
Yes, there is such a thing for Linux, and it is called LIDS. It is basically a kernel patch that, along with a user-mode administration program, does what you just described and much more. For example it can send a message (directly from the kernel!) to somebody on some IP address (which you preconfigured) instead of logging to syslog, also with the help of the capability support in the kernel you can limit the access to certain group of system calls. Check it out!
How good would it be for us to have the animals back without the proper environment for them to live in? Animals are not just something that run around and eat food, they are always part of the ecosystem. Without proper environmental support, they will somehow have to override their genetically-coded behavior pattern to adapt to the new environment. Otherwise they will still not be able to survive (except in the zoo, which is not all that different from extinction).
Woud you consider T-Rex to be "not extinct" if we have managed to reproduce half a dozen of them and place them in Jurassic Park? As long as they are not back into the ecosystem -- which takes more than individual animals -- it really makes no big difference.
I seem to read from my physics textbooks that thermodynamics define the minimum energy required to record a single bit of information; at 3.2 degrees Kelvin, you would need 4.4E-16 ergs to set or clear a bit. So doesn't it mean whichever way you go, storing an infinite amount of information requires an infinite amount of energy?
I recalled seeing an article on Time magazine one or two years ago, mentioning the possible application of flywheels on automobiles. The point is that with a mechanical energy storage device like that, you can easily reclaim energies from, for example, speed brakes, which are normally turned into heat and dissipated into the atmosphere.
However, there are still problems that were not satisfactorily answered AFAIK. Basically flywheels work by storing energies as kinetic energies of a spinning disk. So in order to increase the amount of energy stored, either you have to increase 1) the mass of the wheel, 2) the size (diameter) of the wheel, or 3) the spinning speed of the wheel. None of which seemed desirable.
After all, the most undesirable properties of batteries are: 1) heavy, 2) bulky, 3) potentially dangerous. Just imagine what would happen if you drop such a device to the floor with an 1 Kg plate spinning at over 10K rpm... you get the idea.
Or suppose you're some big-headed gray alien orbiting the Earth in your UFO, ready to abduct some cattle. You lean out the airlock to take a piss, when suddenly -- BAM! -- the Hubble Space Telescope captures you on film. Talk about humiliating.
Just when I thought that we already have more than enough overclocking news stories (on/. and everywhere else), here comes another one. What makes it worse is that it is not even a true overclocking news story at all: first, it has nothing to do with overclocking, second, this is not news, third, there is barely a story in this one -- at least not in the way it is presented.
Let's tackle the easy one first: the "news" part. As many have already pointed out, this is hardly news for anyone who knows his way around the field of modern physics. Even if you do not major in physics or read journals each month, you are supposed to remember that three researchers, Steve Chu, Claude Cohen-Tannoudji, and William D. Phillips received the 1997 Nobel Prize in Physics specifically for the development in laser cooling. I could understand that the editors at HOCP might not have the time or expertise to realize this fact (besides, they never really mentioned overclocking), and I could understand that some readers of/. might be unaware of such fact. But I really expect a lot more from our/. editors. If we need to post science stories, get somebody who knows the business instead of letting stuff posted just because some layman think it's "cool". It is unlikely that we cannot afford it, right?
Second, laser cooling has absolutely nothing to do with overclocking. This is pretty easy to understand after you see what the technology is all about. (I am not a physics major, but have read quite a lot about it a while ago when conducting some research. Still, please correct me if I am wrong.) There are a lot of ways to cooling, and most of them are based on the idea of using something colder to absorb the heat from the object we intend to cool. This works nice under normal conditions, but fails miserably when you need to cool something from 0.1K to 0.000001K -- because there is nothing cooler out there.
Microscopically, heat is represented by the vibration of molecules. The greater the vibration, the hotter it is. So if we could somehow reduce the vibration of molecules, we can effectively cool it. That is where laser comes in. When you have got hold of the vibration pattern of a molecule (or a small group of them), all you need to do is to fire a small burst of laser and use the momentum of the photons to cancel the momemtum of the atoms. So the atoms will slow down, and its temperature will reduce.
Obviously you do not want to (and cannot) do this with your processor, because it is too large, and freezing it to 0.000001K will do more harm than good. From another point of view, it is time for people to realize that there are much more forms of cooling in the field of science and engineering (cooling atoms to absolutely zero, cooling plasmas from destroying the whole research facility, cooling mirrors in high-energy laser facilities, etc.), most of which really have nothing to do with processors. It is naive to think otherwise.
Get a life, people. I mean a real one. If you do not wish to do that, maybe you should spend some of the time you saved and go study.
Anybody remember the NHAA Project from CMU back in 1995? An autonomous steering vehicle took two Robotics Institute researchers all the way from Pittsburgh to San Diego, with the computer program RALPH steering more than 99% of the time. Granted, the people have to handle the throttle and brakes, and it only works out on highways, but that is still quite amazing considering that took place some fregging 5 years ago.
As many people have pointed out, viruses should not pose a big threat to Linux systems. Most Windows viruses propogate through SEX (Software EXchange) activities, where binaries carrying the virus are passed from one system to another by careless users. But for an open source environment like we are having under Linux, most people obtain binaries from trusted sources, thus making it much more difficult for viruses to transport this way. (The FreeBSD ports even do not transport binaries from remote hosts.)
However, that was for the stand alone systems of the past. Now since a great number of computers are wired to the Internet, especially Linux systems will likely be used to provide one sort of network service or another, worms (like the famous rtm worm) might turn out to be the greatest threat we will face in the future.
Implementing one may not be as hard as you might think. First, monitor bugtraq on a daily basis (well, securityfocus will also do), and you will likely to spot a new remote buffer overflow vulnerability within a month or two. You should be able to find the exploit (either verbal description or source code) with it, and that is where you will start. Write some code to activate the exploit against a remote host, and change the shell code to something that plants the worm into the target system. If you are in good spirits, you may even incorporate a root kit into your worm, but I can imagine infecting binaries should be good enough in most cases.
Ask yourself why script kiddies are called script kiddies: because what they do usually requires little intelligence. In other words, you can write a program to do exactly the same things. The can be automated. That is what makes it a genuine threat to us Linux folks.
Of course, I believe most/.ers can (and will) secure their own systems, but the problem is that there are many people who are not as capable as we are, or simply does not give a damn about security issues. They might be convinced that buying (or maybe even pirating) some "security software" will be enough to secure their system, just like back in the Windows days. Wrong. Bad management also contributes greatly to the problem. Just look how many systems are open to third-party mail relays... these systems are almost always important production network servers, something that people will *pay* others to administer. If they cannot even seal this trivial hole in their system, then how about real security problems? How about other "less important" systems that nobody looks after?
If you were to attempt to build up an OS to the level of Linux, from scratch, it would likely take you a decade. For what purpose? To end up with something that is a moderate improvement? Why not just improve what we've got?
There is a good reason: diversity. Sure, there are always room for improvement, and things are indeed constantly getting better, but nevertheless changes made are always restricted to the original design. There is no way around it. Even though many people can make many different changes to the current solution, they are still bounded and will be somewhat alike each other, especially taking into consideration that source-level compatibility needs to be maintained in the process. We can never expect drastic changes from small steps.
I know that "if it ain't broke, don't fix it" is the standard engineering practice (and rightfully so), and I do not think that people should always do everything from scratch. But if you look into the big picture, maintaining high diversity is the utmost concern if any field is to phosperous in the long run. All the biologists in the world will tell you that the loss of DNA diversity (as now taking place in the rain forest) can be the greatest loss for the future generations, and they are hard to make up --- forest can be regrown, and greenhouse gases will clear itself from the atmosphere within decades (if we stop sending more of that up, that is). But diversity, once lost, will not recover within thousands of years.
It is the same here in the software business. If you want to thrive *now*, patching up current design is the best way to go. But if you want to be able to survive and phosperous for a long, long time, we must have a great level of diversity, and some of that will undoubtedly involving doing things from scratch. That is the way it works.
True, these works will lag far behind the current state of art. I agree with that. But you can also say the same thing about mammals some 65 million years ago. Diversity saved the day. Diversity is good for life. Diversity is good for us.
You have to know that this is not going to solve all of your problems. Sure, a common low-level standard toward the storage of information on PDA devices is definitely the first step toward the complete solution, but this step is, hmm, tiny.
Take the large PCs we all use today for example. Sure, we have common standards for information transportation --- floppy disks with FAT filesystems is readable almost everywhere, and TCP/IP protocol is an universal language. However, we still have problems exchanging information with other people, especially one uses open source software and the other does not. Like I always said, if someone dare to mail me Word or Excel files, I will type my reply in LaTeX, and send the bzip2ed DVI file back. High, application level standard will be the key to the problem.
Undoubtedly that will not be easy. Perhaps this is the time for us to push open source sofware on those platforms.
Re:Garbage Collection is for Incompetent Programme
on
The New Garbage Man
·
· Score: 1
GC for procedural code is optional. A good idea, IMHO- but still optional. If worse comes to worse, you can always "bubble up" responsibility for deallocating the memory to the block in which encompasses the entire lifetime of the memory.
Yes, you can always pull of some smart trick in *theory*, but does that really work in practice? Determining which block of memory can be freed at which time automatically will require global flow analysis to the program, and in my opinion that is simply not feasible for imperative languages like C. Even if you could somehow do that (which means you should receive Alan M. Turing award say, in the next ten years or so), current seperate-compile standards (object file formats) will not be able to support this kind of operation. The buttom line? This will not work in practice. Maybe not even in theory.
Computer scientists all over the world are now having great fun solving a relatively easy problem: to perform global flow analysis and find anything interesting from programs written in a pure lazy functional language (like Haskell). Even seemly trivial properties like "is the use of arrays serialized in this program?" will take too much computational power to determine so that the algorithm turns out to be useless in practice (such a property would allow destructive updates for arrays, a big performance win).
Do not underestimate the difficulty of program analysis. You make think they are easy, but hell, you make mistakes all the time, so that does not count.
There seems to be a number of misconceptions as to what this is all about or how might it be useful in practice. I will offer some opinions on some of the issues raised in other posts.
The first one, as already mentioned by a number of people, is that hardware implementation of malloc and free has nothing to do with GC. The most difficult part of GC is to determine which part of the memory is garbage (this is not as easy as it may seem) without using lots of memory (after all, garbage collectors are typically only activated when free memory blocks are running low), and for those garbage collectors running as an independent thread, avoid possible race conditions with the foreground processes. Other issues a garbage collector faces include how to reduce the impact on overall system performance, and how to decrease memory fragmentation.
A garbage collector is not something easy to design and implement. Making a good garbage collector especially requires the almost-impossible combination of profound understanding in the memory usage behavior of typical programs, logical reasoning abilities, and coding techniques. In addition to the garbage collector itself, you also need support from the language and compiler side, and you have to integrate all of these into a clean design. That is about as hard as things like this can be.
(Of course, you can also write a conservative pointer finding GC like the libgc used by many functional language compilers --- but that is far from the state of art in this business.)
The proposed hardware support has nothing to do with the points we mentioned above, therefore has nothing to do with GC. Then, is it possible to build some hardware support for garbage collection? Maybe, but I am not an expert in this field. Whatever the solution turns out to be, it will never be as simple as hardware implementation of malloc and free.
Second, this also has nothing to do with real time systems. Many people seems to think that being "real time" means you have to code everything in assembly language and make things run as fast as possible, but that is simply not true. Being (hard) real time means operations must respond and complete within bounded time; as long as that bound is satisfied, there is no need for the task be completed "very fast". The trick of building real time systems is in making sure that nothing will delay the operation for a long time, and that requires careful analysis and implementation.
If you remain to be convinced, think of a typical hard real time application: CD-R burning control programs. They must feed a continuous stream of data (say, 600KB/s for 4X burning) into the burner, or the disk will turn into a coaster. Is it necessary to code it in assembly? Absolutely not, because pumping data at 600KB/s is very little work for current architectures with 600MHz processors and 100MHz memory busses. However, does that mean you do not need to pay special attention to make it real time? Wrong, because although the hardware is several orders of magnitudes more powerful than it needs to be, there are still possibilities that something will make the program stop working for a second or two and screw the party. It is the responsibility of real time system designers to make sure that it does not happen.
Sure, everything is possible. Aside from political and business interest concerns, I think the technical issues alone would be sufficient to make a Linux port to Office a major headache. Why? Because Office made heavy use of operating system infrastructures not yet available on Linux.
I am not an Office guru, but it should be no surprise to see that Office needs COM, OLE, VBScript and maybe lots of different FoobarX to survive and stay functional. And that is where the problem comes --- not much of that (if any) is available under Linux. Does anyone know how the source-level Windows compatible library is supposed to solve that kind of problem?
Slashdot Mirror
At the POPL 2006 (Symposium on Principles of Programming Languages, an academic conference) last month, Tim Sweeney (of Epic Games and Unreal Engine fame) gave an invited talk on the future of programming languages. You can read his slides online.
It is worth noting that he seems to think that static types, particularly an expressive dependent type system, is the way to go for the future of game development.
Anyone with half a brain knows he was being sarcastic and I see nothing wrong with the informative moderation. Why do you think one can't use sarcasm to inform?
Because "Informative" indicates that the comment conveys accurate and useful information, and here sarcasm involves making false statements deliberately as a taunt.
Sure, if you already know about Turing Award, you can recognize the comment as sarcastic, but then the comment would not be very informative (since you know all that already). If you have never heard of the Turing Award before, then you would get the wrong idea from that comment. Informing only people already in the know hardly qualifies as Informative.
Please also keep in mind that not everyone reading Slashdot is a computer scientist or in the IT business. Recognizing the original comment as sarcastic has nothing to do with brains... either you have heard of Turing Award before, or you have not.
Suppose you see a comment "Sora components are so much better than Dura-Ace" in a cycling forum marked as Informative. Can you really tell that the comment is meant as a joke? I think a Funny moderation would be more appropriate.
Who the heck moderated parent as informative? The Turing Award, issued by ACM, is the most highly regarded award in the computer science field, which means it is about as prestigious as the Nobel Prize in the physics and chemistry. This is definitely not a minor award, and whoever get it (people like Knuth and Hoare) are definitely not slackers.
(Okay, the parent post may be intentionally sarcastic, but the Informative moderation is still misleading, to say the least.)
So instead of VOIP, you are getting IPOV? Marvelous!
You do not need to install a Haskell compiler or interpreter if you just want to use darcs: the Haskell code is compiled into an ELF binary executable just like any other program; thus the user will not even be able to tell that it is written in Haskell.
As far as user contributions are concerned, I agree with your point that using a less mainstream language will pose some additional difficulties and limitations. But this is entirely different from your original thesis that "Haskell just won't cut it". Whether using Haskell is a wise choice depends on whether these difficulties can be offset by other technical advantages, and from the interview, so far the developer seems to think so.
I have to say that I am troubled by this kind of attitude, especially on Slashdot. True, open source is mostly about freedom, but it is also about diversity, about innovation, and about trying to do things the right way. Since when do we condemn a project to failure just because it makes a non-mainstream choice, even if the choice was preferred by the developers due to technical superiority?
How do you feel when PHBs assure you that bringing Linux into the server room is sure to fail because it is not mainstream like Windows?
Since when do we let that stop us?
Insufficient data for meaningful answer.
Isaac Asimov, The Last Question
This is the introductory computer programming textbook used at MIT, and had been featured on slashdot here. However it is very different from what you would expect from such kind of books, with Scheme as the implementation language, it really does not teach readers how to code in a specific programming language, but how to program computers in a large variety of paradigms, what are the trade-offs in program design, how to manage complexity, and how the basics of computing works, by stretching the flexibility of the Lisp family of languages to the maximum. I first read it four years ago as a freshman, and it was a real eye opener. And it never ceased to amaze me through all these years, as I continue to discover new insights in the passages.
You can almost find a full undergrad CS program concentrated in this book, with topics including language design and computing paradigms (object-oriented, functional, imperative, non-deterministic and logic programming, as well as lazy evaluation), operating systems (issues of concurrency), architecture (the design of a register machine), and compiler construction (the reader is asked to build a Scheme compiler in the end). Instead of being filled with buzzwords, here you are shown how the basics of everything works, in ways that you can really understand. Working through this book will teach you concepts that many people with a CS degree had never heard of.
Hell, if I could only save one CS book when the world comes to an end, this would be the one. And the best part is: you can get the full-text online here at MIT Press. Definitely a must read.
That still sounds like awfully lots of energy, and I don't think we are going to harvest that much energy from the ocean -- ever. It is like saying "if we could harvest 0.1% of all the energy output of our sun..."; the problem is not that collecting that much energy will harm the environment or something like that (which may still be possible, since energy circulation in the ocean is tightly coupled with the weather patterns on the planet), it is that we simply cannot do that due to the energy distribution in the sea. My $.02.
All the talk that quantum physics can help us build ultra secure communication channels solved just half of our problems -- it can only be used for communication, but in practice encryption is used to keep data secure through both space (i.e., secure communication) and time (i.e., secure data storage). All quantum cryptography literatures I have seen seemed to have said nothing about building the ultra secure data storage system. And let's not forget, unless information exchange is always done in real time, they got to be stored somehow, somewhere in the process of communication. Anybody have insights into this one?
Yes, there is such a thing for Linux, and it is called LIDS. It is basically a kernel patch that, along with a user-mode administration program, does what you just described and much more. For example it can send a message (directly from the kernel!) to somebody on some IP address (which you preconfigured) instead of logging to syslog, also with the help of the capability support in the kernel you can limit the access to certain group of system calls. Check it out!
How good would it be for us to have the animals back without the proper environment for them to live in? Animals are not just something that run around and eat food, they are always part of the ecosystem. Without proper environmental support, they will somehow have to override their genetically-coded behavior pattern to adapt to the new environment. Otherwise they will still not be able to survive (except in the zoo, which is not all that different from extinction).
Woud you consider T-Rex to be "not extinct" if we have managed to reproduce half a dozen of them and place them in Jurassic Park? As long as they are not back into the ecosystem -- which takes more than individual animals -- it really makes no big difference.
I seem to read from my physics textbooks that thermodynamics define the minimum energy required to record a single bit of information; at 3.2 degrees Kelvin, you would need 4.4E-16 ergs to set or clear a bit. So doesn't it mean whichever way you go, storing an infinite amount of information requires an infinite amount of energy?
I recalled seeing an article on Time magazine one or two years ago, mentioning the possible application of flywheels on automobiles. The point is that with a mechanical energy storage device like that, you can easily reclaim energies from, for example, speed brakes, which are normally turned into heat and dissipated into the atmosphere.
However, there are still problems that were not satisfactorily answered AFAIK. Basically flywheels work by storing energies as kinetic energies of a spinning disk. So in order to increase the amount of energy stored, either you have to increase 1) the mass of the wheel, 2) the size (diameter) of the wheel, or 3) the spinning speed of the wheel. None of which seemed desirable.
After all, the most undesirable properties of batteries are: 1) heavy, 2) bulky, 3) potentially dangerous. Just imagine what would happen if you drop such a device to the floor with an 1 Kg plate spinning at over 10K rpm... you get the idea.
Anybody have insights into this one?
Or suppose you're some big-headed gray alien orbiting the Earth in your UFO, ready to abduct some cattle. You lean out the airlock to take a piss, when suddenly -- BAM! -- the Hubble Space Telescope captures you on film. Talk about humiliating.
Yeah, especially considering that they might have just nailed SETI's Rand Wilson Telescope in South Africa.
... considering what had just happened to the Rand Wilson telescope a couple of days ago.
Just when I thought that we already have more than enough overclocking news stories (on /. and everywhere else), here comes another one. What makes it worse is that it is not even a true overclocking news story at all: first, it has nothing to do with overclocking, second, this is not news, third, there is barely a story in this one -- at least not in the way it is presented.
Let's tackle the easy one first: the "news" part. As many have already pointed out, this is hardly news for anyone who knows his way around the field of modern physics. Even if you do not major in physics or read journals each month, you are supposed to remember that three researchers, Steve Chu, Claude Cohen-Tannoudji, and William D. Phillips received the 1997 Nobel Prize in Physics specifically for the development in laser cooling. I could understand that the editors at HOCP might not have the time or expertise to realize this fact (besides, they never really mentioned overclocking), and I could understand that some readers of /. might be unaware of such fact. But I really expect a lot more from our /. editors. If we need to post science stories, get somebody who knows the business instead of letting stuff posted just because some layman think it's "cool". It is unlikely that we cannot afford it, right?
Second, laser cooling has absolutely nothing to do with overclocking. This is pretty easy to understand after you see what the technology is all about. (I am not a physics major, but have read quite a lot about it a while ago when conducting some research. Still, please correct me if I am wrong.) There are a lot of ways to cooling, and most of them are based on the idea of using something colder to absorb the heat from the object we intend to cool. This works nice under normal conditions, but fails miserably when you need to cool something from 0.1K to 0.000001K -- because there is nothing cooler out there.
Microscopically, heat is represented by the vibration of molecules. The greater the vibration, the hotter it is. So if we could somehow reduce the vibration of molecules, we can effectively cool it. That is where laser comes in. When you have got hold of the vibration pattern of a molecule (or a small group of them), all you need to do is to fire a small burst of laser and use the momentum of the photons to cancel the momemtum of the atoms. So the atoms will slow down, and its temperature will reduce.
Obviously you do not want to (and cannot) do this with your processor, because it is too large, and freezing it to 0.000001K will do more harm than good. From another point of view, it is time for people to realize that there are much more forms of cooling in the field of science and engineering (cooling atoms to absolutely zero, cooling plasmas from destroying the whole research facility, cooling mirrors in high-energy laser facilities, etc.), most of which really have nothing to do with processors. It is naive to think otherwise.
Get a life, people. I mean a real one. If you do not wish to do that, maybe you should spend some of the time you saved and go study.
Anybody remember the NHAA Project from CMU back in 1995? An autonomous steering vehicle took two Robotics Institute researchers all the way from Pittsburgh to San Diego, with the computer program RALPH steering more than 99% of the time. Granted, the people have to handle the throttle and brakes, and it only works out on highways, but that is still quite amazing considering that took place some fregging 5 years ago.
Huh? I thought only GNU's Not Unix.
As many people have pointed out, viruses should not pose a big threat to Linux systems. Most Windows viruses propogate through SEX (Software EXchange) activities, where binaries carrying the virus are passed from one system to another by careless users. But for an open source environment like we are having under Linux, most people obtain binaries from trusted sources, thus making it much more difficult for viruses to transport this way. (The FreeBSD ports even do not transport binaries from remote hosts.)
However, that was for the stand alone systems of the past. Now since a great number of computers are wired to the Internet, especially Linux systems will likely be used to provide one sort of network service or another, worms (like the famous rtm worm) might turn out to be the greatest threat we will face in the future.
Implementing one may not be as hard as you might think. First, monitor bugtraq on a daily basis (well, securityfocus will also do), and you will likely to spot a new remote buffer overflow vulnerability within a month or two. You should be able to find the exploit (either verbal description or source code) with it, and that is where you will start. Write some code to activate the exploit against a remote host, and change the shell code to something that plants the worm into the target system. If you are in good spirits, you may even incorporate a root kit into your worm, but I can imagine infecting binaries should be good enough in most cases.
Ask yourself why script kiddies are called script kiddies: because what they do usually requires little intelligence. In other words, you can write a program to do exactly the same things. The can be automated. That is what makes it a genuine threat to us Linux folks.
Of course, I believe most /.ers can (and will) secure their own systems, but the problem is that there are many people who are not as capable as we are, or simply does not give a damn about security issues. They might be convinced that buying (or maybe even pirating) some "security software" will be enough to secure their system, just like back in the Windows days. Wrong. Bad management also contributes greatly to the problem. Just look how many systems are open to third-party mail relays... these systems are almost always important production network servers, something that people will *pay* others to administer. If they cannot even seal this trivial hole in their system, then how about real security problems? How about other "less important" systems that nobody looks after?
There is a good reason: diversity. Sure, there are always room for improvement, and things are indeed constantly getting better, but nevertheless changes made are always restricted to the original design. There is no way around it. Even though many people can make many different changes to the current solution, they are still bounded and will be somewhat alike each other, especially taking into consideration that source-level compatibility needs to be maintained in the process. We can never expect drastic changes from small steps.
I know that "if it ain't broke, don't fix it" is the standard engineering practice (and rightfully so), and I do not think that people should always do everything from scratch. But if you look into the big picture, maintaining high diversity is the utmost concern if any field is to phosperous in the long run. All the biologists in the world will tell you that the loss of DNA diversity (as now taking place in the rain forest) can be the greatest loss for the future generations, and they are hard to make up --- forest can be regrown, and greenhouse gases will clear itself from the atmosphere within decades (if we stop sending more of that up, that is). But diversity, once lost, will not recover within thousands of years.
It is the same here in the software business. If you want to thrive *now*, patching up current design is the best way to go. But if you want to be able to survive and phosperous for a long, long time, we must have a great level of diversity, and some of that will undoubtedly involving doing things from scratch. That is the way it works.
True, these works will lag far behind the current state of art. I agree with that. But you can also say the same thing about mammals some 65 million years ago. Diversity saved the day. Diversity is good for life. Diversity is good for us.
You have to know that this is not going to solve all of your problems. Sure, a common low-level standard toward the storage of information on PDA devices is definitely the first step toward the complete solution, but this step is, hmm, tiny.
Take the large PCs we all use today for example. Sure, we have common standards for information transportation --- floppy disks with FAT filesystems is readable almost everywhere, and TCP/IP protocol is an universal language. However, we still have problems exchanging information with other people, especially one uses open source software and the other does not. Like I always said, if someone dare to mail me Word or Excel files, I will type my reply in LaTeX, and send the bzip2ed DVI file back. High, application level standard will be the key to the problem.
Undoubtedly that will not be easy. Perhaps this is the time for us to push open source sofware on those platforms.
Yes, you can always pull of some smart trick in *theory*, but does that really work in practice? Determining which block of memory can be freed at which time automatically will require global flow analysis to the program, and in my opinion that is simply not feasible for imperative languages like C. Even if you could somehow do that (which means you should receive Alan M. Turing award say, in the next ten years or so), current seperate-compile standards (object file formats) will not be able to support this kind of operation. The buttom line? This will not work in practice. Maybe not even in theory.
Computer scientists all over the world are now having great fun solving a relatively easy problem: to perform global flow analysis and find anything interesting from programs written in a pure lazy functional language (like Haskell). Even seemly trivial properties like "is the use of arrays serialized in this program?" will take too much computational power to determine so that the algorithm turns out to be useless in practice (such a property would allow destructive updates for arrays, a big performance win).
Do not underestimate the difficulty of program analysis. You make think they are easy, but hell, you make mistakes all the time, so that does not count.
There seems to be a number of misconceptions as to what this is all about or how might it be useful in practice. I will offer some opinions on some of the issues raised in other posts.
The first one, as already mentioned by a number of people, is that hardware implementation of malloc and free has nothing to do with GC. The most difficult part of GC is to determine which part of the memory is garbage (this is not as easy as it may seem) without using lots of memory (after all, garbage collectors are typically only activated when free memory blocks are running low), and for those garbage collectors running as an independent thread, avoid possible race conditions with the foreground processes. Other issues a garbage collector faces include how to reduce the impact on overall system performance, and how to decrease memory fragmentation.
A garbage collector is not something easy to design and implement. Making a good garbage collector especially requires the almost-impossible combination of profound understanding in the memory usage behavior of typical programs, logical reasoning abilities, and coding techniques. In addition to the garbage collector itself, you also need support from the language and compiler side, and you have to integrate all of these into a clean design. That is about as hard as things like this can be.
(Of course, you can also write a conservative pointer finding GC like the libgc used by many functional language compilers --- but that is far from the state of art in this business.)
The proposed hardware support has nothing to do with the points we mentioned above, therefore has nothing to do with GC. Then, is it possible to build some hardware support for garbage collection? Maybe, but I am not an expert in this field. Whatever the solution turns out to be, it will never be as simple as hardware implementation of malloc and free.
Second, this also has nothing to do with real time systems. Many people seems to think that being "real time" means you have to code everything in assembly language and make things run as fast as possible, but that is simply not true. Being (hard) real time means operations must respond and complete within bounded time; as long as that bound is satisfied, there is no need for the task be completed "very fast". The trick of building real time systems is in making sure that nothing will delay the operation for a long time, and that requires careful analysis and implementation.
If you remain to be convinced, think of a typical hard real time application: CD-R burning control programs. They must feed a continuous stream of data (say, 600KB/s for 4X burning) into the burner, or the disk will turn into a coaster. Is it necessary to code it in assembly? Absolutely not, because pumping data at 600KB/s is very little work for current architectures with 600MHz processors and 100MHz memory busses. However, does that mean you do not need to pay special attention to make it real time? Wrong, because although the hardware is several orders of magnitudes more powerful than it needs to be, there are still possibilities that something will make the program stop working for a second or two and screw the party. It is the responsibility of real time system designers to make sure that it does not happen.
Sure, everything is possible. Aside from political and business interest concerns, I think the technical issues alone would be sufficient to make a Linux port to Office a major headache. Why? Because Office made heavy use of operating system infrastructures not yet available on Linux.
I am not an Office guru, but it should be no surprise to see that Office needs COM, OLE, VBScript and maybe lots of different FoobarX to survive and stay functional. And that is where the problem comes --- not much of that (if any) is available under Linux. Does anyone know how the source-level Windows compatible library is supposed to solve that kind of problem?