Mozilla is heavily componentized. Mail/news, the editor, the address book, Java, and many many other pieces are all separate chunks of code which compile into shared libraries, that can simply be thrown away if you don't want them.
Providing all the source together is useful because you can see how the different components work. However, it would be really cool for someone to produce a "Mozilla-lite" distribution with just the binaries required for the browser. That wouldn't be much harder than just selecting the right subset of files to include in the tarball.
> Having suitably-equipped machines with access to > the Net is one. Cheap unmetered Net usage is > another. And of course these two conditions > predicate a whole slew of others, such as > telephone infrastructure, electricity and water > access, and so forth.
See my post above. Also, computers don't need water.
> What was that quote from the Unix-Haters' > Handbook? 'Linux is only free if your spare time > is worthless.' I think this statement is > probably even more applicable to other countries > than it is to the West.
The quote was from Jamie Zawinski. Your last statement is completely backwards if we're thinking in finanicial terms; if you're poor, it's much more worthwhile to spend an hour figuring out a problem than to spend money on another product.
> Lacking proper electricity supply, working > telephone lines, not to mention computers
These and other barriers will disappear rapidly if technology continues to improve at historical rates.
The cost of a general purpose computer can be driven almost arbitrarily low. Right now I see two major issues. Good solid state storage (disks) doesn't scale down well (disk costs $10/GB, but try buying 100MB for a dollar). Various new technologies look likely to fix that, e.g. probe storage*. (Probe storage is one example of why ICs are so wonderful --- they scale down really well.) The other problem is displays. There is a need for a very cheap, passively lit display. The "electronic paper" work might fit the bill.
Likewise, power consumption can go way down. A passively lit screen will really help. It should be reasonable to run a device from solar or muscle power.
The hardest problem is connectivity. Obviously it has to be wireless, at least locally. Then a big problem is that transmission fundamentally requires a lot of power. There are some complementary approaches: -- broadcast content from satellite -- "ad hoc" networking; individual units cooperate to forward packets, to reduce the required range -- some central wired infrastructure serving base stations -- sneakernet with batched data
I'm confident the hardware will appear. Perhaps a tougher problem is to produce software and content to make these things useful. We're going to have to redefine "ease of use". I'm sure we can at least produce a useful library (with video for the illiterate).
Hey, IPO zillionaires! Here's a chance to do something good AND cool!
The problem is that the sort of content protection that Big Media aspires to simply can't be made bulletproof. Any all-software solution can and will be broken fairly easily no matter how good your obfuscation or cryptography is. Hardware solutions are harder but they will fall too.
The *only* thing they can do is come up with some token technical solution and protect it with legal measures, which is of course what they're doing. It's not because they're lame or stupid (although they probably are), it's primarily because nothing better can be done.
It's interesting to see the degree to which everyone's been fooled into thinking that the cracks on DVD and the Windows Media Player, to name two examples, were just due to mistakes made by the vendors. Mistakes help, but the idea that one day an invulnerable solution will come along is a pipe dream.
True, the BA backbone does suck... but my friends are hooked up directly to CMU, so it's really really fast to CS department machines and fairly well provisioned all the way out. Plus vBNS etc...
We don't run servers at home, we run them on the CS department LANs:-).
A professor here at CMU, Dan Siewiorek, consulted for the Army on their Land Warrior infantry battle computer. He claimed that the NSA crypto chips it used were quite poor compared to contemporaneous commercial products. In particular they consumed much more power. So I doubt their in-house chip capabilities are to be feared.
A professor here at CMU, Dan Siewiorek, consulted for the Army on their Land Warrior infantry battle computer. He claimed that the NSA crypto chips it used were quite poor compared to contemporaneous commercial products. In particular they consumed much more power.
When you think about how much a good fab costs these days, it's not surprising really, even with the NSA's budget.
> Keep in mind the real goal of these agencies. > National security.
Of course, we have to take their word for it that that is their real goal, since the very nature of their activities has made a joke of civilian oversight.
Please don't condemn people to use Microsoft software for the rest of their lives. Just because someone is old, or of lesser intelligence, or just unwilling to learn doesn't mean they shouldn't be allowed to enjoy quality software. The fact is that Windows breakage hurts them just as much (more, even) as it hurts anyone else.
Woah. What a potential flame pit. I'll try to restrain myself to just a few comments:-). (Disclaimer: I'm a CMU PhD student.)
> SE This is my area... > Go out into industry Depends what you mean by software engineering. Most industry is based on "hack it together and debug it into something good". You can get that working on most open source projects. The real challenges are mostly in hardcore stuff, e.g. where if the software breaks, people die. For that, you can go to some small companies (e.g. Praxis Critical Systems in the UK), or the government (NASA, DoD). > CMU Or Cornell. > Berkeley Berkeley doesn't do software engineering. Well not much. They just hired one of our guys, and he's really good, but we made him:-).
Hmm, I can't restrain myself.
> if you are looking at PhD programs, choose > school based on potential advisors rather than > overall school reputation. Only if you really really know what you want to do. The top schools have good advisors in almost every area. And overall school reputation really really helps, trust me on this.
> To have a strong chance at the top-tier schools, > you should have a strong research record That helps, but it's not necessary. Most incoming students don't have a strong research record. The admissions committees are just looking for evidence that you're smart and that you will do well, and they don't care what form it comes in. Having a "head start" in research doesn't seem to be much of an advantage once you're in, in general.
In general I think those area lists are too narrow. CMU, MIT and Stanford all have a number of excellent systems groups. CMU is good in theory. And how could you leave MIT out of the AI list??
Some people are saying that you should figure out what you want to do before you choose a school. I don't think that's necessary, IF you can get into some of the tier 1 schools. In particular, at CMU the system is set up to expose you to a lot of different areas of CS. You may think you like network protocols but end up hacking soccer-playing dog robots. Maybe you could even find a way to combine those interests:-). Personally, when I came to CMU I did not have a clue that some of these areas even existed, and it would have been a big mistake for me to have cut down my options prematurely. Of course, some people come to school knowing exactly what they're going to do and they do it --- that's fine.
A PhD is definitely not for everyone. Many people start and drop out after a few years because they find it's not for them. That's fine. However, the job market for PhD graduates is RED HOT right now. There are loads of good positions available in academia and industrial research --- industry is crazy for people, so hiring any professors they can get their hands on, and the universities are trying to grow at the same time. MSR's growth in particular is really putting the squeeze on (but you don't have to go there:-) ).
For getting into grad school, I'd second other people's suggestions that letters of recommendation from people whose names are known are key. Experience on a researchy project also really helps, if it looks like you did something interesting.
Go and do a PhD if you like to do cool things with computers that are too far out for a company to believe in. Especially do a PhD if you think you'd like someone to pay you to do that for the rest of your life. Don't do a PhD for the money... get an MS at most, then get to work.
As for choosing grad schools, I love CMU CS and I could explain why at length, but that's not really appropriate for this forum. Send email to roc@cs.cmu.edu if anyone wants to know more...
PS, why are there so many CMU students on Slashdot? GET BACK TO WORK!
Some of the Sun material talks about Java applications with tens or hundreds of threads each. However, in the applications I write and the applications I've seen, most of those threads exist to provide nonblocking behaviour for various purposes, and it's hardly ever the case that 2 (or more) threads are runnable at once. The problem is that for many tasks it's just really hard to parallelize them into multiple threads, and to do it right. (One problem is that the thread model of concurrency just sucks, but that's another rant.)
So here's my shameless plug for CMU research: what we need is hardware support to make it easier to write threaded programs. One approach is thread-level data speculation. In this system, one thread executes normally while other threads execute speculatively, basically assuming that the parallel execution will be safe and correct. The processor is responsible for detecting conflicts between threads that mean the optimistic parallel execution is not correct. When there is a conflict, the speculating thread that caused the conflict is killed and its speculative state is thrown away. It's not as hard to do this as you might think; it seems possible to do it by adding some tags to the data caches on each processor.
See here for more: http://www.cs.cmu.edu/~tcm/STAMPede.html
The Stanford Hydra project does something like this too, BTW.
> The second vulnerability was SSH. Someone > altered the SSH client to act as a trojan. This > should not be possible - programs should be able > to detect if they've been modified. Failing > that, a virus scanner should be able to detect > modifications.
As the author of the package that was trojaned (TTSSH), I feel obliged to point out that there is NO WAY for a program to reliably detect if it's been modified. The cracker can always just disable the code that's supposed to detect the modifications. (This is a bit easier when source code is available, as TTSSH's is.)
A separate virus scanner might be a bit tougher, but would be vulnerable in the same way.
It's true that there may not be many female kernel hackers to go around, but it's insidious inadvertant slips like this that contribute to the situation, and that's bad for all of us.
> Down under in Australia, we were recently > treated to a leaked report from ASIO ( our > equivelent of the FBI ) that flatly stated that > there was no point in passing laws to prevent > criminals from using encryption technology, > since being criminals, they don't obey the law > anyway.
I read the report, but unfortunately I don't remember exactly what it said. However, the situation is not QUITE as simple as this. On the face of it, this argument could be used against any law whatsoever.
The idea of these laws is not to simply say "thou shalt not use crypto", but actually make it harder to get access to good crypto. In the age of the Internet, however, this is not effective. (This is where the situation starts to diverge from the analogous situation of gun control laws.)
Clearly the NSA knows this. I think (and I'm not alone) that the real purpose of the export laws is to simply slow down the adoption of cryptography everywhere (including domestically), so that for as long as possible the NSA will be able to monitor the general populace. Obviously serious terrorists, foreign governments etc have already secured themselves.
As for whether exporting crypto is good... first of all, the issue is not whether crypto should be exported; the issue is whether we should have it at all. The export thing is just a dodge; the FBI/NSA would love to restrict domestic crypto, it's just politically infeasible. We can easily see that there are plenty of threats within the US. Also, there can be no hedging over key length or cipher type; allowing "weak" crypto is equivalent to not allowing it at all. Computers, algorithms and money all change over time; we have to assume that if someone can break a code, others can too.
Given that, the prospect of people using crypto to, e.g., anonymously publish designs for cheapo biological, chemical and nuclear weapons terrifies me. However, without crypto, "information warfare" attacks on computers and infrastructure also terrify me, and so does the potential for the Internet as the ultimate surveillance tool. Pick your poison. Personally, I think that if we get to the point where readily available technology poses a threat to the future of the human race, then we can transition to a total police state. There is no point in getting there ahead of time.
BTW, I spent quite a bit of time in Australia working on TTSSH. Good thing their export regime leaks like a sieve.
I don't know if this is public yet, but I haven't signed any NDAs, so here goes...
1) IBM research is working on a Hotspot like thing, codename: Jalapeno. They know what they're doing, they have some great people, it should rock. Still a fair way out, though. The interesting part is that Jalapeno is itself written in Java...
2) IBM is fiercely committed to making Java the COBOL of the 21st century, i.e. the language in which all the crufty old inhouse code is written. That would be interesting.
Dynamic Optimization rulz, should be used compiled
on
HotSpot arrives
·
· Score: 1
There are a lot of optimizations the compiler can't do in C/C++, because the program can be very sensitive to things like data structure layout. Not to mention the fact that C++ is so complex, it's incredibly hard just to get the compiler right, let alone do fancy transformations.
Also, because Java defines things like memory allocation and threading, the Java compiler and runtime can cooperate to make optimizations involving those features. In C/C++ you can basically roll your own allocation and threads, which is cool, but it means the compiler doesn't know how to help you and can't make assumptions about what you're trying to do.
Slashdot Mirror
Mozilla is heavily componentized. Mail/news, the editor, the address book, Java, and many many other pieces are all separate chunks of code which compile into shared libraries, that can simply be thrown away if you don't want them.
Providing all the source together is useful because you can see how the different components work. However, it would be really cool for someone to produce a "Mozilla-lite" distribution with just the binaries required for the browser. That wouldn't be much harder than just selecting the right subset of files to include in the tarball.
The memory cache has already landed. It's disabled by default due to some outstanding bugs, but you can turn it on by editing your prefs:
user_pref("browser.cache.enable", true);
It works well for me (Win32).
> Having suitably-equipped machines with access to
> the Net is one. Cheap unmetered Net usage is
> another. And of course these two conditions
> predicate a whole slew of others, such as
> telephone infrastructure, electricity and water
> access, and so forth.
See my post above. Also, computers don't need water.
> What was that quote from the Unix-Haters'
> Handbook? 'Linux is only free if your spare time
> is worthless.' I think this statement is
> probably even more applicable to other countries
> than it is to the West.
The quote was from Jamie Zawinski. Your last statement is completely backwards if we're thinking in finanicial terms; if you're poor, it's much more worthwhile to spend an hour figuring out a problem than to spend money on another product.
> Lacking proper electricity supply, working
> telephone lines, not to mention computers
These and other barriers will disappear rapidly if technology continues to improve at historical rates.
The cost of a general purpose computer can be driven almost arbitrarily low. Right now I see two major issues. Good solid state storage (disks) doesn't scale down well (disk costs $10/GB, but try buying 100MB for a dollar). Various new technologies look likely to fix that, e.g. probe storage*. (Probe storage is one example of why ICs are so wonderful --- they scale down really well.) The other problem is displays. There is a need for a very cheap, passively lit display. The "electronic paper" work might fit the bill.
Likewise, power consumption can go way down. A passively lit screen will really help. It should be reasonable to run a device from solar or muscle power.
The hardest problem is connectivity. Obviously it has to be wireless, at least locally. Then a big problem is that transmission fundamentally requires a lot of power. There are some complementary approaches:
-- broadcast content from satellite
-- "ad hoc" networking; individual units cooperate to forward packets, to reduce the required range
-- some central wired infrastructure serving base stations
-- sneakernet with batched data
I'm confident the hardware will appear. Perhaps a tougher problem is to produce software and content to make these things useful. We're going to have to redefine "ease of use". I'm sure we can at least produce a useful library (with video for the illiterate).
Hey, IPO zillionaires! Here's a chance to do something good AND cool!
Rob
The problem is that the sort of content protection that Big Media aspires to simply can't be made bulletproof. Any all-software solution can and will be broken fairly easily no matter how good your obfuscation or cryptography is. Hardware solutions are harder but they will fall too.
The *only* thing they can do is come up with some token technical solution and protect it with legal measures, which is of course what they're doing. It's not because they're lame or stupid (although they probably are), it's primarily because nothing better can be done.
It's interesting to see the degree to which everyone's been fooled into thinking that the cracks on DVD and the Windows Media Player, to name two examples, were just due to mistakes made by the vendors. Mistakes help, but the idea that one day an invulnerable solution will come along is a pipe dream.
Rob
True, the BA backbone does suck ... but my friends are hooked up directly to CMU, so it's really really fast to CS department machines and fairly well provisioned all the way out. Plus vBNS etc...
:-).
We don't run servers at home, we run them on the CS department LANs
... unless you're out of DSL range, or PacBell just stinks.
Here in Pittsburgh my friends just got ADSL: $200/month for 7Mb/s downstream, 700Kb/s upstream. It's working very well.
(Best of all, the CMU CS department subsidy is paying for it all, but that's another story.)
A professor here at CMU, Dan Siewiorek, consulted for the Army on their Land Warrior infantry battle computer. He claimed that the NSA crypto chips it used were quite poor compared to contemporaneous commercial products. In particular they consumed much more power. So I doubt their in-house chip capabilities are to be feared.
A professor here at CMU, Dan Siewiorek, consulted for the Army on their Land Warrior infantry battle computer. He claimed that the NSA crypto chips it used were quite poor compared to contemporaneous commercial products. In particular they consumed much more power.
When you think about how much a good fab costs these days, it's not surprising really, even with the NSA's budget.
> Keep in mind the real goal of these agencies.
> National security.
Of course, we have to take their word for it that that is their real goal, since the very nature of their activities has made a joke of civilian oversight.
Please don't condemn people to use Microsoft software for the rest of their lives. Just because someone is old, or of lesser intelligence, or just unwilling to learn doesn't mean they shouldn't be allowed to enjoy quality software. The fact is that Windows breakage hurts them just as much (more, even) as it hurts anyone else.
Woah. What a potential flame pit. I'll try to restrain myself to just a few comments :-). (Disclaimer: I'm a CMU PhD student.)
:-).
> SE
This is my area...
> Go out into industry
Depends what you mean by software engineering. Most industry is based on "hack it together and debug it into something good". You can get that working on most open source projects. The real challenges are mostly in hardcore stuff, e.g. where if the software breaks, people die. For that, you can go to some small companies (e.g. Praxis Critical Systems in the UK), or the government (NASA, DoD).
> CMU
Or Cornell.
> Berkeley
Berkeley doesn't do software engineering. Well not much. They just hired one of our guys, and he's really good, but we made him
Hmm, I can't restrain myself.
> if you are looking at PhD programs, choose
> school based on potential advisors rather than
> overall school reputation.
Only if you really really know what you want to do. The top schools have good advisors in almost every area. And overall school reputation really really helps, trust me on this.
> To have a strong chance at the top-tier schools,
> you should have a strong research record
That helps, but it's not necessary. Most incoming students don't have a strong research record. The admissions committees are just looking for evidence that you're smart and that you will do well, and they don't care what form it comes in. Having a "head start" in research doesn't seem to be much of an advantage once you're in, in general.
In general I think those area lists are too narrow. CMU, MIT and Stanford all have a number of excellent systems groups. CMU is good in theory. And how could you leave MIT out of the AI list??
I'm a 6th year PhD student at CMU. Nearly done...
:-). Personally, when I came to CMU I did not have a clue that some of these areas even existed, and it would have been a big mistake for me to have cut down my options prematurely. Of course, some people come to school knowing exactly what they're going to do and they do it --- that's fine.
:-) ).
... get an MS at most, then get to work.
Some people are saying that you should figure out what you want to do before you choose a school. I don't think that's necessary, IF you can get into some of the tier 1 schools. In particular, at CMU the system is set up to expose you to a lot of different areas of CS. You may think you like network protocols but end up hacking soccer-playing dog robots. Maybe you could even find a way to combine those interests
A PhD is definitely not for everyone. Many people start and drop out after a few years because they find it's not for them. That's fine. However, the job market for PhD graduates is RED HOT right now. There are loads of good positions available in academia and industrial research --- industry is crazy for people, so hiring any professors they can get their hands on, and the universities are trying to grow at the same time. MSR's growth in particular is really putting the squeeze on (but you don't have to go there
For getting into grad school, I'd second other people's suggestions that letters of recommendation from people whose names are known are key. Experience on a researchy project also really helps, if it looks like you did something interesting.
Go and do a PhD if you like to do cool things with computers that are too far out for a company to believe in. Especially do a PhD if you think you'd like someone to pay you to do that for the rest of your life. Don't do a PhD for the money
As for choosing grad schools, I love CMU CS and I could explain why at length, but that's not really appropriate for this forum. Send email to roc@cs.cmu.edu if anyone wants to know more...
PS, why are there so many CMU students on Slashdot? GET BACK TO WORK!
Rob
- XML based (XUL)
- XUL can include arbitrary HTML elements (want an MPEG in your menus? That's easy)
- Write UI code in any supported scripting language (currently only Javascript though) using standard event model
- Dynamically modify UI via standard DOM interfaces
- Fast, powerful dynamic layout engine
- Seamless Web integration (duh)
- UI talks to backend components through language-independent XPCOM
- Runs on all important (and many unimportant) platforms in various toolkit combinations (potentially KDE/GNOME agnostic)
- Skinnable using CSS
- Fully open source
- Leveraging Web standards means it will grow with the Web (e.g. JPEG2000, MathML, SVG)
Well, that's the plan. There's still some distance to go, but the basics are all there and working.Some of the Sun material talks about Java applications with tens or hundreds of threads each. However, in the applications I write and the applications I've seen, most of those threads exist to provide nonblocking behaviour for various purposes, and it's hardly ever the case that 2 (or more) threads are runnable at once. The problem is that for many tasks it's just really hard to parallelize them into multiple threads, and to do it right. (One problem is that the thread model of concurrency just sucks, but that's another rant.)
So here's my shameless plug for CMU research: what we need is hardware support to make it easier to write threaded programs. One approach is thread-level data speculation. In this system, one thread executes normally while other threads execute speculatively, basically assuming that the parallel execution will be safe and correct. The processor is responsible for detecting conflicts between threads that mean the optimistic parallel execution is not correct. When there is a conflict, the speculating thread that caused the conflict is killed and its speculative state is thrown away. It's not as hard to do this as you might think; it seems possible to do it by adding some tags to the data caches on each processor.
See here for more:
http://www.cs.cmu.edu/~tcm/STAMPede.html
The Stanford Hydra project does something like this too, BTW.
> The second vulnerability was SSH. Someone
> altered the SSH client to act as a trojan. This
> should not be possible - programs should be able
> to detect if they've been modified. Failing
> that, a virus scanner should be able to detect
> modifications.
As the author of the package that was trojaned (TTSSH), I feel obliged to point out that there is NO WAY for a program to reliably detect if it's been modified. The cracker can always just disable the code that's supposed to detect the modifications. (This is a bit easier when source code is available, as TTSSH's is.)
A separate virus scanner might be a bit tougher, but would be vulnerable in the same way.
I hope they'd consider female applicants too.
It's true that there may not be many female kernel hackers to go around, but it's insidious inadvertant slips like this that contribute to the situation, and that's bad for all of us.
> Down under in Australia, we were recently
... first of all, the issue is not whether crypto should be exported; the issue is whether we should have it at all. The export thing is just a dodge; the FBI/NSA would love to restrict domestic crypto, it's just politically infeasible. We can easily see that there are plenty of threats within the US. Also, there can be no hedging over key length or cipher type; allowing "weak" crypto is equivalent to not allowing it at all. Computers, algorithms and money all change over time; we have to assume that if someone can break a code, others can too.
> treated to a leaked report from ASIO ( our
> equivelent of the FBI ) that flatly stated that
> there was no point in passing laws to prevent
> criminals from using encryption technology,
> since being criminals, they don't obey the law
> anyway.
I read the report, but unfortunately I don't remember exactly what it said. However, the situation is not QUITE as simple as this. On the face of it, this argument could be used against any law whatsoever.
The idea of these laws is not to simply say "thou shalt not use crypto", but actually make it harder to get access to good crypto. In the age of the Internet, however, this is not effective. (This is where the situation starts to diverge from the analogous situation of gun control laws.)
Clearly the NSA knows this. I think (and I'm not alone) that the real purpose of the export laws is to simply slow down the adoption of cryptography everywhere (including domestically), so that for as long as possible the NSA will be able to monitor the general populace. Obviously serious terrorists, foreign governments etc have already secured themselves.
As for whether exporting crypto is good
Given that, the prospect of people using crypto to, e.g., anonymously publish designs for cheapo biological, chemical and nuclear weapons terrifies me. However, without crypto, "information warfare" attacks on computers and infrastructure also terrify me, and so does the potential for the Internet as the ultimate surveillance tool. Pick your poison. Personally, I think that if we get to the point where readily available technology poses a threat to the future of the human race, then we can transition to a total police state. There is no point in getting there ahead of time.
BTW, I spent quite a bit of time in Australia working on TTSSH. Good thing their export regime leaks like a sieve.
I don't know if this is public yet, but I haven't signed any NDAs, so here goes ...
1) IBM research is working on a Hotspot like thing, codename: Jalapeno. They know what they're doing, they have some great people, it should rock. Still a fair way out, though. The interesting part is that Jalapeno is itself written in Java...
2) IBM is fiercely committed to making Java the COBOL of the 21st century, i.e. the language in which all the crufty old inhouse code is written. That would be interesting.
There are a lot of optimizations the compiler can't do in C/C++, because the program can be very sensitive to things like data structure layout. Not to mention the fact that C++ is so complex, it's incredibly hard just to get the compiler right, let alone do fancy transformations.
Also, because Java defines things like memory allocation and threading, the Java compiler and runtime can cooperate to make optimizations involving those features. In C/C++ you can basically roll your own allocation and threads, which is cool, but it means the compiler doesn't know how to help you and can't make assumptions about what you're trying to do.