At work we sometimes work on projects which span multiple offices. We have used a pair of Tandberg units, one sitting on our desk in California, the other sitting on a desk in New York. It is great to be able to say "hey Bob, can you explain this bit of code?" when you see that Bob is sitting at his desk and not deep in conversation with someone else. Much more productive than resorting to email, phone, or IM all the time.
Sadly, I've heard that those Tandbergs are super expensive...
Good decent people own guns in illinois and have their FOID card, but they aren't the ones doing drive by shooting or holding up liquor stores or banks.
I was amazed to read this entire article and not learn:
a) what do they do with the data they collect? I'd have loved to learn what sensor data is valuable for, and how it changes the dynamics of the race. (Who cares how many bits they ship if you have no idea if the bits are _useful_ bits?)
b) how much of an impact does this have on the race? Does this make a 1% difference in track times, 80%, something in the middle?
Anyone have a link to an article which explains _why_ they collect all this data?
Before thinking that an IFR ticket will let you fly a 182 anytime, look into the icing conditions in your area. For example, in the SF Bay Area most cloudy days occur in the winter, and a large fraction of those days are also prime icing conditions -- grounding most single engine planes. (Airliners have extensive anti-ice equipment, and usually climb or descend through the icing layer so quickly it is a non-issue.)
An IFR ticket is really educational, fun to get, and does expand your options when flying. But in many otherwise fantastic places for GA flying, it won't give you year-round on-demand transportation.
My wedding band is titanium as well. I was worried that I really wouldn't like wearing a ring, and having a light metal like titanium is awesome.
Several websites said that boonerings.com was excellent, so I got my ring there. They were right -- fast, friendly service, and the ring is exactly what I asked for. If you read through the site you will see that this guy is a geek too -- he bought a CNC milling machine to make his own bicycle parts, found that others were willing to pay him for his work, then found that making rings was more profitable than making bike parts.
The main thing I have used LaTeX for is generating conference papers (and a few journal papers and a thesis).
99% of grad student time wasted in LaTeX is spent trying to squeeze more content into a set page limit. I can't tell you how long I have spent trying to reformat tables to appear in a more compact format and still be readable, rephrasing sentences to eliminate dangling words in paragraphs, tweaking line spacing just enough to get your last 100 words to fit on the last page (while not being noticeable to reviewers), turning first names into initials in the bibtex file to shrink the references section, and when pressed hand-editing the postscript in figures to make things look better or more compact...
If you are writing text which doesn't have to meet tight formatting or page-count restraints, LaTeX can be a real joy to use. It always makes things look great. (Heck, I helped edit a non-math published book using LaTeX, and our printers were overjoyed at how easy it was to deal with our postscript.) But if you give in to the temptation to try and tell LaTeX to do something different than it wants to do, then you are in for a world of pain.
My first PC (replaced my old Amiga...) was a 486DX/33 with 8MB of RAM. Since I was a geek, I installed OS/2 2.0, Windows 3.1, and SLS Linux 0.95.3. (Aside: my mouse didn't work under Linux. So I kludged the driver to make it work, and submitted the patch to Linus. Now my name is in the kernel, on a driver for a mouse that nobody has made since 1992...)
Windows was snappy and fast. OS/2 lumbered along (it spent a lot of time swapping, since 8MB was not really enough for it). Linux was zippy fast, unless you started X -- X worked, but was pretty darn slow.
Compared to the Sun workstations at school which each had 10 NCD X-terminals slaved to them, Linux/X on this machine was fast. But compared to everything else, it was slooooow.
I have one of these machines. About a week after I got it, I lost the pen on a flight. That was an expensive mistake. If you ever lose the pen, you will find that:
a) It is difficult to find a replacement. You certainly won't find one on short notice. (I was unable to find any store in the Bay Area of California or in Pittsburgh PA that had them in stock.); and
b) They are EXPENSIVE! Replacement pens online cost at least $40.
Actually, the job market for PhDs in CS is currently very tight.
During this spring's academic hiring cycle many top universities were not even interviewing candidates, since they had no funding for teaching slots. CS enrollment is down, and this means that most schools don't need to hire new professors. At the top schools many fantastic candidates who other years would have had no problems getting a job with MIT, Stanford or CMU didn't even get interviews.
The corporate research world has also shrunk over the past few years. AT&T labs, Lucent and Xerox PARC have all shrunk dramatically or pretty much gone. HP, IBM research and Sun labs are not exactly on major hiring sprees. Microsoft research is not growing fast enough to hire all the people who lost jobs at these major labs, and the new players in town (TTI in Chicago, Seagate research and the Intel research lablets) are not big enough to hire all the talent suddenly flooding the market.
This hiring crunch is particularly hurting folks with expertise in networking, due to the flood of senior people coming from Lucent and AT&T.
The result of this is threefold: first, some companies are finding that they are having much less trouble than in the past hiring PhDs. Second, many second and third tier schools are managing to hire fantastic professors this year, instead of the usual second string candidates they manage to pick up. Third, many students are either stretching out their PhDs or taking postdocs instead of going into the job market.
Good question. If you look at the recent history of CPU design (say,
for the past 20 years), you see that the primary concern of architects
have changed with the technology over time. In the 80's any design
you came up with was limited by how many transistors you could squeeze
onto a chip, and so everyone was worried about transistor count. By the
90's the transistors became abundant and small enough that a lack of
transistors was no longer a primary concern of designers --- instead,
they were much more concerned with the wires: how to pack them in and
route the nicely, and how long it took for signals to get from one
place to another.
These days, wires are abundant, transistors are abundant, and the main
concern is power. Why?
a) GHz == Power. If you increase the clock rate, you increase the
power drawn. So every time you want to make the machine "faster", you
need to feed it more power.
b) More logic == more power. If you want to make the chip more
complex or have more cache, it will need more power. But at the
moment, it is cheaper (in terms of power) to add more logic than to
add more GHz.
So why is power a problem? How much is too much? First, let's talk
about total power: the total amount of electricity you have to feed
into the chip to keep it running. This changes depending on how you
utilize the chip, but designers have to design for the worst case.
There are two problems with total power: how do you get the
electricity into the chip, and how do you get the heat it produces off
of the chip. My understanding is that both problems are hard, but the
heat one is currently harder. If you put too much power in, you need
to get the heat out. More power == more heat. More heat == more
expensive cooling solution. For example, if you had a low power chip
you could get away with a simple and cheap heat sink. As it draws
more power you have to add expensive (and noisy!) fans. Add more
power, and you might eventually have to add a liquid cooling system,
air conditioning unit, and a bunch of plumbing. Add more power, and
perhaps you have to hire a team of workers to constantly feed dry ice
into your machine, or some other creative cooling solution. So the
fundamental problem is that once your chip draws enough power keeping
it cool becomes too expensive. Right now it looks like 100 to 150W is
the max power which can be kept cool by fan systems which are cheap
and quiet enough that people will actually buy them. Nobody wants to
buy a computer with plumbing for their home or office, liquid cooled
machines are still only used for special business applications where
they have little other choice.
Now total power is not the only problem. There is also localized
power. Think "will a portion of my chip melt into a pool of molten
silicon since I can't cool it off fast enough"? There is a nice story
of how one of the first Alpha CPU prototypes cracked in half due to
having too much power running up the middle of the chip... It turns
out that this localized heat is a major limitation these days, and is
a primary reason why Intel won't sell you a 5GHz chip. They don't
know how to avoid this problem in a reasonable way. So, instead, they
are going to improve performance by adding cores.
If you have one core, you have one central location in the chip that
is constantly working hard, and so it is generating a lot of heat.
Getting the heat away from that tiny point is hard. If you build a
chip with two cores, then you divide the work over two points, and so
each point generates half of the heat. Keeping that cool is much
easier. With four cores....etc.
A research paper at last year's ASPLOS suggested that a good way to
work this problem is to have a program run on one core until it gets
too hot, then move execution to the next core, and repeat. This way
you always have one core doing work, and the others are cooling off.
We may end up having to do this.
The advice about loans doesn't apply to a student from India. Getting a loan at any rate from a US lending institution will be very difficult or impossible unless you are a US citizen or permenant resident. They key is your lack of a "US credit history".
When I first came to the US (from Canada) to go to grad school I couldn't even get a credit card! My Canadian CitiBank Visa card meant nothing when I tried to get a US CitiBank Visa -- the banks don't know how to talk across borders. Even after 8 years in the US the banks laugh if I ask them about student loans (but the credit card companies now like me).
If you apply to PhD programs in Computer Science, expect to have them pay you enough to get by on, either through teaching or research funds. If they can't offer you that, they are probably not giving you a serious offer.
This article refers to machines equipped with TCPA, not Palladium. These are different architectures. The TCPA design is a bootstrap architecture, which means that the boot process has to be changed such that each portion of the OS is validated as it is loaded -- a task that is probably much easier to do in Linux than Windows, since you can always compile a minimal Linux system with TCPA support and not worry about portions of the kernel which support legacy hardware and software. A major design feature of Palladium is you can avoid that headache, and instead try to get a secure subsystem up and running under an already running insecure operating system.
If you want to know more about the difference, you can read an article about it here.
I am a PhD student in computer science at Carnegie Mellon. I write C++ code every day. I know at least 7 programming languages well enough to program in them professionally. For my research I design new computer hardware, compilers, database systems, and operating systems. I have helped write (non-software) patents....and I'll be damned if I can fully understand the text of most patents, including the ones cited in this article. How in the world is a software developer supposed to avoid infringing on patents if they can't _understand_ them? I don't know of any school which includes a course on "reading patent legaleese" in their computer science programs.
I have 12 years of post-high-school education in Computer Science. I have no idea how to write a non-trivial program that I am relatively sure does not infringe on any patent. I don't know anyone who does. Doesn't this seem absurd?
Depends on the machine. I once helped to run a Coke machine which took in about $2k/week. If you got into the machine at the wrong time you could have easily gotten $1k in cash... (The machine was located in a high traffic area, and most of the people around knew who was _supposed_ to be opening it, so breaking in unnoticed might be kind of hard 'tho.)
It is actually not always true that using a 64-bit address space will result in a faster program if your code needs to access more than 2GB of data.
64-bit pointers give you two things:
An easier to target programming model for large datasets
The ability to simultaneously access larger amounts of data.
Note that neither of these instantly lead to better performance -- instead, they make it easier to write programs. If you are simultaneously accessing a dataset this large (i.e., if you have such a huge working set) then your cache performance will probably suck. This will be true whether you have 32-bit or 64-bit pointers. But if you have 64-bit pointers, you will also have more data to store (since your pointers are twice as large). This may hurt performance badly.
Most programs switch to 64-bit pointers since it is easier than trying to fake a large address space throguh segments and paging. It is by no means always faster.
Before HP purchased Compaq, Compaq had already committed to selling EV7 systems to customers. HP would be stupid to reneg on those contracts and upset their customers.
Also, when HP bought Compaq years worth of design work for the EV7 were already finished. Throwing it away would not necessarily be a profitable decision.
Talking to the folks on the Alpha design team (now the Intel advanced design team), they were not super happy about EV8 being cancelled. But such decisions usually come down to money...
The Alpha was in almost all ways a technically superior design to the IA-64. Now that the same group of architects is working for Intel, they can probably make the IA-64 run almost as well or better...
PLEASE go and read about both TCPA and Palladium before flaming them. They are NOT the same thing. Really.
Both TCPA and Palladium are ways of achieving "trusted computing", which is the ability for a program to run in an environment where the program knows (and can certify to people other than the computer's owner) that no other unwanted software is monitoring or modifying its actions. But how they are implemented is quite different.
TCPA uses a secure boot process. The BIOS verifies that the boot block is trusted; the boot block verifies that the os kernel is trusted; the kernel then verifies the trust level of specific applications; etc. This is what this BIOS implements. The main feature of TCPA (in my mind) is HARDWARE SIMPLICITY -- all that is needed is a small extension to the BIOS which modifies the boot process.
Palladium is from Microsoft, and it shows. Palladium is designed to start up in already running copy of pretty-much-unmodified Windows. Loading the Palladium subsystem (now known as a nexus) is supposed to be fairly easy, sort of like loading a device driver. But to get this ability they PAY with hardware complexity -- the CPU itself has to be changed so that the address space of the nexus can be partitioned, so it is not visible to or under the control of the main Windows kernel. This is one of many reasons why you don't see any Palladium enhanced systems in the real world yet -- Intel (or AMD) has not yet started selling a chip which supports what Microsoft needs to make Palladium work. A main design goal in Palladium seems to be "don't mess with Windows, we don't want to break legacy code".
Dave did his PhD thesis on the idea of routing packets between a bunch of wavelan cards moving all over the place. If you play up the military side of it (imagine every soldier/tank with wavelan, routing packets between them!) DARPA likes to fund this kind of stuff.
Anyways, the most fun was had when Dave and his colleagues rented a fleet of cars, put a wavelan equipped laptop in each one (since this was a while ago, they were using the original 2Mb wavelan, not this 802.11b stuff), and were driving all over Pittsburgh trying to see how well packets would get through between cars....
Slashdot Mirror
At work we sometimes work on projects which span multiple offices. We have used a pair of Tandberg units, one sitting on our desk in California, the other sitting on a desk in New York. It is great to be able to say "hey Bob, can you explain this bit of code?" when you see that Bob is sitting at his desk and not deep in conversation with someone else. Much more productive than resorting to email, phone, or IM all the time.
Sadly, I've heard that those Tandbergs are super expensive...
Good decent people own guns in illinois and have their FOID card, but they aren't the ones doing drive by shooting or holding up liquor stores or banks.
http://xkcd.com/703/
Fascinating. Thank you for the details!
I was amazed to read this entire article and not learn:
a) what do they do with the data they collect? I'd have loved to learn what sensor data is valuable for, and how it changes the dynamics of the race. (Who cares how many bits they ship if you have no idea if the bits are _useful_ bits?)
b) how much of an impact does this have on the race? Does this make a 1% difference in track times, 80%, something in the middle?
Anyone have a link to an article which explains _why_ they collect all this data?
Before thinking that an IFR ticket will let you fly a 182 anytime, look into the icing conditions in your area. For example, in the SF Bay Area most cloudy days occur in the winter, and a large fraction of those days are also prime icing conditions -- grounding most single engine planes. (Airliners have extensive anti-ice equipment, and usually climb or descend through the icing layer so quickly it is a non-issue.)
An IFR ticket is really educational, fun to get, and does expand your options when flying. But in many otherwise fantastic places for GA flying, it won't give you year-round on-demand transportation.
In the US?
T-Mobile. I signed up for a FlexPay account yesterday for my and my wife's phones, no credit check required.
My wedding band is titanium as well. I was worried that I really wouldn't like wearing a ring, and having a light metal like titanium is awesome.
Several websites said that boonerings.com was excellent, so I got my ring there. They were right -- fast, friendly service, and the ring is exactly what I asked for. If you read through the site you will see that this guy is a geek too -- he bought a CNC milling machine to make his own bicycle parts, found that others were willing to pay him for his work, then found that making rings was more profitable than making bike parts.
The main thing I have used LaTeX for is generating conference papers (and a few journal papers and a thesis).
99% of grad student time wasted in LaTeX is spent trying to squeeze more content into a set page limit. I can't tell you how long I have spent trying to reformat tables to appear in a more compact format and still be readable, rephrasing sentences to eliminate dangling words in paragraphs, tweaking line spacing just enough to get your last 100 words to fit on the last page (while not being noticeable to reviewers), turning first names into initials in the bibtex file to shrink the references section, and when pressed hand-editing the postscript in figures to make things look better or more compact...
If you are writing text which doesn't have to meet tight formatting or page-count restraints, LaTeX can be a real joy to use. It always makes things look great. (Heck, I helped edit a non-math published book using LaTeX, and our printers were overjoyed at how easy it was to deal with our postscript.) But if you give in to the temptation to try and tell LaTeX to do something different than it wants to do, then you are in for a world of pain.
My first PC (replaced my old Amiga...) was a 486DX/33 with 8MB of RAM. Since I was a geek, I installed OS/2 2.0, Windows 3.1, and SLS Linux 0.95.3. (Aside: my mouse didn't work under Linux. So I kludged the driver to make it work, and submitted the patch to Linus. Now my name is in the kernel, on a driver for a mouse that nobody has made since 1992...)
Windows was snappy and fast. OS/2 lumbered along (it spent a lot of time swapping, since 8MB was not really enough for it). Linux was zippy fast, unless you started X -- X worked, but was pretty darn slow.
Compared to the Sun workstations at school which each had 10 NCD X-terminals slaved to them, Linux/X on this machine was fast. But compared to everything else, it was slooooow.
One example of why you might be concerned about lithium batteries:
http://video.google.com/videoplay?docid=3690260570423705609
This video shows what happens if you overcharge or damage a Lithium Polymer battery as is commonly used in R/C planes and helicopters.
I have one of these machines. About a week after I got it, I lost the pen on a flight. That was an expensive mistake. If you ever lose the pen, you will find that:
a) It is difficult to find a replacement. You certainly won't find one on short notice. (I was unable to find any store in the Bay Area of California or in Pittsburgh PA that had them in stock.); and
b) They are EXPENSIVE! Replacement pens online cost at least $40.
Egads!
Actually, the job market for PhDs in CS is currently very tight.
During this spring's academic hiring cycle many top universities were not even interviewing candidates, since they had no funding for teaching slots. CS enrollment is down, and this means that most schools don't need to hire new professors. At the top schools many fantastic candidates who other years would have had no problems getting a job with MIT, Stanford or CMU didn't even get interviews.
The corporate research world has also shrunk over the past few years. AT&T labs, Lucent and Xerox PARC have all shrunk dramatically or pretty much gone. HP, IBM research and Sun labs are not exactly on major hiring sprees. Microsoft research is not growing fast enough to hire all the people who lost jobs at these major labs, and the new players in town (TTI in Chicago, Seagate research and the Intel research lablets) are not big enough to hire all the talent suddenly flooding the market.
This hiring crunch is particularly hurting folks with expertise in networking, due to the flood of senior people coming from Lucent and AT&T.
The result of this is threefold: first, some companies are finding that they are having much less trouble than in the past hiring PhDs. Second, many second and third tier schools are managing to hire fantastic professors this year, instead of the usual second string candidates they manage to pick up. Third, many students are either stretching out their PhDs or taking postdocs instead of going into the job market.
Good question. If you look at the recent history of CPU design (say, for the past 20 years), you see that the primary concern of architects have changed with the technology over time. In the 80's any design you came up with was limited by how many transistors you could squeeze onto a chip, and so everyone was worried about transistor count. By the 90's the transistors became abundant and small enough that a lack of transistors was no longer a primary concern of designers --- instead, they were much more concerned with the wires: how to pack them in and route the nicely, and how long it took for signals to get from one place to another.
These days, wires are abundant, transistors are abundant, and the main concern is power. Why?
a) GHz == Power. If you increase the clock rate, you increase the power drawn. So every time you want to make the machine "faster", you need to feed it more power.
b) More logic == more power. If you want to make the chip more complex or have more cache, it will need more power. But at the moment, it is cheaper (in terms of power) to add more logic than to add more GHz.
So why is power a problem? How much is too much? First, let's talk about total power: the total amount of electricity you have to feed into the chip to keep it running. This changes depending on how you utilize the chip, but designers have to design for the worst case.
There are two problems with total power: how do you get the electricity into the chip, and how do you get the heat it produces off of the chip. My understanding is that both problems are hard, but the heat one is currently harder. If you put too much power in, you need to get the heat out. More power == more heat. More heat == more expensive cooling solution. For example, if you had a low power chip you could get away with a simple and cheap heat sink. As it draws more power you have to add expensive (and noisy!) fans. Add more power, and you might eventually have to add a liquid cooling system, air conditioning unit, and a bunch of plumbing. Add more power, and perhaps you have to hire a team of workers to constantly feed dry ice into your machine, or some other creative cooling solution. So the fundamental problem is that once your chip draws enough power keeping it cool becomes too expensive. Right now it looks like 100 to 150W is the max power which can be kept cool by fan systems which are cheap and quiet enough that people will actually buy them. Nobody wants to buy a computer with plumbing for their home or office, liquid cooled machines are still only used for special business applications where they have little other choice.
Now total power is not the only problem. There is also localized power. Think "will a portion of my chip melt into a pool of molten silicon since I can't cool it off fast enough"? There is a nice story of how one of the first Alpha CPU prototypes cracked in half due to having too much power running up the middle of the chip... It turns out that this localized heat is a major limitation these days, and is a primary reason why Intel won't sell you a 5GHz chip. They don't know how to avoid this problem in a reasonable way. So, instead, they are going to improve performance by adding cores.
If you have one core, you have one central location in the chip that is constantly working hard, and so it is generating a lot of heat. Getting the heat away from that tiny point is hard. If you build a chip with two cores, then you divide the work over two points, and so each point generates half of the heat. Keeping that cool is much easier. With four cores....etc.
A research paper at last year's ASPLOS suggested that a good way to work this problem is to have a program run on one core until it gets too hot, then move execution to the next core, and repeat. This way you always have one core doing work, and the others are cooling off. We may end up having to do this.
The advice about loans doesn't apply to a student from India. Getting a loan at any rate from a US lending institution will be very difficult or impossible unless you are a US citizen or permenant resident. They key is your lack of a "US credit history".
When I first came to the US (from Canada) to go to grad school I couldn't even get a credit card! My Canadian CitiBank Visa card meant nothing when I tried to get a US CitiBank Visa -- the banks don't know how to talk across borders. Even after 8 years in the US the banks laugh if I ask them about student loans (but the credit card companies now like me).
If you apply to PhD programs in Computer Science, expect to have them pay you enough to get by on, either through teaching or research funds. If they can't offer you that, they are probably not giving you a serious offer.
If you want to know more about the difference, you can read an article about it here.
I am a PhD student in computer science at Carnegie Mellon. I write C++ code every day. I know at least 7 programming languages well enough to program in them professionally. For my research I design new computer hardware, compilers, database systems, and operating systems. I have helped write (non-software) patents. ...and I'll be damned if I can fully understand the text of most patents, including the ones cited in this article. How in the world is a software developer supposed to avoid infringing on patents if they can't _understand_ them? I don't know of any school which includes a course on "reading patent legaleese" in their computer science programs.
I have 12 years of post-high-school education in Computer Science. I have no idea how to write a non-trivial program that I am relatively sure does not infringe on any patent. I don't know anyone who does. Doesn't this seem absurd?
Depends on the machine. I once helped to run a Coke machine which took in about $2k/week. If you got into the machine at the wrong time you could have easily gotten $1k in cash... (The machine was located in a high traffic area, and most of the people around knew who was _supposed_ to be opening it, so breaking in unnoticed might be kind of hard 'tho.)
64-bit pointers give you two things:
Note that neither of these instantly lead to better performance -- instead, they make it easier to write programs. If you are simultaneously accessing a dataset this large (i.e., if you have such a huge working set) then your cache performance will probably suck. This will be true whether you have 32-bit or 64-bit pointers. But if you have 64-bit pointers, you will also have more data to store (since your pointers are twice as large). This may hurt performance badly.
Most programs switch to 64-bit pointers since it is easier than trying to fake a large address space throguh segments and paging. It is by no means always faster.
Before HP purchased Compaq, Compaq had already committed to selling EV7 systems to customers. HP would be stupid to reneg on those contracts and upset their customers.
Also, when HP bought Compaq years worth of design work for the EV7 were already finished. Throwing it away would not necessarily be a profitable decision.
Talking to the folks on the Alpha design team (now the Intel advanced design team), they were not super happy about EV8 being cancelled. But such decisions usually come down to money...
The Alpha was in almost all ways a technically superior design to the IA-64. Now that the same group of architects is working for Intel, they can probably make the IA-64 run almost as well or better...
PLEASE go and read about both TCPA and Palladium before flaming them. They are NOT the same thing. Really.
Both TCPA and Palladium are ways of achieving "trusted computing", which is the ability for a program to run in an environment where the program knows (and can certify to people other than the computer's owner) that no other unwanted software is monitoring or modifying its actions. But how they are implemented is quite different.
TCPA uses a secure boot process. The BIOS verifies that the boot block is trusted; the boot block verifies that the os kernel is trusted; the kernel then verifies the trust level of specific applications; etc. This is what this BIOS implements. The main feature of TCPA (in my mind) is HARDWARE SIMPLICITY -- all that is needed is a small extension to the BIOS which modifies the boot process.
Palladium is from Microsoft, and it shows. Palladium is designed to start up in already running copy of pretty-much-unmodified Windows. Loading the Palladium subsystem (now known as a nexus) is supposed to be fairly easy, sort of like loading a device driver. But to get this ability they PAY with hardware complexity -- the CPU itself has to be changed so that the address space of the nexus can be partitioned, so it is not visible to or under the control of the main Windows kernel. This is one of many reasons why you don't see any Palladium enhanced systems in the real world yet -- Intel (or AMD) has not yet started selling a chip which supports what Microsoft needs to make Palladium work. A main design goal in Palladium seems to be "don't mess with Windows, we don't want to break legacy code".
He also says "what did you have to insure was done?". Do you really think he was asking about insurance issues?
Slashdot. News for the terminally stupid. I think slashdot is going to disappear from my bookmark list...
Perhaps this link is better.
Dave did his PhD thesis on the idea of routing packets between a bunch of wavelan cards moving all over the place. If you play up the military side of it (imagine every soldier/tank with wavelan, routing packets between them!) DARPA likes to fund this kind of stuff.
Anyways, the most fun was had when Dave and his colleagues rented a fleet of cars, put a wavelan equipped laptop in each one (since this was a while ago, they were using the original 2Mb wavelan, not this 802.11b stuff), and were driving all over Pittsburgh trying to see how well packets would get through between cars....
See www.junkbusters.org for details.
You must be kidding. Have you read these books? I can't say I know a single person who has read all of them.
I have both Knuth and CLR (Cormen, Leiserson and Rivest) on my shelf -- and when I need information on algorithms, I read CLR every time.