But if I'd been using Windows as my primary OS for my whole career, I'd probably feel the opposite way about Macs.
No, you probably would not. In my now-long-and-checkered career, I once worked for about five years for a company that was developing a Windows (NT/2k/XP) application, and I used Windows for everything (desktop, you name it). We also had Cygwin installed so we could get our almost-Unix fix.
Next job after that was a Linux desktop, and I loathed it (keep in mind that before the Windows job, was about ten years of Unix desktop and development. I was plenty familiar with the X/Unix/Emacs world). I managed to lay my hands on a TiBook, beefed it up to 1G of memory, and I used that for my desktop instead, and it has been my desktop ever since.
My colleagues from the Windows job? Both of them now use Macs, too.
If you manage to get a hybrid of two species, the offspring are sterile, so the strain acnnot ontinue beyond a first generation fo offspring (cf. mules).
Not so true for plants. Often the diploid offspring are infertile, but conversion to tetraploid form can restore fertility. (This is true for lilium species, at least. For mammals(at least), getting converted to tetraploid form is a bad idea.)
In addition, plant tissue culture makes the issue of fertility somewhat less of an issue, again depending on the plant. Much of the tree-borne fruit that you see in any store (apples, oranges, peaches, I think bananas), was propagated asexually (grafted onto root stock).
The scale of "conventional" techniques for improving species (e.g., plant 10 acres of pink lilies, keep the 100 best stems, crossbreed, repeat for 10 generations) is sufficiently large that I would not bet too much money that accidental gene transfer/modification (by viruses/bacteria/background radiation) isn't occurring anyway. I don't think anyone ever did any formal safety tests on the first navel orange; they saw that it was seedless and tasty enough, and propagated it all over the place.
Essential?
Till I was 12, I lived in a house with no public fire service, no public road service, no public water service, no public sewer service. 30+ years later, said house is still on its own water and sewer. Only local government services we got were school and police (this assumes that the police could negotiate 1/2 mile of dirt road, not a sure thing). "Animal control" was a shotgun.
I think you need to consider that "essential" is a matter of opinion, and as such, other people might have different opinions. If the people who run a town decide that some service is essential, and don't get voted out of office, then in one important sense, that service is indeed essential.
Didn't see any full text at the Wiley site, only an abstract. Complain all you want about the NYT wanting DNA samples to view their articles, they at least let you look for free.
Given my recent experience as Home IT Guy, I would agree wholeheartedly with EA=bad, MS=bad. I've spent several days trying to pry a friend's data loose from her spyware-infested PC (it is so totally scragged, I cannot even get at the control panels, even after replacing control.exe and rundll32.exe). Ucking Foutlook keeps its data in some wacky proprietary format not easily transported from machine to machine (not like Eudora, just copy the.mbx file over and you're set).
I've been trying to get my son's recently-purchased copy of SimCity to work. Near as I can tell, it is just plain busted, and fat chance getting any help out of EA. Their FAQ has suggestions, but none of that works. Good luck getting to a real person for help.
And yes, I know that corporations serve their stockholders, but the usual recipe for doing this is by finding a way to get people to want to be their customers. All my recent encounters with EA and MS have been frustrating and timewasting; its seems sensible to see if other companies are more interested in my business.
To add a detail to what the other posters wrote -- if you hit an immovable object, all that matters is the distance in which you decelerate (the length of your hood) and how well that deceleration is managed (the engineering of the crumple zone) and how the force of the deceleration is applied to your body (lap belt, shoulder belt, airbag). This is one reason side impacts suck so severely -- instead of having 4 feet to work with, you have about 1 (plus truck bumpers coming through your door, etc).
In two body problems, what determines the worst-case acceleration is the difference in the body weights, and the elasticity of the collision (better if the cars stick together instead of bouncing -- crumple zones again). What little safety advantage large cars and trucks have, they gain at the expense of other people's safety. (And, as has been demonstrated by problems with tires and rollovers, SUVs are not exactly safe anyhow).
Smarter cars could improve on safety slightly by braking early, pretensioning belts, and perhaps extending adjustable bumpers to take some of the edge off the collision.
I'm not sure I buy your claim about the difficulty of solving the original problem in terms of decision problems. For example, if I have an decision procedure for answering "G can be colored with K or more colors" I can derive a "minimum # of colors for G" with binary search: try 1 (no) 2 (no) 4 (no)... 2-to-M (yes) (log N steps to get an upper bound) and then use binary search to find the precise minimum. Maybe you meant something different.
Note that polynomial equivalence admits an awful lot of difference in difficulty -- I can get to within a factor of 2 in either traveling salesman or bin packing w/o too much work, but guaranteeing to be within any factor M of optimal K for graph coloring is equivalent to proving that P=NP. (So graph coloring is in some sense a lot harder than TSP or BP. And no, I do NOT remember the proof).
I used one eagle creek bag till I was sick of it, upgraded to a backpack that had a padded suspension sleeve for the computer, a place for CD or iPod, and a mesh stretch thing that could pin a bike helmet. Comfortable, tough, I use it every day. My only gripe was an excess of logos, all of which I removed. Turned out not to use the helmet-holding thing (my head also holds the helmet pretty well) but I end up stuffing all manner of cables into the kangaroo pouch.
Unfortunately: $100, and I don't see anything like it on their site now.
I would definitely spring for a bag with the laptop pocket, whatever the brand, but I am pretty hard on my stuff. I'm sure Eagle creek is not the only good brand.
I realize your question was rhetorical, but this is something I've actually had to worry about, so here's an answer anyhow.
First, you write as much as possible of the VM in a safe language. (e.g., Java). This minimizes the amount of code for step two. Ideally, the non-safe portions of the VM are doing things like mapping and unmapping memory for the GC, and allocating, starting, and stopping threads -- and that's all.
In the JVM that I worked on, there is ONE INSTANCE of each
Windows system call (i.e., socket read, socket write, file read, file write, etc).
Second, you read the code; ideally, all I/O is in the form of system calls reading blocks of data. In the case of the VM I worked on, that means you need to understand very well exactly what that single instance of each useful system call is doing.
Only let your best people work on this code, and then check their work anyhow. Ideally, write proofs and get automated checkers to verify them (this is all a static type system is, after all).
Third, all other I/O layers are written in the safe language. If something goes wrong there, it gets caught by bounds checking.
There's been other work to guard against "adversaries" that might exploit type flaws in your VM, but ultimately it all boils down to desk checking, and minimizing the amount of code that must be checked in that way. I saw a talk by Andrew Appel explaining how, for an ML compiler, this required checking the 5000 lines of assembly language that gcc produced compiling their theorem checker (because how do you know that gcc is a correct compiler?)
Sadly, practice diverges from theory at times. Various JVMs depend on native code that they don't really need to, and thus have increased their vulnerability to buffer overflow attacks. For example, I think that most JVMs call zlib as a DLL -- and zlib recently had a buffer overflow in it. They call native code to manipulate JPEG and PNG images -- and both of those recently were discovered (on various platforms) to have buffer overflow problems. So, in practice there are still risks, but the way to reduce those risks is to rewrite the risky code in a safe language, not write more code in the risky language. We can rarely afford to desk check 250,000 lines of code, and it's irresponsible to assume that it contains no holes merely because none have been found yet.
A safe language
implementation of things like zlib and jpeg is not necessarily slower, though by default it will do more checking. If you can prove by hand that the bounds checks aren't necessary, then there's a good chance that the compiler will too (and if you cannot prove it, what business do you have not using the safe language?) One way to improve the performance of code in a safe language is to make the proof-of-unnecessary-checking more obvious, so that the compiler will get it. For example,
you might do all the bounds checking up front before entering a loop. If no exception is thrown, then the fact of the correct bounds is established for all the following code. Better, you end up with a piece of code that does not get halfway into whatever side effects it was planning to do, then throw an exception leaving things in an uncertain state.
Java also makes multithreading easier and more portable, so in those cases where a problem could be attacked in parallel, you just might do it. This is much less true of C.
I was not that Java disciple. Back then, the joke was tht the GC should just print "NFS server not responding, still trying" and everything would be ok. Now, it needs to print "47 out of 50 images loaded..."
Great story, but basically wrong and misleading. You can trowel on the layers in any language, and you can write fast Java programs. The speech engine is proof of that.
Garbage collection, in particular, is coming along nicely. Check out "Metronome" by David Bacon, of IBM. You set the knobs, it tells you how much memory you will need, and it gives you GC with real time performance. No pauses.
Or, consider the machine that Azul is working on (good luck getting details now that they are in some sort of a quiet period). It has hardware support for read and write barriers, plus a
good story for stack caches. Chances are good its GC pauses will be tiny (1-10 ms).
I can also tell you that the market very much prefers JIT compilation. I worked on an ahead-of-time-compiling JVM, and there were a couple of others built by other companies. I don't work on that JVM any more, and the other AOT JVM companies have either failed or gone into other lines of business.
So, great story, but not exactly correlated with reality.
On the other hand, consider all the buggy apps that we (who sometimes administer Windows machines) have needed to patch over and over again over the years. If I am unwilling to run an application in the first place because of its poor security, does it really matter how little memory it uses, how fast it runs, or how well it gets along with the other worm-friendly apps?
Big if, that "written correctly". Do you dare to certify that any non-trivial piece of C code is free of buffer overflows? I would never make that bet, but it is true of (pure) Java.
That's not funny, that's stupid. Stuff written in Java is better than stuff written in C or C++ because there are no frapping buffer overflows in Java code (though, sadly, there may be in the native libraries that they sometimes call).
I would have thought that people would be aware of this, given recent PNG and JPEG-related vulnerabilities. By writing Sphinx in Java, we can be sure that run-on sentences will not accidentally overflow a buffer and install a worm.
Guns. (Years ago) my downstairs neighbors had a "gun for safety", of course they left it in the house when they went to work and I was sleeping late. Burglars stole it; I'm damn glad I didn't surprise them.
Guns. After my grandfather died, burglars broke in to the empty house, stole all the lovely guns (some of which I should have inherited). Fortunately, the clueless bozos wrapped them in a cheap rug, instead of the dozen-thousand-dollar antique.
Dogs. My aunt had a dog, very barky, too (at least he barked at me). She was burgled, too. Unless you like dogs, and like walking them, this seems like a poor idea. (Consider what else you could be doing with the dog whenever you are walking it.)
Jaguars. A neighbor of a friend kept one, told his girlfriend to feed it while he was on vacation, she skipped a few days, the cat almost took her head off before it was shot. (Guns ARE good for animal pests.)
Motion sensors are good. It might be interesting to use a black light, instead of a regular one, so that any people (usually wearing detergent-brightened clothes) will glow in the dark.
There's a sprinkler that is supposed to repel pests -- it detects motion, orients, and squirts some water in the direction of the motion. Might work on people, too; at least, it would get their attention.
Cameras are good; a hidden camera is good for keeping a record, but if there was an obvious lens-looking thing with a blinking red LED where someone was sure to see it, all the better. The obvious "camera" should trigger a loud alarm if someone messes with it.
We had a cat once, that like nothing better than to surprise you in the yard, in the dark, by climbing up your leg fast like it was a tree. Get a cat like that.
It's a shame that you cannot train a skunk. Certain parts of the world, a plastic snake on a string, plus a rattling noise, would do the job nicely.
As others have noted, there is Java. And (at minimum) Python. His I-wonder-if supposition about a malloc that is backed up by GC is old news; the Boehm-Demers-Weiser collector was used exactly like that 15 years ago (for example, in the first Modula-3 runtime system, and a friend at HP linked it into an X server). Ben Zorn used it in much the same way to take (now dated) measurements of the time and space costs of garbage collection (executive summary -- the cost is mostly a space cost).
I worked, at CenterLine, on a follow-on for CodeCenter that used compiled-in checks to get similar checking at a higher speed than the intepreter. It was a wonderful accomplishment, but it was still vastly slower than a good Java or Modula-3 implementation. Use a safe language, end of stupid security bugs, and you can spend more time worrying about the subtle ones.
One more thing to note, if you take the draconian view that warnings are for wimps: I found one real program, in all that I tried as tests, that did not generate a single warning during its execution, and that was gzip. One of the emacses was our error-filtering test case; running to the "dump" step, it generated over one million diagnostics, which we managed to automatically filter down to one thousand.
I really have to wonder about the author's background. He claims to care about this, yet has apparently never used Java outside of a browser, nor played with the BDW-GC for as a leak backstop. I sure do wish the ACM editors were a little more clueful.
If you are looking for good schools that are "less coastal", consider (and I will leave good ones out, apologies in advance) Rice (Houston), Cornell (Ithaca), UIUC (Illinois), Washington U (St. Louis), Duke, UT Austin, Rutgers, Purdue, Indiana U, U Wisconsin, U Arizona, (I realize this depends on the definition of "coastal").
A friend and former colleague got his undergrad at Wabash College, grad at Cornell.
As far as white men vs the rest of the world, at the research labs I've seen (and I work at one now) white men are still at about 50%, maybe more. African-Americans are incredibly underrepresented (those with "black" skin are most often African-not-American). The women I've met in CS research are generally outstanding; I think the old rule of twice the work for half the recognition still holds.
And do note, I am a white guy, as Wasp as they come, legacy graduate from Rice, descendant of legacy graduates from Dartmouth. But, I can count heads, and most of them still look like me. 14 people under my manager, 1 woman, 13 definitely "white", 9 speak unaccented English (i.e., raised in US or Canada).
Apparently fewer students are pursuing EE/CS as a career. Supposedly down 33% over the last two years at MIT, 23% in the country as a whole this year. Potential gradual students are
opting for Wall Street instead. See
an article in today's NYT
Speaking as a former bytecode-to-native compiler writer, I can assure that if someone writes a compiler from Your Favorite Intermediate Language (YFIL) to native code, then someone can crack it. Every (stupid) obfuscator trick out there, the compiler has to tolerate in its quest for verifiable, compilable, optimizable code.
Examples of Stupid Obfuscator Tricks include:
Scrambling exception ranges so they don't nest.
Inserting non-structured GOTOs
Inserting never-executed exits from synchronized blocks
There are others, these are just the ones that I recall. A compiler (static or JIT, it does not matter) must deal with all of these.
There are two outs that I know of. One is to only use interpreted code and morph it on the fly (still seems vulnerable to an observant interpreter, but perhaps the amount of necessary observations can be made extravagantly large), the other is to require use of a "trusted" compiler (which, in turn, requires use of a "trusted" OS to prevent substitution of an untrusted compiler, which in turn requires "trusted" hardware to prevent
substitution of an untrusted OS).
Don't need to move to California, just work for a California company (e.g., Sun, Intel, Oracle, Apple, as well as all the littler ones). Any well-run CA company doesn't even bother putting that crap in their employment agreements.
Here in Massachusetts, things are different. I've run into at least three relatively silly employment agreements here -- paranoid, overbroad, ask me to sign away lots of rights, no thank you (I ran the worst of these past a lawyer friend and a lawyer I paid, and this was their opinion).
I did run across one MA company that had a completely sensible employment agreement, and that was Savaje. Great guys, nifty product, I hope they win (no, I do not work for them).
Binary compatible means same data layouts, same parameter-passing conventions, same conventions for shared libraries and position-independent code. However, between those interfaces, the generated code is probably different.
Think of it like nuts and bolts -- a nut and bolt are compatible if they have the same diameter and threads per inch, but they may be made of carbon steel, steel, bronze, nylon, titanium, whatever.
Depends upon what sort of brains they put into it. They could put a whole-hog inertial guidance system into it (just like an ICBM) and integrate accleration over time to get velocity. If the laptop is moving down fast....
There are numerous ways to know that a piece of mail is not spam, and we should use them all and accept them all.
1) Transitive trust.
a) If a PGP name server is known to contain links to actual people, then messages signed from that server are ok -- if they are spam, you can track down the sender.
b) if an ISP is known to enforce a no-spam policy, ditto.
c) If the HELO domain name resolves to the IP via a trusted DNS server (e.g., dynamic DNS from tzo.com), ditto.
2) white list
a) users, per user
b) ISPs, per ISP (I don't get spam actually mailed from aol.com anymore -- I think I can usually trust them).
3) challenge-response -- if you challenge incoming emails, surely you will process them when they arrive.
4) time-limited email address from web pages, combined with known-user databases. dr2chase+2003-10-03@etc will work for initial communications (from clicked web links) for only a few days, though anyone initiating an email exchange in that window can reuse the address as much as they want (this is to allow easy-click sending and correspondence from web pages).
5) hash-cash -- prove you solved a hard problem uniquely associated with this particular email, and you've proved that you cannot be sending too much mail per day. Therefore, you must not be a spammer.
The main point here is that ANY one of these methods can be used to show that a message is not spam. Mail receivers should deploy all of them, now. Mail senders should also get to work -- in particular, user agents should include "this will look like spam" sensers, so that they can ensure that legitimate messages do not look like spam.
The other half of the spam solution is to use "economic" punishment in the sendmail protocol. Don't ever reject email -- a clean rejection is cheap and fast. Hold the connection open. Delay before replying. Use that time window to gather information ("look, 100 incoming SMTP connections from the same source in the last 30 seconds").
The sad thing is, if/when you have an idea that you think deserves investment, your job will be to distinguish yourselves from these guys so you can get that investment. Remember, anyone can say "honest, we're not crooks". The trick is proving it to the satisfaction of the investors.
I don't know the details of the investment, but if Ren bought in February and sold now, they'd make $15-20 on each $4 invested. That's not a bad return for less than a year, so I cannot even say that Ren's plan is a bad one, financially speaking. Remember, in business, if something is profitable and the compensation's enough to cover the jail time, then it must be ethical.
The piper always charges, whether for manual or automatic memory management. The costs have been measured, and for decently large systems, the gains in reliability, maintainablility, and time to market are well worth the additional costs of garbage collection.
As far as your remarks about OS-level code go, people have experimented, successfully, with writing large portions of what might normally be regarded as "the kernel" in a garbage collected language. One example is the SPIN project at the U of Washington during the 1990s. Because they used a safe language (which generally implies garbage collection) they were able to maintain the usual security guarantees while allowing greater freedom in loading code into the kernel. Avoiding the kernel-user boundary at busy interfaces more than made up for the in-the-small overhead of using a safe language. There will always be people capable of writing such code, and compared with the other start-up expenses involved in computing, the costs of motivating those people to be interested in working on the OS will not be excessive. I'm able, and with any luck I'll be alive and mentally sharp (like all my ancestors) for another 40 years.
Another example comes when you do concurrent programming. Reference counting becomes much less attractive when it requires frequent use of bus-locking instructions to keep the counts consistent.
I have also done the experiment of writing code in Java, and then working to insert typed storage pools to avoid activating the GC. The end result does run faster, if you take care to recycle complex data structures without shredding them into parts (by analogy, recycling glass bottles by refilling instead of melting and reblowing), but it does require interface changes, and it does require peculiar distribution of responsibility for reclamation. You might say this is "good design", but it doesn't look good to me -- it looks strictly more complex and more fragile. There is a large quantity of design, but the quality goes down.
And, because this is an economic exercise, it is sometimes worth making the effort to avoid heap allocation, but in practice, like all optimization, this should be done after measurement, not before measurement. Since this will require changes to interfaces, it's not fun, but to simply design the entire system as if it were all one big critical inner loop is wasteful (crazy, actually).
And yes, I AM an Expert. I have done GC research, studied its interactions with optimizing compilers, written interpreters and compilers for garbage-collected languages, written optimizing phases for compilers for those garbage-collected languages, and measured the performance of different garbage collectors and GC-using applications as I optimized them.
Regarding your "solid minute" remark. The last time I played games with rate benchmarking, I saw a rate of 10Mb/second on a 200Mhz Pentium Pro with 66Mhz memory, where the size of the "dense" portion of the live set is what matters (this was with two crude collectors, one of them someone's adaption of the Boehm-Weiser collector). A solid minute of collection would require, on that now-slow processor, 600 Mb of dense live set. This is a worst-case conservative estimate of GC performance -- the collector is crude (not generational), the processor is slow, and I am assuming a large dataset of pointerful objects. In practice, even "crude" copying collections on modern machines run in under a second, because most applications don't have that much live data.
In addition, one can write a provably real-time collector. It's not done often because there are associated overheads (humans are fine with milliseconds of pause, so this would trade off performance losses for no perceived latency gains), but it can be done. Henry Baker wrote a paper on this long ago, and their have been improvements on his work since then (e.g., the "treadmill collector"). Real-time memory management with reference counting always requires careful work, because releas
Slashdot Mirror
No, you probably would not. In my now-long-and-checkered career, I once worked for about five years for a company that was developing a Windows (NT/2k/XP) application, and I used Windows for everything (desktop, you name it). We also had Cygwin installed so we could get our almost-Unix fix.
Next job after that was a Linux desktop, and I loathed it (keep in mind that before the Windows job, was about ten years of Unix desktop and development. I was plenty familiar with the X/Unix/Emacs world). I managed to lay my hands on a TiBook, beefed it up to 1G of memory, and I used that for my desktop instead, and it has been my desktop ever since.
My colleagues from the Windows job? Both of them now use Macs, too.
Not so true for plants. Often the diploid offspring are infertile, but conversion to tetraploid form can restore fertility. (This is true for lilium species, at least. For mammals(at least), getting converted to tetraploid form is a bad idea.)
In addition, plant tissue culture makes the issue of fertility somewhat less of an issue, again depending on the plant. Much of the tree-borne fruit that you see in any store (apples, oranges, peaches, I think bananas), was propagated asexually (grafted onto root stock).
The scale of "conventional" techniques for improving species (e.g., plant 10 acres of pink lilies, keep the 100 best stems, crossbreed, repeat for 10 generations) is sufficiently large that I would not bet too much money that accidental gene transfer/modification (by viruses/bacteria/background radiation) isn't occurring anyway. I don't think anyone ever did any formal safety tests on the first navel orange; they saw that it was seedless and tasty enough, and propagated it all over the place.
Essential? Till I was 12, I lived in a house with no public fire service, no public road service, no public water service, no public sewer service. 30+ years later, said house is still on its own water and sewer. Only local government services we got were school and police (this assumes that the police could negotiate 1/2 mile of dirt road, not a sure thing). "Animal control" was a shotgun. I think you need to consider that "essential" is a matter of opinion, and as such, other people might have different opinions. If the people who run a town decide that some service is essential, and don't get voted out of office, then in one important sense, that service is indeed essential.
Didn't see any full text at the Wiley site, only an abstract. Complain all you want about the NYT wanting DNA samples to view their articles, they at least let you look for free.
I've been trying to get my son's recently-purchased copy of SimCity to work. Near as I can tell, it is just plain busted, and fat chance getting any help out of EA. Their FAQ has suggestions, but none of that works. Good luck getting to a real person for help. And yes, I know that corporations serve their stockholders, but the usual recipe for doing this is by finding a way to get people to want to be their customers. All my recent encounters with EA and MS have been frustrating and timewasting; its seems sensible to see if other companies are more interested in my business.
In two body problems, what determines the worst-case acceleration is the difference in the body weights, and the elasticity of the collision (better if the cars stick together instead of bouncing -- crumple zones again). What little safety advantage large cars and trucks have, they gain at the expense of other people's safety. (And, as has been demonstrated by problems with tires and rollovers, SUVs are not exactly safe anyhow).
Smarter cars could improve on safety slightly by braking early, pretensioning belts, and perhaps extending adjustable bumpers to take some of the edge off the collision.
Note that polynomial equivalence admits an awful lot of difference in difficulty -- I can get to within a factor of 2 in either traveling salesman or bin packing w/o too much work, but guaranteeing to be within any factor M of optimal K for graph coloring is equivalent to proving that P=NP. (So graph coloring is in some sense a lot harder than TSP or BP. And no, I do NOT remember the proof).
Unfortunately: $100, and I don't see anything like it on their site now.
I would definitely spring for a bag with the laptop pocket, whatever the brand, but I am pretty hard on my stuff. I'm sure Eagle creek is not the only good brand.
First, you write as much as possible of the VM in a safe language. (e.g., Java). This minimizes the amount of code for step two. Ideally, the non-safe portions of the VM are doing things like mapping and unmapping memory for the GC, and allocating, starting, and stopping threads -- and that's all. In the JVM that I worked on, there is ONE INSTANCE of each Windows system call (i.e., socket read, socket write, file read, file write, etc).
Second, you read the code; ideally, all I/O is in the form of system calls reading blocks of data. In the case of the VM I worked on, that means you need to understand very well exactly what that single instance of each useful system call is doing. Only let your best people work on this code, and then check their work anyhow. Ideally, write proofs and get automated checkers to verify them (this is all a static type system is, after all).
Third, all other I/O layers are written in the safe language. If something goes wrong there, it gets caught by bounds checking.
There's been other work to guard against "adversaries" that might exploit type flaws in your VM, but ultimately it all boils down to desk checking, and minimizing the amount of code that must be checked in that way. I saw a talk by Andrew Appel explaining how, for an ML compiler, this required checking the 5000 lines of assembly language that gcc produced compiling their theorem checker (because how do you know that gcc is a correct compiler?)
Sadly, practice diverges from theory at times. Various JVMs depend on native code that they don't really need to, and thus have increased their vulnerability to buffer overflow attacks. For example, I think that most JVMs call zlib as a DLL -- and zlib recently had a buffer overflow in it. They call native code to manipulate JPEG and PNG images -- and both of those recently were discovered (on various platforms) to have buffer overflow problems. So, in practice there are still risks, but the way to reduce those risks is to rewrite the risky code in a safe language, not write more code in the risky language. We can rarely afford to desk check 250,000 lines of code, and it's irresponsible to assume that it contains no holes merely because none have been found yet.
A safe language implementation of things like zlib and jpeg is not necessarily slower, though by default it will do more checking. If you can prove by hand that the bounds checks aren't necessary, then there's a good chance that the compiler will too (and if you cannot prove it, what business do you have not using the safe language?) One way to improve the performance of code in a safe language is to make the proof-of-unnecessary-checking more obvious, so that the compiler will get it. For example, you might do all the bounds checking up front before entering a loop. If no exception is thrown, then the fact of the correct bounds is established for all the following code. Better, you end up with a piece of code that does not get halfway into whatever side effects it was planning to do, then throw an exception leaving things in an uncertain state.
Java also makes multithreading easier and more portable, so in those cases where a problem could be attacked in parallel, you just might do it. This is much less true of C.
I was not that Java disciple. Back then, the joke was tht the GC should just print "NFS server not responding, still trying" and everything would be ok. Now, it needs to print "47 out of 50 images loaded ..."
Garbage collection, in particular, is coming along nicely. Check out "Metronome" by David Bacon, of IBM. You set the knobs, it tells you how much memory you will need, and it gives you GC with real time performance. No pauses.
Or, consider the machine that Azul is working on (good luck getting details now that they are in some sort of a quiet period). It has hardware support for read and write barriers, plus a good story for stack caches. Chances are good its GC pauses will be tiny (1-10 ms).
I can also tell you that the market very much prefers JIT compilation. I worked on an ahead-of-time-compiling JVM, and there were a couple of others built by other companies. I don't work on that JVM any more, and the other AOT JVM companies have either failed or gone into other lines of business.
So, great story, but not exactly correlated with reality.
On the other hand, consider all the buggy apps that we (who sometimes administer Windows machines) have needed to patch over and over again over the years. If I am unwilling to run an application in the first place because of its poor security, does it really matter how little memory it uses, how fast it runs, or how well it gets along with the other worm-friendly apps?
Big if, that "written correctly". Do you dare to certify that any non-trivial piece of C code is free of buffer overflows? I would never make that bet, but it is true of (pure) Java.
That's not funny, that's stupid. Stuff written in Java is better than stuff written in C or C++ because there are no frapping buffer overflows in Java code (though, sadly, there may be in the native libraries that they sometimes call). I would have thought that people would be aware of this, given recent PNG and JPEG-related vulnerabilities. By writing Sphinx in Java, we can be sure that run-on sentences will not accidentally overflow a buffer and install a worm.
Guns. After my grandfather died, burglars broke in to the empty house, stole all the lovely guns (some of which I should have inherited). Fortunately, the clueless bozos wrapped them in a cheap rug, instead of the dozen-thousand-dollar antique.
Dogs. My aunt had a dog, very barky, too (at least he barked at me). She was burgled, too. Unless you like dogs, and like walking them, this seems like a poor idea. (Consider what else you could be doing with the dog whenever you are walking it.)
Jaguars. A neighbor of a friend kept one, told his girlfriend to feed it while he was on vacation, she skipped a few days, the cat almost took her head off before it was shot. (Guns ARE good for animal pests.)
Motion sensors are good. It might be interesting to use a black light, instead of a regular one, so that any people (usually wearing detergent-brightened clothes) will glow in the dark.
There's a sprinkler that is supposed to repel pests -- it detects motion, orients, and squirts some water in the direction of the motion. Might work on people, too; at least, it would get their attention.
Cameras are good; a hidden camera is good for keeping a record, but if there was an obvious lens-looking thing with a blinking red LED where someone was sure to see it, all the better. The obvious "camera" should trigger a loud alarm if someone messes with it.
We had a cat once, that like nothing better than to surprise you in the yard, in the dark, by climbing up your leg fast like it was a tree. Get a cat like that.
It's a shame that you cannot train a skunk. Certain parts of the world, a plastic snake on a string, plus a rattling noise, would do the job nicely.
I worked, at CenterLine, on a follow-on for CodeCenter that used compiled-in checks to get similar checking at a higher speed than the intepreter. It was a wonderful accomplishment, but it was still vastly slower than a good Java or Modula-3 implementation. Use a safe language, end of stupid security bugs, and you can spend more time worrying about the subtle ones.
One more thing to note, if you take the draconian view that warnings are for wimps: I found one real program, in all that I tried as tests, that did not generate a single warning during its execution, and that was gzip. One of the emacses was our error-filtering test case; running to the "dump" step, it generated over one million diagnostics, which we managed to automatically filter down to one thousand.
I really have to wonder about the author's background. He claims to care about this, yet has apparently never used Java outside of a browser, nor played with the BDW-GC for as a leak backstop. I sure do wish the ACM editors were a little more clueful.
Cool your flame a little, please.
If you are looking for good schools that are "less coastal", consider (and I will leave good ones out, apologies in advance) Rice (Houston), Cornell (Ithaca), UIUC (Illinois), Washington U (St. Louis), Duke, UT Austin, Rutgers, Purdue, Indiana U, U Wisconsin, U Arizona, (I realize this depends on the definition of "coastal").
A friend and former colleague got his undergrad at Wabash College, grad at Cornell.
As far as white men vs the rest of the world, at the research labs I've seen (and I work at one now) white men are still at about 50%, maybe more. African-Americans are incredibly underrepresented (those with "black" skin are most often African-not-American). The women I've met in CS research are generally outstanding; I think the old rule of twice the work for half the recognition still holds.
And do note, I am a white guy, as Wasp as they come, legacy graduate from Rice, descendant of legacy graduates from Dartmouth. But, I can count heads, and most of them still look like me. 14 people under my manager, 1 woman, 13 definitely "white", 9 speak unaccented English (i.e., raised in US or Canada).
Apparently fewer students are pursuing EE/CS as a career. Supposedly down 33% over the last two years at MIT, 23% in the country as a whole this year. Potential gradual students are opting for Wall Street instead. See an article in today's NYT
Examples of Stupid Obfuscator Tricks include:
- Scrambling exception ranges so they don't nest.
- Inserting non-structured GOTOs
- Inserting never-executed exits from synchronized blocks
There are others, these are just the ones that I recall. A compiler (static or JIT, it does not matter) must deal with all of these.There are two outs that I know of. One is to only use interpreted code and morph it on the fly (still seems vulnerable to an observant interpreter, but perhaps the amount of necessary observations can be made extravagantly large), the other is to require use of a "trusted" compiler (which, in turn, requires use of a "trusted" OS to prevent substitution of an untrusted compiler, which in turn requires "trusted" hardware to prevent substitution of an untrusted OS).
Don't need to move to California, just work for a California company (e.g., Sun, Intel, Oracle, Apple, as well as all the littler ones). Any well-run CA company doesn't even bother putting that crap in their employment agreements.
Here in Massachusetts, things are different. I've run into at least three relatively silly employment agreements here -- paranoid, overbroad, ask me to sign away lots of rights, no thank you (I ran the worst of these past a lawyer friend and a lawyer I paid, and this was their opinion).
I did run across one MA company that had a completely sensible employment agreement, and that was Savaje. Great guys, nifty product, I hope they win (no, I do not work for them).
Binary compatible means same data layouts, same parameter-passing conventions, same conventions for shared libraries and position-independent code. However, between those interfaces, the generated code is probably different.
Think of it like nuts and bolts -- a nut and bolt are compatible if they have the same diameter and threads per inch, but they may be made of carbon steel, steel, bronze, nylon, titanium, whatever.
As opposed to, say, writing an NSF grant to get 4Mb of memory for a VAX 11/780?
Depends upon what sort of brains they put into it. They could put a whole-hog inertial guidance system into it (just like an ICBM) and integrate accleration over time to get velocity. If the laptop is moving down fast....
There are numerous ways to know that a piece of mail is not spam, and we should use them all and accept them all.
1) Transitive trust.
a) If a PGP name server is known to contain links to actual people, then messages signed from that server are ok -- if they are spam, you can track down the sender.
b) if an ISP is known to enforce a no-spam policy, ditto.
c) If the HELO domain name resolves to the IP via a trusted DNS server (e.g., dynamic DNS from tzo.com), ditto.
2) white list
a) users, per user
b) ISPs, per ISP (I don't get spam actually mailed from aol.com anymore -- I think I can usually trust them).
3) challenge-response -- if you challenge incoming emails, surely you will process them when they arrive.
4) time-limited email address from web pages, combined with known-user databases. dr2chase+2003-10-03@etc will work for initial communications (from clicked web links) for only a few days, though anyone initiating an email exchange in that window can reuse the address as much as they want (this is to allow easy-click sending and correspondence from web pages).
5) hash-cash -- prove you solved a hard problem uniquely associated with this particular email, and you've proved that you cannot be sending too much mail per day. Therefore, you must not be a spammer.
The main point here is that ANY one of these methods can be used to show that a message is not spam. Mail receivers should deploy all of them, now. Mail senders should also get to work -- in particular, user agents should include "this will look like spam" sensers, so that they can ensure that legitimate messages do not look like spam.
The other half of the spam solution is to use "economic" punishment in the sendmail protocol. Don't ever reject email -- a clean rejection is cheap and fast. Hold the connection open. Delay before replying. Use that time window to gather information ("look, 100 incoming SMTP connections from the same source in the last 30 seconds").
The sad thing is, if/when you have an idea that you think deserves investment, your job will be to distinguish yourselves from these guys so you can get that investment. Remember, anyone can say "honest, we're not crooks". The trick is proving it to the satisfaction of the investors.
I don't know the details of the investment, but if Ren bought in February and sold now, they'd make $15-20 on each $4 invested. That's not a bad return for less than a year, so I cannot even say that Ren's plan is a bad one, financially speaking. Remember, in business, if something is profitable and the compensation's enough to cover the jail time, then it must be ethical.
The piper always charges, whether for manual or automatic memory management. The costs have been measured, and for decently large systems, the gains in reliability, maintainablility, and time to market are well worth the additional costs of garbage collection.
As far as your remarks about OS-level code go, people have experimented, successfully, with writing large portions of what might normally be regarded as "the kernel" in a garbage collected language. One example is the SPIN project at the U of Washington during the 1990s. Because they used a safe language (which generally implies garbage collection) they were able to maintain the usual security guarantees while allowing greater freedom in loading code into the kernel. Avoiding the kernel-user boundary at busy interfaces more than made up for the in-the-small overhead of using a safe language. There will always be people capable of writing such code, and compared with the other start-up expenses involved in computing, the costs of motivating those people to be interested in working on the OS will not be excessive. I'm able, and with any luck I'll be alive and mentally sharp (like all my ancestors) for another 40 years.
Another example comes when you do concurrent programming. Reference counting becomes much less attractive when it requires frequent use of bus-locking instructions to keep the counts consistent.
I have also done the experiment of writing code in Java, and then working to insert typed storage pools to avoid activating the GC. The end result does run faster, if you take care to recycle complex data structures without shredding them into parts (by analogy, recycling glass bottles by refilling instead of melting and reblowing), but it does require interface changes, and it does require peculiar distribution of responsibility for reclamation. You might say this is "good design", but it doesn't look good to me -- it looks strictly more complex and more fragile. There is a large quantity of design, but the quality goes down.
And, because this is an economic exercise, it is sometimes worth making the effort to avoid heap allocation, but in practice, like all optimization, this should be done after measurement, not before measurement. Since this will require changes to interfaces, it's not fun, but to simply design the entire system as if it were all one big critical inner loop is wasteful (crazy, actually).
And yes, I AM an Expert. I have done GC research, studied its interactions with optimizing compilers, written interpreters and compilers for garbage-collected languages, written optimizing phases for compilers for those garbage-collected languages, and measured the performance of different garbage collectors and GC-using applications as I optimized them.
Regarding your "solid minute" remark. The last time I played games with rate benchmarking, I saw a rate of 10Mb/second on a 200Mhz Pentium Pro with 66Mhz memory, where the size of the "dense" portion of the live set is what matters (this was with two crude collectors, one of them someone's adaption of the Boehm-Weiser collector). A solid minute of collection would require, on that now-slow processor, 600 Mb of dense live set. This is a worst-case conservative estimate of GC performance -- the collector is crude (not generational), the processor is slow, and I am assuming a large dataset of pointerful objects. In practice, even "crude" copying collections on modern machines run in under a second, because most applications don't have that much live data.
In addition, one can write a provably real-time collector. It's not done often because there are associated overheads (humans are fine with milliseconds of pause, so this would trade off performance losses for no perceived latency gains), but it can be done. Henry Baker wrote a paper on this long ago, and their have been improvements on his work since then (e.g., the "treadmill collector"). Real-time memory management with reference counting always requires careful work, because releas