Yep. That was covered in the part where I was talking about how garbage collectors have really improved in the past few years. That is why most GCs nowadays are concurrent, adaptive, and incremental. Otherwise they interfere with the application too much.
I was using C++ as an example of a language that was "higher level" than C. Lisp and OCaml also fit that description (as well as the "higher level than C++" description). The point was that high-level languages can, in some cases, actually BEAT C in PERFORMANCE, let alone programmer productivity. Look at the "Great Computer Language Shootout" page for more info. OCaml is right up there with C and C++ in performance.
So the point is that people shouldn't be afraid of "high level" features like GC. While some high level languages have lousy perf, others are just as fast or faster than the "low level, bare metal, super-efficient" languages.
It's even better than that. In many cases, GC can be almost as fast as malloc/free. Looking at the way things are going, I am pretty sure that in the near future GC-based code will be faster, not slower, than equivalent malloc/free code:
A compacting GC heap can make allocation into a REALLY fast operation (unless it triggers a collection), and there is no time spent deallocating. On normal heaps, malloc/new can take quite a lot of work (thread synchronization, best-fit free list searching, etc.). If you amortize the time the GC spends in collection over the allocations, the average allocation isn't that much slower than the corresponding malloc/free. Best of all, the gap is shrinking. Soon, GC may be FASTER overall than malloc/free in many real-world situations. It obviously depends on memory usage patterns and collection strategies, but it is starting to happen.
If you're using GC, your program doesn't have to do all of the bookkeeping anymore. The amount of time spent in resource tracking in big programs is fairly significant -- where the same object is shared by many parts of the program, figuring out when the item can be released is nontrivial. Under a GC, this is handled by the collector. In some cases, the GC can handle the bookkeeping more efficiently than would have been feasible with manual bookkeeping.
As CPUs get faster and storage (memory and disk) gets (relatively) slower, it becomes more and more attractive to spend extra CPU cycles to try to make better use of cache and memory. An L1 cache miss costs around 4-10 cycles; an L2 miss can cost 100-400 cycles; a page fault costs millions. The CPU time spent in garbage collection can become insignificant when compared with storage access time. Do you take the cache line size into consideration when you call malloc? I sure don't. But compacting GC implementations are starting to take things like that into consideration when they collect, and they rearrange the memory of the process to maximize cache hits and minimize memory waste. They can help your program make more efficient use of the cache, and perhaps reduce the working set. Just a 5% reduction in page faults would more than offset all but the most CPU-intensive garbage collectors.
GCs usually collect on a separate thread. That means that with a properly designed collector, while your program is blocked on IO or waiting for user input, the GC might be cleaning up the heap on a low priority thread. With luck, your main thread might NEVER actually be interrupted for a collection -- all of the collection can be done while your work threads were waiting for something else. Your memory management tax was paid in the background, while the machine was otherwise idle. On the other hand, with malloc and free, the memory management tax is paid up front by the currently executing thread. While this isn't always the case (i.e. CPU-bound processes), most apps are NOT CPU-bound, so this is a likely scenario in the future (if not the present).
While I don't think GC is quite to the point where it is free or beneficial to the performance of the average application, it is a lot less harmful than most people think. Given that it simplifies the code and eliminates a lot of bugs (usually more than it introduces), it is definitely worthwhile in almost all new application code (kernel-mode code isn't quite there yet, but it's coming), with only a small performance penalty. And I suspect that it won't be too long before it starts to be more of a speed booster, not a perf hit.
I think this is just another step in the process of handing another menial task over to the CPU. We moved from binary to assembly, assembly to low-level languages, low-level languages to higher-level languages, etc. At each step, the new method had a performance penalty at first, then as the new method matured, it turned out to actually be faster than the old method it replaced, while dramatically increasing programmer productivity (i.e. modern optimizers can usually do a better job than an assembly language programmer; often C++ code is faster than the equivalent C code since the compiler has more information to work with and the programmer can make use of more effective techniques like templates).
Excellent point. The "lock" that has been broken is just that -- a lock, designed such that those who only use Word to edit the file can't edit the file without the password. This is the same as saying that a lock on a door is only effective against those who only come in through the doorway. The file isn't encrypted in any way, just locked. It is just a flag that tells Word to not let you view or edit the file until you've provided the password.
There have always been a lot of ways around this lock. First, you can always generate a matching password (equivalent to picking the lock on a door). Or you can just zero out the password field in the file (the point of the "Security Advisory" linked in the article), which is like taking a door off of its hinges (I'm nearing metaphor breakdown here, but you'll just have to deal with it). Or you can just use some other editor (a hacked version of Word, a hex editor, or an Open Source editor) that lacks the programming to enforce the lock flag. That would be like ignoring the door and going for an open window or the back door or something. (Metaphor over, you can open your eyes now.)
Remember that the file format was designed back when any non-trivial encryption was evil, and exporting it was considered espionage. Also remember that Word is targeted at students, teachers, and soccer moms just as much as it is targeted at CEOs and lawyers. The average Joe is satisfied with the trivial lock, and in fact would probably prefer less security, since that means if he/she is careless and forgets the password, the document can still be recovered (cost/benefit analysis: potential for damage if the document is opened by an outsider * probability that it will be opened by an outsider --versus-- potential for damage if my password is lost * probability that I will lose my password). Most people aren't protecting documents against evil government agents -- usually it is just their little brother or the guy in the next office that they need to keep out.
Anyway, the bottom line is that this was never meant to be a safe deposit box, not even barbed wire and chain link. It is a simple lock, and just as a good screwdriver or a pair of bolt cutters can get you past a lock in no time, a real computer person would never even blink if confronted by something like this, and Microsoft never advertised it as anything else.
On the other hand, they are now advertising new encryption and protection features that are the real thing. This time, they are making a strong claim of decent encryption: if you don't have the appropriate certificate, you're going to have a very hard time opening this document. Of course, once it is opened, the "Do Not Forward" or "Do Not Save Unencrypted" flags are once again just trivial locks, but that is a separate issue -- you have to open the document before you could do that.
Insightful? Heck no. This was supposed to come across as sarcasm. (It isn't quite "Funny" either, but that isn't a big deal since I'm not trolling for Mod points). Sheesh, moderators these days!
See, it is people like you who make "Ask Slashdot" suck. The guy asks a lame question, and (assuming your answer is correct), he immediately gets a great answer. This kind of positive reinforcement is only going to result in even more lame postings.
As long as people can ask lame questions and get decent answers, they're just going to continue asking them.
I've always been a BSD fan, but mostly for server needs. I've never really tried it for desktop use. For server, 5.1 was plenty stable. However, several ports for more "desktop-ish" apps are still broken. Most of them aren't important, but there are a few that I am looking forward to having fixed (boehm-gc, mono, etc.).
You see, the hack requires that the licensed owner of the AAC files do the decryption. You can't strip the DRM (with this program, anyways) unless you can play it.
This means that if your files are seen stripped on Kazaa, the RIAA has a whole lot more ammo in court -- you had to strip the DRM before sharing your files.
I fell asleep before I could finish my post last night, and I hit "submit" as I was drifting away. So continuing where I left off...
There is a third category of transaction security, where even after observing the entire transaction, an eavesdropper doesn't have enough information to impersonate you. Generally, this takes the form of challenge-response. The server asks "42365?" and you answer "92581!" which is the correct answer. But an observer still doesn't know how to impersonate you, because next time, the server will ask "98765?" and the observer doesn't know that the answer is "45678!". Smart cards are like this, which is why they are more secure than credit cards or passwords.
Each of these three categories still have varying degrees of security.
In the first case, it is easy to use the information from a stolen credit card, but it would be pretty hard to make use of the information from a retinal scan. In both cases, you have all the information, but it's quite a pain to get your eyes replaced (if you get hungry, there's a sandwich and some milk in the fridge...).
In the second case, while reversing a crypt password isn't too tough anymore, it still takes a bit of work to reverse engineer a 1024-bit RSA key. In both cases, the information is out in the clear, but factoring a 1024-bit number is a lot more work than running the crypt algorithm a few billion times.
In the third case, "Mary had a what?" --> "Little lamb!" is easier than a smart card transaction.
While we would love to have a cryptographically strong variation on the third case for every possible authentication/encryption transaction, it just isn't practical. In the case of WEP/WAP/Whatever, there are a lot of limitations to work around. It has to work on cheap hardware, it has to be fast enough to handle the traffic, it has to work in the face of many dropped packets, it can't inconvenience the user too much, etc.
While I can think of a few things that I might have done differently, it seems like the new protocol is decent, given the limitations they were facing. While I wouldn't want to trust top-secret information to it, it seems that it is good enough for the average Joe.
Kudos to a sibling post who brought up the fact that the only way to prevent this kind of attack is to limit the number of attempts possible in a span of time. The article/post failed to emphasize this enough.
When possible, it is nice to find an algorithm or a protocol that allows two parties to authenticate without actually revealing enough information to identify the key.
The lowest level of security would be where everything is out in the open for any observer -- they still have to observe, but one observation is all that is needed. For example, if you hand somebody your credit card, they have all of the information necessary to use it to steal from you -- it is all there on the card, perfectly legible. As another example, if you walk up to a terminal and type your password, anybody with camera pointed at the keyboard or some kind of electronic keylogger will be able to record your name and password on the wire, and then they know everything they need to know to take over your account.
Things are slightly more secure when some additional work is required after getting the information. The old-school UNIX passwd file with encrypted passwords out in the open was like this -- anybody could copy the passwd file, but they would then have to run a cracker on it for a few weeks or months before anything useful showed up. Now that computers are faster and security is more of an issue, the passwd file is shadowed so that the passwd file doesn't actually have the encrypted passwords, which is a good thing because the original crypt algorithm can now be cracked pretty easily. Thus exploit is similar -- you can watch a session initiation, and with only that info, you can crack the password.
Regarding knots, mips, flops, and a lot of other things: yes, you are correct. Technically, these units already include the "per (unit of time)". However, it is an easy rule to forget, due to the fact that the units in question break standard usage rules in the first place. While two wrongs don't make a right (but three lefts do), two wrongs seem reduce the shame of the second wrong.
In the case of knots, the same unit (knot) is used for distance and speed. You tell me how that isn't screwball to begin with. Even though knots is a valid measure of distance, the convention is to use "knots" instead of "knots per hour" since it is also used for speed. So those who make the mistake either don't know this irregularity of usage, or have a conflict between the regular use of units (follow "distance" with "per (unit of time)" to turn it into speed) and the convention for usage of the word "knot".
Mips and flops -- they are plural. Removing the "s" technically leaves you with "millions of instructions per" but we're more accustomed to situations where removing the "s" makes the plural into a singular. So it is easy to forget, since the trailing "s" doesn't mean what it usually means in English usage.
This is great -- I would probably be 15 pounds lighter if Mtn Dew were low-cal.
I'm looking forward to low-cal fat now. But I fear it will be a while. Whereas substitute sugar just has to be sweet (creative cooks have found ways around the missing browning/cooking characteristics), fat has to have texture and volume characteristics in addition to the flavor requirements. That adds hard-to-meet requirements to any potential solution.
With sugar, you can substitute it with some chemical that is 600X sweeter than sugar, so you hardly need any of it for it to do its job. With the volume requirement of fat, you can't just get away with a tiny amount of some chemical 600 times more "fatty". So you look for something that has the same volume and texture, but that doesn't make you get fat.
One way to do this is to use something that seems like fat, but that your body can't digest. Unfortunately, if your body doesn't digest it, it still has to go somewhere. If the fat substitute is completely undigestable, it will stay in your intestines all the way through -- and the consumer will have a nice case of the runs when it gets to the other end.
If you go for something that can be absorbed by the intestines, but somehow not be metabolized by the body, you're asking for a lot of trouble. Once it is in the bloodstream, how does it get out? It has to be something that can either safely pass through the kidneys, or something that the liver can route through the gall bladder (in which case, you're back to problem #1).
One approach might be something that is water-based but has oil-like properties until it hits the stomach acid, at which point it breaks down so that the water can be absorbed. I'm no chemist, but that seems to be asking a lot.
Here's hoping there is a chemist out there who isn't as easily discouraged as I am...
In addition, I don't know where he comes up with "early next year." Everything I've heard up till now says that Visual Studio 2004 is coming "late next year." And I've been following it pretty closely.
Perhaps I missed something in the news, maybe about a new.Net SDK coming out separately from Visual Studio.Net 2004. But "early next year" is highly doubtful.
First, he is going for the best way for him to find the solution. The objective isn't always to challenge yourself -- sometimes you actually want to solve the problem. And if you're better at programming than numerical analysis, then you're more likely to find the solution through programming.
Second, finding a good way to brute-force this solution isn't trivial. With that many billions of nodes to trace through, it takes a good bit of effort to find a way to optimize it enough for a computer to chew through in a reasonable amount of time. With almost a trillion nodes, you've got to be relatively clever to find a way to manage that much data without seriously crimping the computation speed.
Third, there are some problems that don't have any better solutions. Remember the Halting Problem? Church's thesis? That time your wife/girlfriend asked if she looked fat?
Actually, in a well-written DB system on a modern MMU-based OS, there is no difference between DB cache and filesystem cache. The data gets read into "filesystem cache", which is then mmapped into the "DB cache". The same physical memory will be used anywhere that particular portion of disk is needed, until the data gets flushed or swapped out.
I haven't read the whole thing, but I've read parts of it. Some of it is quite good, but other parts... Well, I'll just say that he doesn't let the facts stand in the way of the point he's trying to make.
Really, it just blew me away how biased he was in some areas. For example, about two years ago, I was reading the draft edition. In his section where he was discussing various operating systems, he compared Windows to UNIX. He made some very broad, very negative statements about Windows that simply weren't/aren't true. The link at the bottom of the page asked for corrections and suggestions, so I sent him a short email with some additional information. He replied, and admitted that he didn't really know much about Windows since he didn't use it very much, and that the information was all second hand. I pointed out some factual errors, along with references to back up the corrections. The discussion seemed very positive at the time. However, now that the book has gone to print, I have looked over that section to see how it turned out. Not much has really changed -- some of the most blatant mistakes have been corrected, but many factual errors of which he was fully aware remain in the printing edition. Most importantly, the tone of the section is very authoritative and negative towards the technical aspects of Windows, when ESR admits that he really doesn't know much about it.
I guess that tells me what I wanted to know about the book. It may have some wonderful insights about the "UNIX way" (which is actually pretty cool), but the author isn't interested in making me wiser and better informed -- he's pushing an agenda. His statements are heavily slanted towards what he wants people to believe, and he is willing to bend the facts to strengthen his case.
Personally, I think he would have no trouble defending his position with solid facts. There is a lot of good in the "UNIX Way" of doing things. He shouldn't need to twist things to get his point across. This simply discredits him, and by association, discredits the Open Source movement in general.
There are plenty of books out there about UNIX, more than I'll ever be able to read in the limited amount of time I have for bedtime reading. I'm not going to spend my time on one that I can't trust to give me the straight facts.
Slashdot Mirror
Yep. That was covered in the part where I was talking about how garbage collectors have really improved in the past few years. That is why most GCs nowadays are concurrent, adaptive, and incremental. Otherwise they interfere with the application too much.
I was using C++ as an example of a language that was "higher level" than C. Lisp and OCaml also fit that description (as well as the "higher level than C++" description). The point was that high-level languages can, in some cases, actually BEAT C in PERFORMANCE, let alone programmer productivity. Look at the "Great Computer Language Shootout" page for more info. OCaml is right up there with C and C++ in performance.
So the point is that people shouldn't be afraid of "high level" features like GC. While some high level languages have lousy perf, others are just as fast or faster than the "low level, bare metal, super-efficient" languages.
While I don't think GC is quite to the point where it is free or beneficial to the performance of the average application, it is a lot less harmful than most people think. Given that it simplifies the code and eliminates a lot of bugs (usually more than it introduces), it is definitely worthwhile in almost all new application code (kernel-mode code isn't quite there yet, but it's coming), with only a small performance penalty. And I suspect that it won't be too long before it starts to be more of a speed booster, not a perf hit.
I think this is just another step in the process of handing another menial task over to the CPU. We moved from binary to assembly, assembly to low-level languages, low-level languages to higher-level languages, etc. At each step, the new method had a performance penalty at first, then as the new method matured, it turned out to actually be faster than the old method it replaced, while dramatically increasing programmer productivity (i.e. modern optimizers can usually do a better job than an assembly language programmer; often C++ code is faster than the equivalent C code since the compiler has more information to work with and the programmer can make use of more effective techniques like templates).
Excellent point. The "lock" that has been broken is just that -- a lock, designed such that those who only use Word to edit the file can't edit the file without the password. This is the same as saying that a lock on a door is only effective against those who only come in through the doorway. The file isn't encrypted in any way, just locked. It is just a flag that tells Word to not let you view or edit the file until you've provided the password.
There have always been a lot of ways around this lock. First, you can always generate a matching password (equivalent to picking the lock on a door). Or you can just zero out the password field in the file (the point of the "Security Advisory" linked in the article), which is like taking a door off of its hinges (I'm nearing metaphor breakdown here, but you'll just have to deal with it). Or you can just use some other editor (a hacked version of Word, a hex editor, or an Open Source editor) that lacks the programming to enforce the lock flag. That would be like ignoring the door and going for an open window or the back door or something. (Metaphor over, you can open your eyes now.)
Remember that the file format was designed back when any non-trivial encryption was evil, and exporting it was considered espionage. Also remember that Word is targeted at students, teachers, and soccer moms just as much as it is targeted at CEOs and lawyers. The average Joe is satisfied with the trivial lock, and in fact would probably prefer less security, since that means if he/she is careless and forgets the password, the document can still be recovered (cost/benefit analysis: potential for damage if the document is opened by an outsider * probability that it will be opened by an outsider --versus-- potential for damage if my password is lost * probability that I will lose my password). Most people aren't protecting documents against evil government agents -- usually it is just their little brother or the guy in the next office that they need to keep out.
Anyway, the bottom line is that this was never meant to be a safe deposit box, not even barbed wire and chain link. It is a simple lock, and just as a good screwdriver or a pair of bolt cutters can get you past a lock in no time, a real computer person would never even blink if confronted by something like this, and Microsoft never advertised it as anything else.
On the other hand, they are now advertising new encryption and protection features that are the real thing. This time, they are making a strong claim of decent encryption: if you don't have the appropriate certificate, you're going to have a very hard time opening this document. Of course, once it is opened, the "Do Not Forward" or "Do Not Save Unencrypted" flags are once again just trivial locks, but that is a separate issue -- you have to open the document before you could do that.
Insightful? Heck no. This was supposed to come across as sarcasm. (It isn't quite "Funny" either, but that isn't a big deal since I'm not trolling for Mod points). Sheesh, moderators these days!
See, it is people like you who make "Ask Slashdot" suck. The guy asks a lame question, and (assuming your answer is correct), he immediately gets a great answer. This kind of positive reinforcement is only going to result in even more lame postings.
As long as people can ask lame questions and get decent answers, they're just going to continue asking them.
I've always been a BSD fan, but mostly for server needs. I've never really tried it for desktop use. For server, 5.1 was plenty stable. However, several ports for more "desktop-ish" apps are still broken. Most of them aren't important, but there are a few that I am looking forward to having fixed (boehm-gc, mono, etc.).
I'm not dead!
I'm getting better!
I don't want to go on the cart.
I feel fine.
I think I'll go for a walk.
MAN, i W1$H i HAD M0D P01NT5 RITE N0W!!!!!! :P
Close, but no cigar.
1. Strip DRM.
2. Put files up on Kazaa.
You see, the hack requires that the licensed owner of the AAC files do the decryption. You can't strip the DRM (with this program, anyways) unless you can play it.
This means that if your files are seen stripped on Kazaa, the RIAA has a whole lot more ammo in court -- you had to strip the DRM before sharing your files.
No, no, no. You've got it all wrong.
It's "Never pet a flaming cat."
And it is the standard response when anybody asks for a tip (either kind) or insightful advise.
I fell asleep before I could finish my post last night, and I hit "submit" as I was drifting away. So continuing where I left off...
There is a third category of transaction security, where even after observing the entire transaction, an eavesdropper doesn't have enough information to impersonate you. Generally, this takes the form of challenge-response. The server asks "42365?" and you answer "92581!" which is the correct answer. But an observer still doesn't know how to impersonate you, because next time, the server will ask "98765?" and the observer doesn't know that the answer is "45678!". Smart cards are like this, which is why they are more secure than credit cards or passwords.
Each of these three categories still have varying degrees of security.
In the first case, it is easy to use the information from a stolen credit card, but it would be pretty hard to make use of the information from a retinal scan. In both cases, you have all the information, but it's quite a pain to get your eyes replaced (if you get hungry, there's a sandwich and some milk in the fridge...).
In the second case, while reversing a crypt password isn't too tough anymore, it still takes a bit of work to reverse engineer a 1024-bit RSA key. In both cases, the information is out in the clear, but factoring a 1024-bit number is a lot more work than running the crypt algorithm a few billion times.
In the third case, "Mary had a what?" --> "Little lamb!" is easier than a smart card transaction.
While we would love to have a cryptographically strong variation on the third case for every possible authentication/encryption transaction, it just isn't practical. In the case of WEP/WAP/Whatever, there are a lot of limitations to work around. It has to work on cheap hardware, it has to be fast enough to handle the traffic, it has to work in the face of many dropped packets, it can't inconvenience the user too much, etc.
While I can think of a few things that I might have done differently, it seems like the new protocol is decent, given the limitations they were facing. While I wouldn't want to trust top-secret information to it, it seems that it is good enough for the average Joe.
Kudos to a sibling post who brought up the fact that the only way to prevent this kind of attack is to limit the number of attempts possible in a span of time. The article/post failed to emphasize this enough.
When possible, it is nice to find an algorithm or a protocol that allows two parties to authenticate without actually revealing enough information to identify the key.
The lowest level of security would be where everything is out in the open for any observer -- they still have to observe, but one observation is all that is needed. For example, if you hand somebody your credit card, they have all of the information necessary to use it to steal from you -- it is all there on the card, perfectly legible. As another example, if you walk up to a terminal and type your password, anybody with camera pointed at the keyboard or some kind of electronic keylogger will be able to record your name and password on the wire, and then they know everything they need to know to take over your account.
Things are slightly more secure when some additional work is required after getting the information. The old-school UNIX passwd file with encrypted passwords out in the open was like this -- anybody could copy the passwd file, but they would then have to run a cracker on it for a few weeks or months before anything useful showed up. Now that computers are faster and security is more of an issue, the passwd file is shadowed so that the passwd file doesn't actually have the encrypted passwords, which is a good thing because the original crypt algorithm can now be cracked pretty easily. Thus exploit is similar -- you can watch a session initiation, and with only that info, you can crack the password.
They can nail you for posession. Kinda like drugs.
Regarding knots, mips, flops, and a lot of other things: yes, you are correct. Technically, these units already include the "per (unit of time)". However, it is an easy rule to forget, due to the fact that the units in question break standard usage rules in the first place. While two wrongs don't make a right (but three lefts do), two wrongs seem reduce the shame of the second wrong.
In the case of knots, the same unit (knot) is used for distance and speed. You tell me how that isn't screwball to begin with. Even though knots is a valid measure of distance, the convention is to use "knots" instead of "knots per hour" since it is also used for speed. So those who make the mistake either don't know this irregularity of usage, or have a conflict between the regular use of units (follow "distance" with "per (unit of time)" to turn it into speed) and the convention for usage of the word "knot".
Mips and flops -- they are plural. Removing the "s" technically leaves you with "millions of instructions per" but we're more accustomed to situations where removing the "s" makes the plural into a singular. So it is easy to forget, since the trailing "s" doesn't mean what it usually means in English usage.
No, he wants a thumb drive.
You know, even faster than the bistro drive or that old, outdated infinite improbability drive...
Yes. But it suffers from problem #1 (the runs).
This is great -- I would probably be 15 pounds lighter if Mtn Dew were low-cal.
I'm looking forward to low-cal fat now. But I fear it will be a while. Whereas substitute sugar just has to be sweet (creative cooks have found ways around the missing browning/cooking characteristics), fat has to have texture and volume characteristics in addition to the flavor requirements. That adds hard-to-meet requirements to any potential solution.
With sugar, you can substitute it with some chemical that is 600X sweeter than sugar, so you hardly need any of it for it to do its job. With the volume requirement of fat, you can't just get away with a tiny amount of some chemical 600 times more "fatty". So you look for something that has the same volume and texture, but that doesn't make you get fat.
One way to do this is to use something that seems like fat, but that your body can't digest. Unfortunately, if your body doesn't digest it, it still has to go somewhere. If the fat substitute is completely undigestable, it will stay in your intestines all the way through -- and the consumer will have a nice case of the runs when it gets to the other end.
If you go for something that can be absorbed by the intestines, but somehow not be metabolized by the body, you're asking for a lot of trouble. Once it is in the bloodstream, how does it get out? It has to be something that can either safely pass through the kidneys, or something that the liver can route through the gall bladder (in which case, you're back to problem #1).
One approach might be something that is water-based but has oil-like properties until it hits the stomach acid, at which point it breaks down so that the water can be absorbed. I'm no chemist, but that seems to be asking a lot.
Here's hoping there is a chemist out there who isn't as easily discouraged as I am...
Wrong. Actual conversation:
G: Does this make me look fat?
B: No.
G: No, really, tell me what you think.
B: Of course it doesn't. You look great.
G: Tell me what you really think.
B: I did. You look awesome.
G: You don't have to be nice. Just give me your honest opinion.
B: I did. You look great. If anything, you're too skinny.
G: You're just saying that. What do you really think.
B: (Puzzled. "No" doesn't seem to be working. Maybe it is the wrong answer? Never can tell with girls.) Umm, ok, fine. It makes you look fat.
G: You jerk! I'm never talking to you again!
B: ????
Huh? Whachoo talkin' bout, Willis?
C#? Yeah, under C#, no compiler warnings. Cuz it won't even compile!
C++? Under C++, it is by default a level 4 warning.
In addition, I don't know where he comes up with "early next year." Everything I've heard up till now says that Visual Studio 2004 is coming "late next year." And I've been following it pretty closely.
.Net SDK coming out separately from Visual Studio .Net 2004. But "early next year" is highly doubtful.
Perhaps I missed something in the news, maybe about a new
They state that there are some questions that can only be answered via brute force.
And there is no right answer if a girl asks you if she looks fat, brute force or no...
First, he is going for the best way for him to find the solution. The objective isn't always to challenge yourself -- sometimes you actually want to solve the problem. And if you're better at programming than numerical analysis, then you're more likely to find the solution through programming.
Second, finding a good way to brute-force this solution isn't trivial. With that many billions of nodes to trace through, it takes a good bit of effort to find a way to optimize it enough for a computer to chew through in a reasonable amount of time. With almost a trillion nodes, you've got to be relatively clever to find a way to manage that much data without seriously crimping the computation speed.
Third, there are some problems that don't have any better solutions. Remember the Halting Problem? Church's thesis? That time your wife/girlfriend asked if she looked fat?
Actually, in a well-written DB system on a modern MMU-based OS, there is no difference between DB cache and filesystem cache. The data gets read into "filesystem cache", which is then mmapped into the "DB cache". The same physical memory will be used anywhere that particular portion of disk is needed, until the data gets flushed or swapped out.
I haven't read the whole thing, but I've read parts of it. Some of it is quite good, but other parts... Well, I'll just say that he doesn't let the facts stand in the way of the point he's trying to make.
Really, it just blew me away how biased he was in some areas. For example, about two years ago, I was reading the draft edition. In his section where he was discussing various operating systems, he compared Windows to UNIX. He made some very broad, very negative statements about Windows that simply weren't/aren't true. The link at the bottom of the page asked for corrections and suggestions, so I sent him a short email with some additional information. He replied, and admitted that he didn't really know much about Windows since he didn't use it very much, and that the information was all second hand. I pointed out some factual errors, along with references to back up the corrections. The discussion seemed very positive at the time. However, now that the book has gone to print, I have looked over that section to see how it turned out. Not much has really changed -- some of the most blatant mistakes have been corrected, but many factual errors of which he was fully aware remain in the printing edition. Most importantly, the tone of the section is very authoritative and negative towards the technical aspects of Windows, when ESR admits that he really doesn't know much about it.
I guess that tells me what I wanted to know about the book. It may have some wonderful insights about the "UNIX way" (which is actually pretty cool), but the author isn't interested in making me wiser and better informed -- he's pushing an agenda. His statements are heavily slanted towards what he wants people to believe, and he is willing to bend the facts to strengthen his case.
Personally, I think he would have no trouble defending his position with solid facts. There is a lot of good in the "UNIX Way" of doing things. He shouldn't need to twist things to get his point across. This simply discredits him, and by association, discredits the Open Source movement in general.
There are plenty of books out there about UNIX, more than I'll ever be able to read in the limited amount of time I have for bedtime reading. I'm not going to spend my time on one that I can't trust to give me the straight facts.