Check them all into a repository, then periodically run git-fsck. Git hashes all files in a repository with SHA-1 when they're first committed, and git-fsck recalculates the hashes.
A number of the comments here are more like a bar conversation regarding computer forensics than actual informed advice. Additionally, a number of the comments are wrong wrt/ technical facts concerning NTFS.
The first question is this: do the parties need to retain legal counsel? If A and B are shaking hands and good to go, great. If not, they need to retain counsel.
If counsel is retained, then they need to work with their clients to find a reputable computer forensics expert. And that's all there is to it, really.
But to answer your general question of, does computer forensics apply to this?, well, yes, definitely.
(Disclaimer: I'm a programmer at Guidance Software, and work on EnCase.)
The fact that the presence of PGP on the suspect's computer was determined to be "somewhat relevant" by a Minnesota appeals court in this particular case is hardly the death knell for the 4th amendment.
Evidence from computer media is largely treated as circumstantial in the courtroom. As such, the tact in CP trials like this is to present lots of independent facts to the court with the hope that the aggregate weight of these facts is enough to remove reasonable doubt.
I have and use PGP and have no fear that it'll ever be used as evidence against me. Unless, of course, child pornography is recovered from the unallocated clusters on my disk, internet history show I was surfing CP sites through Google searches, link files pointing to, for an example I had from an investigator this very morning, "Gruppe 3 M:adchen Sperma.jpg", etc., etc.
Another subtlety to understand is typically only a small amount of the technical evidence from a case is presented to the court. Why? Because you don't want to spend hours and hours confusing the judge and jury about the meaning of MFT records and the like. I'd be sure in this case that there's a fair amount of evidence against the suspect (there usually is in CP cases, or they don't prosecute...) and the prosecution cherry-picked what to present in court based on how easy it would be to explain.
Yes. Many games these days are written as if they were a pure simulation. You have your initial state and you change state by applying inputs (user commands & time progression). It should be completely deterministic, so you can have two copies of the game that start with the same state, apply the same inputs, and arrive at the same final state.
This may seem heavyweight, but, hey, processors are fast these days. Many games use scripting languages -- the "I need to write this in C using only global variables" approach of yesteryear is no longer necessary. Additionally, you get some great benefits. Chief among them is replayability and save&restore, but you can also get a relatively simple network protocol (mostly just send inputs, which are small), maintainable code, easy dead reckoning, and the ability to apply other optimizations on top of the model (e.g. lag thrusters). Also, an important insight is that you don't necessarily have to display your simulation state _exactly_. This way you can have reliable code to track the simulation and reap the benefits of such a model, and you can also use a bunch of hacks on top of the simulation to make the user experience look/feel good. That's a good way to isolate the hacks that go into any game.
Windows-centric? The title of the book is *Windows* Forensics and Incident Response. I guess this is Slashdot so I should expect to be flamed for being on-topic...
My top post isn't about EnCase.
As others note here, standard forensic practice -- especially when you don't know what you're doing -- is to pull the plug. That's what the DOJ says, at least.
In the example that you give, of the OpenSSH vulnerability, it's very likely that the intruder will leave filesystem artifacts. sync() runs every few seconds. Syslog keeps track of all kinds of events (not to mention shell history files!). Sure, if someone's got root they can cover their tracks completely, but we're rarely dealing with Moriarty -- usually it's Moe and his friends, Larry and Curly.
Additionally, the distinction needs to be made between forensics and incident response. That distinction is definitely murky, but it exists. When you suspect an "incident", which is usually a code word for "exploited vulnerability", yeah, gathering live data totally makes sense, and I'd do it. Once I'd gotten my data, I'd then pull the plug. For forensic software, mildly corrupt filesystems resulting from powerloss is not a big deal. But if you think about the potential for losing artifacts that is entailed from performing a clean shutdown, you can see why abrupt power cut-off is the way to go.
For example, tmpfs. Sure, tmpfs is a "RAM"-disk, but that memory is backed by swap. If I'm the kernel, I bet I'm going to see that a lot of the files in this 'tmpfs' are relatively unused -- swap them away! Now, consider what happens when you perform a shutdown. Processes are killed, users are logged out, daemons are signalled, runlevels are changed, etc., etc., etc. That sounds to me like a pretty invasive procedure, one that could very well involve lots of swapping. So then you lose tmpfs. As noted above, if I really cared about the live data, I'd capture it, as simply as possible, and then I'd pull the plug. So I'd run ps, netstat, maybe lsof, and ls -ls/tmpfs. And then the plug would be pulled.
As far as getting in the doghouse, my experience has been that it's far better to be in everyone else's doghouse but have your General Counsel love you than to have everyone else love you and be in your General Counsel's doghouse. That's the key point, really: When legal gets involved, IT doesn't matter.
The EEE "servlet" will not write anything to the filesystem directly. Acquisitions are made on a low-level sector-by-sector basis.
However, running *any* program on a targetted system necessarily changes it. The operating system has to allocate memory and CPU time for the process, and on any modern system that can invoke a write to the pagefile/swap area. This is just the way life is, and for corporate investigations -- which almost never go criminal -- this is more than good enough.
Whether an investigation is internal, civil, or criminal, it's important to know and follow forensic best practices. If you know an acquisition is going to be used in a criminal investigation, my understanding is that it is generally preferable to pull the plug and image the drive off-line. But that's only if you've got a trusted tech on-site to do the job at the time...
And that kind of an IT response (problem? reboot!) is fine, because you've got work to do after all.
However, at the point that you discover that there's been an incident, you should note what's running (ps), what's open (netstat), who's logged on, and what drives are mounted. Document everything that you do (date/time, action, reason for action), pull the plug, and call your lawyer.
Incident response is difficult as the scale of the "response" can vary so widely. Sometimes it's enough to run a virus scanner and reboot. Other times you may find you've been 0wn3d by international hackers conducting IP theft (I've seen it) and you need to proceed very carefully. And then there are the HR investigations...
My main point is simply that when geeks start to tread into the area of incident response/forensics, it's important for them to know what they're doing. When you're operating in the context of traditional IT, an IT response is okay. When you're operating in the context of an investigation, a traditional IT response is typically the worst thing you can do.
You are also very correct, though, in noting that pro-active security is where the typical sysadmin should have his/her focus. You don't want to be the sysadmin who let in the international hackers stealing all your company's intellectual property.
There are all kinds of ways to image a SATA drive. It's a non-issue. Worse comes to worst, we boot your system up in DOS and acquire it via crossover cable.
EnCase supports Reiser3. I don't know whether Reiser4 is so radically different from Reiser3 that we can't decode the filesystem currently, but I'm sure we could roll it out the door quickly if there was a large need. We've done it for our customers before.
We can't yet do XFS, but we could still recover quite a bit of data from unallocated. As others have noted, all you need to get an image is good old dd.
In many respects, savvy forensics investigators are far ahead of most criminals. Police forces band together to create high tech task forces, and they tend to have plenty of budget (e.g. they have their own clean rooms for manufacturing damaged hard drive parts). With all the ways that Windows and most applications leak information, it requires an extreme amount of discipline to avoid littering your hard drive with evidentiary artifacts.
"Forensics" on a live system is a misnomer. For incident response, collecting live data on open ports, running processes, logged on users, and mounted devices is useful and sometimes necessary. Investigators should be sure to check -- gingerly -- whether any encrypted volumes are mounted.
Generally, however, if there's any chance that the investigation could wind up in court, it's best to pull the plug (literally) and conduct a static analysis of the hard drive. You lose access to running processes and some live registry keys, but otherwise just about everything exists on the hard drive and is accessible through standard forensic tools.
As a forensic programmer/consultant, one of the biggest problems I run into is when J. Random Sysadmin is tasked with conducting an initial investigation and ends up rampaging through the hard drive like a bull in a china shop. If you ever find yourself in this situation, stop and get the facts. There's no better way for a sysadmin to wind up in the doghouse than to ruin a legal investigation.
Jon
(Disclaimer: I work at Guidance Software, makers of EnCase, which is the all-in-one tool that can do all of the things mentioned in the review. But not for free...)
I did XP in extreme C++ for about a year (by extreme C++, I mean boostified, Alexandrescu'd C++). We used CppUnit for our test framework.
I'm not especially satisfied with the currently available C++ unit testing frameworks. CppUnit and Boost's both have trade-offs. I suspect they'll both get better, though.
The Ant-Contrib project's cc task works pretty well, in my limited experience. I was playing around with it just this weekend. I've yet to set up a tinderbox build process, but I don't see why this wouldn't be easy with either Cruise Control or good ol' cron.
In my mind, the two biggest hurdles with doing XP in C++ are build speed and developer prejudice. You can tackle build speed with a combination of ccache, distcc, goodprogrammingprinciples, and cash. Tackling developer prejudice is harder. A lot of C++ programmers like to write low-level, unsafe, old school C++ code. Modern C++ mostly lets you discard unsafe coding practices without sacrificing efficiency. Whether you can convince an old C++ programmer of this is another matter; it depends on the person. I've had decent success taking Java programmers and teaching them modern C++ via pair programming.
Using Boost helps, indirectly. You write safer code, which gives you a faster development cycle. All in all, I think the basic tools are there. It might be a little harder to get fancy lava lamp integration going with C++, but there's no reason why you can't have a good build process. It's just that a lot of C++ projects haven't evolved (I think this is due, in part, to the fact that the C++ community is late to the internet; a lot of C++ programmers just don't know what's, outthere.
In law enforcement circles, this is known as the "trojan defense", i.e. a trojan was responsible for downloading the kiddie porn, not the user. When the defendant makes such a claim, the investigator will typically restore the disk image to a drive or use software to make the image show up as a mounted drive (EnCase, the product I work on, can do this), and then run a few antivirus utilities against the disk.
Additionally, all computer evidence is circumstantial under the law. This puts a reasonably high burden of proof on the investigator, because s/he has to accumulate an overwhelming amount of evidence in order to convince a jury of guilt. A single kiddie porn jpeg won't convict you, nor will kiddie porn sticking around in unallocated. But if all the little artifacts that your OS and software drop all over your hard drive show a pattern of repeated and consistent abuse and intent, then you may want to make a deal. And many folks do make deals.
As for on-the-job matters, the best policy is probably one of prevention. If you've signed an acceptable use policy, live by it. If you've violated it, they have the right to can you. Update and patch your system. Turn off javascript in your browser. Don't install crappy software. If you think your system has been compromised, alert your system administrator immediately -- no one's going to care that you mistyped the White House's URL and ended up at a porn site -- so you avoid a problem later on. If you think you've been wrongfully terminated, or if you know you're being investigated, get a lawyer and a copy of the disk image so a private forensics investigator can help prove your innocence.
When you're *really* doing pair programming, you and your partner are talking constantly and shoving/grabbing the keyboard back and forth between each other. Most programmers are familiar with "flow" or "the zone" or "hack mode" -- alive in the code and dead to the world. When two people are in "pair-flow", the results are astonishing. It takes a lot of work and management to get two people to that level of intellectual comfort, but it's worth it. I'm not doing pair-programming currently, and I miss being able to plug my brain into my former colleagues'. Achieving pair flow makes up for any lost productivity inherent in halving the number of things a team is working on (and there are actual university studies which show that pair programming makes up for initial productivity hits in the long run, due to a lower bug rate).
One problem with pair programming is that it's intellectually and emotionally exhausting, especially for your average introverted programmer. One of the places where XP needs to be refactored is in giving coders a chance to rest and recuperate while still on the job. The Sustainable Pace practice counteracts this to a certain extent, but not fully, in my experience.
The other poster is wrong when s/he claims that pair programming isn't about increasing communication. In fact, that's one of the largest benefits. Fred Brooks showed that communication overhead is indeed the essential problem of team programming. Pair programming lets you skirt around Brooks' Law, in certain situations.
1. Where's the basic information about this book? Author, publisher, ISBN, list price, etc. None of these are mentioned in the review (yes, there's a link to B&N, but, c'mon).
2. Sequencing is an essential aspect of a technical book review. In what order does the author address the topics? Are there many forward references? Does the author march through the topics one at a time or is the subject matter gradually explored, step-wise? A Table of Contents listing (instead of the simplistic 6 parts) would be nice, at a minimum.
Some problems with this book:
1. Having found the TOC on O'Reilly's website (http://www.oreilly.com/catalog/cplus2/toc.html), it's clear that this book features the Bad Old Style of C++ pedagogy: namely, teach C first. The author tackles arrays before std::vector, structs (and unions!) before classes, C-style linked lists before std::list, switch statements before virtual functions, and macros before templates. The new approach to teaching C++ is to give the user familiarity with the powerful utilities of the standard library, so that useful programs can be written right off the bat, and then to explore the dizzying array of language constructs which make the standard library what it is. I encourage those new to C++ to check out Accelerated C++ as an alternative introduction to C++.
2. The reviewer points out that there are many code errors in the book. This is unacceptable, especially for a beginning book. A small number of obvious typos can be forgiven, but anything more than that should consign a tech book -- again, especially an introductory book, where the audience has little experience for dealing with errors -- to the circular file.
While I love many of O'Reilly's offerings, their coverage of C++ has always seemed spotty and outdated. I encourage anyone trying to learn C++ to check out the C++ In Depth series published by Addison-Wesley, starting with Accelerated C++ and Essential C++.
Essentially, you have a learning problem: how does one efficiently propagate detailed knowledge within a group?
Answer: Sex. Continually pair off, sharing genes or, in this case, memes.
I was brought into a company a few months ago for six weeks to finish a demo of a networked, multithreaded peer-to-peer system written in C++. Even though I hadn't much experience with networking or threading, I was up to speed in 2-3 days because we were doing extreme programming. Our pairs swapped every few hours, insuring that I saw a lot of the system in a short amount of time. In your case, I would set up double-rotations. Separate out a handful of logical groups of systems, so that you can have at least two pairs working on a particular group (if you have a ratio of 20 systems to admin and 320 systems, you could have 4 groups). They pair swap at least twice a day. Every so often (e.g. 2 weeks, 1 month, 2 months), have group swaps such that half the members in a group are swapped.
The result is that when someone leaves, there are at least 3 other people in the affected group that have more-or-less the same knowledge as the person who departed. Specific knowledge travels into different groups when you have a group swap, but only so often, which means you don't have a loss in productivity by folks getting up-to-speed all the time. Over time, best practices will be learned by everyone and a positive team culture will develop.
Not to mention that you'll make fewer mistakes since everything happens under the watchful gaze of a partner...
(not that mistakes will disappear entirely:-)
Pairing just works. Why not try it out with half of the staff and see how people like it? Make sure to get caught up on how extreme programming works and figure out what you want to adopt and what isn't feasible for your particular situation.
My girlfriend works on Capitol Hill. Her congressman is a co-sponsor of this bill (he's a good guy, dem, and thinks that it will bring more services to his rural district). It's going to pass the House, but probably not the Senate, at least not any time soon.
So, this is mostly mass hysteria.
One very important thing to remember about Members of Congress: the vast, vast majority of them have already made their minds up the day before a vote. You can call, email, and write all you want the day before a vote, but unless you're someone important, it's not going to make a difference. If you want to make a difference, get involved earlier in the process.
C'mon, it was just a couple of posts down. How hard is it to scan the main posts before posting?? Keep the quality up, timothy. It wouldn't be/. if timothy didn't mess up at least once a week.
Many years ago, during the bad old days of Gil Amelio (who still did a lot of good, necessary things for Apple), I argued with anyone and everyone who made fun of Macs. I am not so pugnacious these days.
As Jobs says, survival is success. I don't care if my Mac is liked by others. I don't care if the MacOS doesn't have the highest market share. I don't care if I could have gotten a better deal on similar hardware. I don't care if the latest greatest seizure-inducing bloodbath games don't run at the highest frame rates on my Mac. I don't care about any of that anymore.
I care about Apple's survival only because I care about the continual improvement of Macintosh hardware and software. I care about having hardware that will run reliably for a long time. I care about having software, both the system and the available applications, that lets me get done what I want to get done, with a minimum of fuss. I care about having the power and flexibility of Unix, without the hassle of tweaking config files if I don't feel like it right at the moment. This is all I care about. As long as Apple survives and keeps doing these things, I will go quietly about my day, blissfully writing code.
For those in the U.S., and an increasingly large portion of the world, we live in a pluralistic society, where others' choices are tolerated and, ideally, ignored. To Jon Katz, I say: Run the OS you like, on the hardware you like. I will, and I'll be happy if you do, too.
My girlfriend is a Legislative Correspondent for her congressman. Here's how it all works.
Most every representative and senator has at least one "Legislative Correspondent". This staffer is responsible for dealing with mail and responding to it.
IF YOU ARE NOT A CONSTITUENT, DON'T EXPECT A RESPONSE. They're not going to waste time/money on you; it's S.O.P. for all congressional offices.
If you are a constituent, your letter/email will be assigned to an issues category and have basic information from it entered into a database (which keeps track of who you are, where you live, what other letters you've sent, basic stuff like that). If a letter exists which addresses your issue, it'll get printed out and sent back to you. If not, either the legislative correspondent will write a letter on it -- which can require a good deal of research -- or, especially if it's an important, popular issue, will have a "Legislative Assistant" write the letter, typically someone who knows more about the particular issue. The new response letter typically will be read by the "Legislative Director", the chief of staff, or even your congressperson.
Once the letter is revised and approved, it will be mailed to you. Some offices reply via email -- if you emailed them; other offices always issue snail mail. Always, always, always include your mailing address in your letter.
In my g/f's office, email has the same status as written letters. I don't know if this is a universal practice. I do know that their email system and database software is universal. It's best to submit your email via your congressperson's web site (http://www.senate.gov/, http://www.house.gov/), because it's easier to get info from it into their database.
Once your letter/email has been responded to, they will file a paper copy of it and that will be that. Whether it has an effect is entirely dependent upon your congressperson's politics, campaign financing interests, and staffers, and upon the political wind, and upon how reasonable and articulate your correspondence is. If you sound crazed at all -- and remember that congressional staffers majored in poly sci, not CS; their passions are not your's -- they'll think you're loony.
An important fact to keep in mind is that some congressional offices have months' worth of backlog. It will take TIME to get a response, especially as there's a lot of mail pouring into the Capitol these days. My g/f's office strives for two weeks turnaround, max, and that's a very good number.
---
Congressional correspondence is important, obviously, but you may be able to be more persuasive by talking with the right legislative assistant. Call up the office, explain to whoever answers the phone that you'd like to talk to the appropriate legislative assistant about your issue, and if the right LA isn't there, leave your phone number. If you take this tact, however, it's very important to know about the issue and to be prepared to talk about it in a reasonable and personable manner. Think soft sell. Be prepared to concede some points. Be prepared to prioritize sub-issues, what's non-negotiable for your vote, why you feel that way, and also what you could live with. Be prepared to demonstrate the ramifications of possible legislation, how it affects you, and how it affects others (especially other constituents). If you're a business leader, or work for a notable employer, or are an influential and/or notable and respected citizen, your voice will carry some impact. If you can be a source of reliable information and input for your congressperson, his/her staffers will be grateful.
Not to say that 18-month olds are stupid -- in fact -- I am continually amazed at how rapidly kids are able to acquire language. Nevertheless, the linguistic faculty of an average 18 month old would be relatively simple to model with a computer. (Yes, I'm a linguistics major.)
At that stage in development, kids have only the most basic grammar, and deal almost entirely with simple nouns and verbs. The non-lexical grammar could be described with probably 2 or 3 simple rules (eg. if the language is English, nouns precede verbs). What's left to input is the sub-categorization frame of each word in the model's lexicon; this is information stored for each word which tells in what context the word can be used in (it's pretty much possible to make such contexts as complex and deep as possible).
For a generative vocabulary of 50 words, as "Hal" has, this is not so much information to learn and store. Using brute force, you could relate every word to each other. So, let's say, you've got 50! relations. That's already a big number. Of course, how they got there was by trimming their graph back a little, to make things manageable, to impose hierarchies, so that some classes of words will never relate to each other and you don't have to store that information (think: a tree). Still, when you add a new word to the vocabulary, if you're trying to get the agent/model to learn the word, then it's going to relate the new word to every other word AT FIRST. Gradually, it'll learn where to put the word and trim the graph. Still, though, it's learning is essentially O(n!). I mean, it's incredibly hard to get away from O(n!) for learning vocabulary. Kids can cope because each and every neuron operates autonomously; neural nets can't, 'cuz they still run on single proc machines (or pathetically small multi-processor machines, when compared to our brains).
So, purely from a combinatorial standpoint, such an endeavor is doomed to failure. It cannot scale to an adult vocabulary.
From a linguistic standpoint, such learning techniques are laughable: kids come hard-wired, and this machine doesn't; it won't be able to keep up. Kids are born with innate knowledge about all of the morphological categories (ie nouns, verbs, adjectives, determiners, etc.) and only need to observe enough of a language to determine the specific ways in which these categories are treated in a particular language. Moreover, there are even constraints concerning the range of possible syntaxes built into our brains, which again limits the processing required drastically; Hal knows no such limits (a bad thing). Furthermore, the complexities of possible grammatical constructions multiply super-linearly as more linguistic features are added to a grammar; adverbs, clefting, subject-auxiliary inversion, parasitic gaps, pronominalization, etc. are all features of adult natural language -- which adults have trouble with, btw -- which have subtleties that cannot even be explained with current linguistic analysis (some to a greater extent than others, of course). How can we teach a computer something which we do not yet understand? The only way people learn language is because we have it hard-wired into our brains.
Finally, as a previous poster admonished, nothing is said of the ontological system underlying Hal. Ontology is an order of magnitude harder than linguistics. If Hal is to obtain adult discursive capabilities, it had better have some idea, however loosely, of what it's saying. Since no one knows anything useful about ontology, methinks this company is just showing off some demoware so they can get some cash for a couple more years, without doing real work.
I've developed a note-taking application for my company. Although it's fairly portable, right now we only target DOS. Why DOS? Because there are a number of industrial-strength handheld computers which run DOS on top of an embedded x86 processor. They're exactly what you want in the middle of a corn field in November.
The current handhelds we're buying are made by Juniper Systems. They're AMD 486s with 16MB RAM which can dual-boot DOS and WinCE. They're $2500 a pop. They're waterproof. They're damn near drop-proof. They've got heaters on the LCD screen so they can be used outside in freezing temperatures.
By using x86 procs and OSes, one can use existing apps with them and use standard development tools to create new apps (and develop and test on a desktop system!). These types of computers are not revised too often. I'm sure my company won't be affected too much by this, but it is something for me to worry about, and for our supplier to work out. The embedded market may be contracting because of the networking slowdown, but there's still demand for old AMD 486s, nonetheless.
Languages are not drastically different; they are eerily similar. The differences between languages are like a fugue: variations on the same theme.
In particular, most linguists believe that all languages are governed by something called Universal Grammar (UG). UG very much restricts the set of possible languages.
As for "what if ROT-13" was a language, I don't think it would hold up; any judge would throw it out. There's really no grammar at all to ROT-13, certainly not one that even comes close to what's required by UG.
I don't usually criticize slashdot; I hardly comment at all.
But why was this posted? I'm a longtime Mac fan, and a CS student, so, naturally, I'm very excited about what the amalgation of NetBSD, OpenStep, and MacOS that is MacOS X will bring to my computing experience.
The article at MacCentral is hardly "news for nerds", however. There's much better sources for technical information concerning MacOS X. Plus, the article doesn't seem especially central to the topic of the post itself.
Now, because the article doesn't really serve as a good source of information, essentially what we have is a discussion about porting issues in MacOS X -- not a bad thing -- but a discussion without a foundation of facts.
Consequently, I see a lot of ill-informed posts here. Few of them are trolls, which is quite heartening, but it would behoove (I love that word:-)/.'s editors to make sure they have a good source of information to base discussions on, to ensure that we have a reasonably intelligent discussion. It seems that people here have more questions about this topic than answers, and no obvious way (ie. linkage) to find the necessary answers.
One of the main problems with doing natural language processing is that linguistics is about as old as computer science. And while CS has had a pretty firm theoretical foundation since Day One (thank you, Mr. Turing), debate rages on to this day as to how language really works. So not only is the domain quite complex (ie. you need damn good programmers who have good knowledge of linguistics), no one even completely understands the domain.
That's not gonna' stop me from goin' into the field, though...
The Algorithms class I'm currently in uses this text. Of course, we've only done a few chapters, but it has been an excellent book so far -- it's wide-ranging and includes many graph algorithms (most of which are missing from my other algorithms books) as well as a good description of NP problems (ie. most people who have posted here should read this). One of the best things about the book is the bibliography at the back -- you know where to turn to for more information.
It doesn't include splay trees, however. They're one of my favorite data structures.
See my above post. The ABC is a computer only in the eyes of the courts (and Iowa State!). It was not generally programmable, even mechanically. All it did was solve systems of linear equations.
Slashdot Mirror
Use git.
http://git.or.cz/
Check them all into a repository, then periodically run git-fsck. Git hashes all files in a repository with SHA-1 when they're first committed, and git-fsck recalculates the hashes.
Jon
A number of the comments here are more like a bar conversation regarding computer forensics than actual informed advice. Additionally, a number of the comments are wrong wrt/ technical facts concerning NTFS.
The first question is this: do the parties need to retain legal counsel? If A and B are shaking hands and good to go, great. If not, they need to retain counsel.
If counsel is retained, then they need to work with their clients to find a reputable computer forensics expert. And that's all there is to it, really.
But to answer your general question of, does computer forensics apply to this?, well, yes, definitely.
cheers,
Jon
(Disclaimer: I'm a programmer at Guidance Software, and work on EnCase.)
The fact that the presence of PGP on the suspect's computer was determined to be "somewhat relevant" by a Minnesota appeals court in this particular case is hardly the death knell for the 4th amendment.
Evidence from computer media is largely treated as circumstantial in the courtroom. As such, the tact in CP trials like this is to present lots of independent facts to the court with the hope that the aggregate weight of these facts is enough to remove reasonable doubt.
I have and use PGP and have no fear that it'll ever be used as evidence against me. Unless, of course, child pornography is recovered from the unallocated clusters on my disk, internet history show I was surfing CP sites through Google searches, link files pointing to, for an example I had from an investigator this very morning, "Gruppe 3 M:adchen Sperma.jpg", etc., etc.
Another subtlety to understand is typically only a small amount of the technical evidence from a case is presented to the court. Why? Because you don't want to spend hours and hours confusing the judge and jury about the meaning of MFT records and the like. I'd be sure in this case that there's a fair amount of evidence against the suspect (there usually is in CP cases, or they don't prosecute...) and the prosecution cherry-picked what to present in court based on how easy it would be to explain.
Jon
Yes. Many games these days are written as if they were a pure simulation. You have your initial state and you change state by applying inputs (user commands & time progression). It should be completely deterministic, so you can have two copies of the game that start with the same state, apply the same inputs, and arrive at the same final state.
This may seem heavyweight, but, hey, processors are fast these days. Many games use scripting languages -- the "I need to write this in C using only global variables" approach of yesteryear is no longer necessary. Additionally, you get some great benefits. Chief among them is replayability and save&restore, but you can also get a relatively simple network protocol (mostly just send inputs, which are small), maintainable code, easy dead reckoning, and the ability to apply other optimizations on top of the model (e.g. lag thrusters). Also, an important insight is that you don't necessarily have to display your simulation state _exactly_. This way you can have reliable code to track the simulation and reap the benefits of such a model, and you can also use a bunch of hacks on top of the simulation to make the user experience look/feel good. That's a good way to isolate the hacks that go into any game.
Jon
Windows-centric? The title of the book is *Windows* Forensics and Incident Response. I guess this is Slashdot so I should expect to be flamed for being on-topic...
/tmpfs. And then the plug would be pulled.
My top post isn't about EnCase.
As others note here, standard forensic practice -- especially when you don't know what you're doing -- is to pull the plug. That's what the DOJ says, at least.
In the example that you give, of the OpenSSH vulnerability, it's very likely that the intruder will leave filesystem artifacts. sync() runs every few seconds. Syslog keeps track of all kinds of events (not to mention shell history files!). Sure, if someone's got root they can cover their tracks completely, but we're rarely dealing with Moriarty -- usually it's Moe and his friends, Larry and Curly.
Additionally, the distinction needs to be made between forensics and incident response. That distinction is definitely murky, but it exists. When you suspect an "incident", which is usually a code word for "exploited vulnerability", yeah, gathering live data totally makes sense, and I'd do it. Once I'd gotten my data, I'd then pull the plug. For forensic software, mildly corrupt filesystems resulting from powerloss is not a big deal. But if you think about the potential for losing artifacts that is entailed from performing a clean shutdown, you can see why abrupt power cut-off is the way to go.
For example, tmpfs. Sure, tmpfs is a "RAM"-disk, but that memory is backed by swap. If I'm the kernel, I bet I'm going to see that a lot of the files in this 'tmpfs' are relatively unused -- swap them away! Now, consider what happens when you perform a shutdown. Processes are killed, users are logged out, daemons are signalled, runlevels are changed, etc., etc., etc. That sounds to me like a pretty invasive procedure, one that could very well involve lots of swapping. So then you lose tmpfs. As noted above, if I really cared about the live data, I'd capture it, as simply as possible, and then I'd pull the plug. So I'd run ps, netstat, maybe lsof, and ls -ls
As far as getting in the doghouse, my experience has been that it's far better to be in everyone else's doghouse but have your General Counsel love you than to have everyone else love you and be in your General Counsel's doghouse. That's the key point, really: When legal gets involved, IT doesn't matter.
cheers,
Jon
Hi Jack -
The EEE "servlet" will not write anything to the filesystem directly. Acquisitions are made on a low-level sector-by-sector basis.
However, running *any* program on a targetted system necessarily changes it. The operating system has to allocate memory and CPU time for the process, and on any modern system that can invoke a write to the pagefile/swap area. This is just the way life is, and for corporate investigations -- which almost never go criminal -- this is more than good enough.
Whether an investigation is internal, civil, or criminal, it's important to know and follow forensic best practices. If you know an acquisition is going to be used in a criminal investigation, my understanding is that it is generally preferable to pull the plug and image the drive off-line. But that's only if you've got a trusted tech on-site to do the job at the time...
Jon
And that kind of an IT response (problem? reboot!) is fine, because you've got work to do after all.
However, at the point that you discover that there's been an incident, you should note what's running (ps), what's open (netstat), who's logged on, and what drives are mounted. Document everything that you do (date/time, action, reason for action), pull the plug, and call your lawyer.
Incident response is difficult as the scale of the "response" can vary so widely. Sometimes it's enough to run a virus scanner and reboot. Other times you may find you've been 0wn3d by international hackers conducting IP theft (I've seen it) and you need to proceed very carefully. And then there are the HR investigations...
My main point is simply that when geeks start to tread into the area of incident response/forensics, it's important for them to know what they're doing. When you're operating in the context of traditional IT, an IT response is okay. When you're operating in the context of an investigation, a traditional IT response is typically the worst thing you can do.
You are also very correct, though, in noting that pro-active security is where the typical sysadmin should have his/her focus. You don't want to be the sysadmin who let in the international hackers stealing all your company's intellectual property.
Jon
There are all kinds of ways to image a SATA drive. It's a non-issue. Worse comes to worst, we boot your system up in DOS and acquire it via crossover cable.
EnCase supports Reiser3. I don't know whether Reiser4 is so radically different from Reiser3 that we can't decode the filesystem currently, but I'm sure we could roll it out the door quickly if there was a large need. We've done it for our customers before.
We can't yet do XFS, but we could still recover quite a bit of data from unallocated. As others have noted, all you need to get an image is good old dd.
In many respects, savvy forensics investigators are far ahead of most criminals. Police forces band together to create high tech task forces, and they tend to have plenty of budget (e.g. they have their own clean rooms for manufacturing damaged hard drive parts). With all the ways that Windows and most applications leak information, it requires an extreme amount of discipline to avoid littering your hard drive with evidentiary artifacts.
It sounds like you do need a book.
cheers,
Jon
"Forensics" on a live system is a misnomer. For incident response, collecting live data on open ports, running processes, logged on users, and mounted devices is useful and sometimes necessary. Investigators should be sure to check -- gingerly -- whether any encrypted volumes are mounted.
Generally, however, if there's any chance that the investigation could wind up in court, it's best to pull the plug (literally) and conduct a static analysis of the hard drive. You lose access to running processes and some live registry keys, but otherwise just about everything exists on the hard drive and is accessible through standard forensic tools.
As a forensic programmer/consultant, one of the biggest problems I run into is when J. Random Sysadmin is tasked with conducting an initial investigation and ends up rampaging through the hard drive like a bull in a china shop. If you ever find yourself in this situation, stop and get the facts. There's no better way for a sysadmin to wind up in the doghouse than to ruin a legal investigation.
Jon
(Disclaimer: I work at Guidance Software, makers of EnCase, which is the all-in-one tool that can do all of the things mentioned in the review. But not for free...)
I did XP in extreme C++ for about a year (by extreme C++, I mean boostified, Alexandrescu'd C++). We used CppUnit for our test framework.
I'm not especially satisfied with the currently available C++ unit testing frameworks. CppUnit and Boost's both have trade-offs. I suspect they'll both get better, though.
The Ant-Contrib project's cc task works pretty well, in my limited experience. I was playing around with it just this weekend. I've yet to set up a tinderbox build process, but I don't see why this wouldn't be easy with either Cruise Control or good ol' cron.
In my mind, the two biggest hurdles with doing XP in C++ are build speed and developer prejudice. You can tackle build speed with a combination of ccache, distcc, good programming principles, and cash. Tackling developer prejudice is harder. A lot of C++ programmers like to write low-level, unsafe, old school C++ code. Modern C++ mostly lets you discard unsafe coding practices without sacrificing efficiency. Whether you can convince an old C++ programmer of this is another matter; it depends on the person. I've had decent success taking Java programmers and teaching them modern C++ via pair programming.
Using Boost helps, indirectly. You write safer code, which gives you a faster development cycle. All in all, I think the basic tools are there. It might be a little harder to get fancy lava lamp integration going with C++, but there's no reason why you can't have a good build process. It's just that a lot of C++ projects haven't evolved (I think this is due, in part, to the fact that the C++ community is late to the internet; a lot of C++ programmers just don't know what's, out there.
cheers,
Jon
In law enforcement circles, this is known as the "trojan defense", i.e. a trojan was responsible for downloading the kiddie porn, not the user. When the defendant makes such a claim, the investigator will typically restore the disk image to a drive or use software to make the image show up as a mounted drive (EnCase, the product I work on, can do this), and then run a few antivirus utilities against the disk.
Additionally, all computer evidence is circumstantial under the law. This puts a reasonably high burden of proof on the investigator, because s/he has to accumulate an overwhelming amount of evidence in order to convince a jury of guilt. A single kiddie porn jpeg won't convict you, nor will kiddie porn sticking around in unallocated. But if all the little artifacts that your OS and software drop all over your hard drive show a pattern of repeated and consistent abuse and intent, then you may want to make a deal. And many folks do make deals.
As for on-the-job matters, the best policy is probably one of prevention. If you've signed an acceptable use policy, live by it. If you've violated it, they have the right to can you. Update and patch your system. Turn off javascript in your browser. Don't install crappy software. If you think your system has been compromised, alert your system administrator immediately -- no one's going to care that you mistyped the White House's URL and ended up at a porn site -- so you avoid a problem later on. If you think you've been wrongfully terminated, or if you know you're being investigated, get a lawyer and a copy of the disk image so a private forensics investigator can help prove your innocence.
Jon
What you describe isn't [good] pair programming.
When you're *really* doing pair programming, you and your partner are talking constantly and shoving/grabbing the keyboard back and forth between each other. Most programmers are familiar with "flow" or "the zone" or "hack mode" -- alive in the code and dead to the world. When two people are in "pair-flow", the results are astonishing. It takes a lot of work and management to get two people to that level of intellectual comfort, but it's worth it. I'm not doing pair-programming currently, and I miss being able to plug my brain into my former colleagues'. Achieving pair flow makes up for any lost productivity inherent in halving the number of things a team is working on (and there are actual university studies which show that pair programming makes up for initial productivity hits in the long run, due to a lower bug rate).
One problem with pair programming is that it's intellectually and emotionally exhausting, especially for your average introverted programmer. One of the places where XP needs to be refactored is in giving coders a chance to rest and recuperate while still on the job. The Sustainable Pace practice counteracts this to a certain extent, but not fully, in my experience.
The other poster is wrong when s/he claims that pair programming isn't about increasing communication. In fact, that's one of the largest benefits. Fred Brooks showed that communication overhead is indeed the essential problem of team programming. Pair programming lets you skirt around Brooks' Law, in certain situations.
Jon
Some problems with this review:
1. Where's the basic information about this book? Author, publisher, ISBN, list price, etc. None of these are mentioned in the review (yes, there's a link to B&N, but, c'mon).
2. Sequencing is an essential aspect of a technical book review. In what order does the author address the topics? Are there many forward references? Does the author march through the topics one at a time or is the subject matter gradually explored, step-wise? A Table of Contents listing (instead of the simplistic 6 parts) would be nice, at a minimum.
Some problems with this book:
1. Having found the TOC on O'Reilly's website (http://www.oreilly.com/catalog/cplus2/toc.html), it's clear that this book features the Bad Old Style of C++ pedagogy: namely, teach C first. The author tackles arrays before std::vector, structs (and unions!) before classes, C-style linked lists before std::list, switch statements before virtual functions, and macros before templates. The new approach to teaching C++ is to give the user familiarity with the powerful utilities of the standard library, so that useful programs can be written right off the bat, and then to explore the dizzying array of language constructs which make the standard library what it is. I encourage those new to C++ to check out Accelerated C++ as an alternative introduction to C++.
2. The reviewer points out that there are many code errors in the book. This is unacceptable, especially for a beginning book. A small number of obvious typos can be forgiven, but anything more than that should consign a tech book -- again, especially an introductory book, where the audience has little experience for dealing with errors -- to the circular file.
While I love many of O'Reilly's offerings, their coverage of C++ has always seemed spotty and outdated. I encourage anyone trying to learn C++ to check out the C++ In Depth series published by Addison-Wesley, starting with Accelerated C++ and Essential C++.
Jon
Essentially, you have a learning problem: how does one efficiently propagate detailed knowledge within a group?
:-)
Answer: Sex. Continually pair off, sharing genes or, in this case, memes.
I was brought into a company a few months ago for six weeks to finish a demo of a networked, multithreaded peer-to-peer system written in C++. Even though I hadn't much experience with networking or threading, I was up to speed in 2-3 days because we were doing extreme programming. Our pairs swapped every few hours, insuring that I saw a lot of the system in a short amount of time.
In your case, I would set up double-rotations. Separate out a handful of logical groups of systems, so that you can have at least two pairs working on a particular group (if you have a ratio of 20 systems to admin and 320 systems, you could have 4 groups). They pair swap at least twice a day.
Every so often (e.g. 2 weeks, 1 month, 2 months), have group swaps such that half the members in a group are swapped.
The result is that when someone leaves, there are at least 3 other people in the affected group that have more-or-less the same knowledge as the person who departed. Specific knowledge travels into different groups when you have a group swap, but only so often, which means you don't have a loss in productivity by folks getting up-to-speed all the time. Over time, best practices will be learned by everyone and a positive team culture will develop.
Not to mention that you'll make fewer mistakes since everything happens under the watchful gaze of a partner...
(not that mistakes will disappear entirely
Pairing just works. Why not try it out with half of the staff and see how people like it? Make sure to get caught up on how extreme programming works and figure out what you want to adopt and what isn't feasible for your particular situation.
Jon
My girlfriend works on Capitol Hill. Her congressman is a co-sponsor of this bill (he's a good guy, dem, and thinks that it will bring more services to his rural district). It's going to pass the House, but probably not the Senate, at least not any time soon.
So, this is mostly mass hysteria.
One very important thing to remember about Members of Congress: the vast, vast majority of them have already made their minds up the day before a vote. You can call, email, and write all you want the day before a vote, but unless you're someone important, it's not going to make a difference. If you want to make a difference, get involved earlier in the process.
Jon
C'mon, it was just a couple of posts down. How hard is it to scan the main posts before posting?? Keep the quality up, timothy. It wouldn't be
That said, it's an interesting article...
Jon
Many years ago, during the bad old days of Gil Amelio (who still did a lot of good, necessary things for Apple), I argued with anyone and everyone who made fun of Macs. I am not so pugnacious these days.
As Jobs says, survival is success. I don't care if my Mac is liked by others. I don't care if the MacOS doesn't have the highest market share. I don't care if I could have gotten a better deal on similar hardware. I don't care if the latest greatest seizure-inducing bloodbath games don't run at the highest frame rates on my Mac. I don't care about any of that anymore.
I care about Apple's survival only because I care about the continual improvement of Macintosh hardware and software. I care about having hardware that will run reliably for a long time. I care about having software, both the system and the available applications, that lets me get done what I want to get done, with a minimum of fuss. I care about having the power and flexibility of Unix, without the hassle of tweaking config files if I don't feel like it right at the moment. This is all I care about. As long as Apple survives and keeps doing these things, I will go quietly about my day, blissfully writing code.
For those in the U.S., and an increasingly large portion of the world, we live in a pluralistic society, where others' choices are tolerated and, ideally, ignored. To Jon Katz, I say: Run the OS you like, on the hardware you like. I will, and I'll be happy if you do, too.
Jon
My girlfriend is a Legislative Correspondent for her congressman. Here's how it all works.
Most every representative and senator has at least one "Legislative Correspondent". This staffer is responsible for dealing with mail and responding to it.
IF YOU ARE NOT A CONSTITUENT, DON'T EXPECT A RESPONSE. They're not going to waste time/money on you; it's S.O.P. for all congressional offices.
If you are a constituent, your letter/email will be assigned to an issues category and have basic information from it entered into a database (which keeps track of who you are, where you live, what other letters you've sent, basic stuff like that). If a letter exists which addresses your issue, it'll get printed out and sent back to you. If not, either the legislative correspondent will write a letter on it -- which can require a good deal of research -- or, especially if it's an important, popular issue, will have a "Legislative Assistant" write the letter, typically someone who knows more about the particular issue. The new response letter typically will be read by the "Legislative Director", the chief of staff, or even your congressperson.
Once the letter is revised and approved, it will be mailed to you. Some offices reply via email -- if you emailed them; other offices always issue snail mail. Always, always, always include your mailing address in your letter.
In my g/f's office, email has the same status as written letters. I don't know if this is a universal practice. I do know that their email system and database software is universal. It's best to submit your email via your congressperson's web site (http://www.senate.gov/, http://www.house.gov/), because it's easier to get info from it into their database.
Once your letter/email has been responded to, they will file a paper copy of it and that will be that. Whether it has an effect is entirely dependent upon your congressperson's politics, campaign financing interests, and staffers, and upon the political wind, and upon how reasonable and articulate your correspondence is. If you sound crazed at all -- and remember that congressional staffers majored in poly sci, not CS; their passions are not your's -- they'll think you're loony.
An important fact to keep in mind is that some congressional offices have months' worth of backlog. It will take TIME to get a response, especially as there's a lot of mail pouring into the Capitol these days. My g/f's office strives for two weeks turnaround, max, and that's a very good number.
---
Congressional correspondence is important, obviously, but you may be able to be more persuasive by talking with the right legislative assistant. Call up the office, explain to whoever answers the phone that you'd like to talk to the appropriate legislative assistant about your issue, and if the right LA isn't there, leave your phone number. If you take this tact, however, it's very important to know about the issue and to be prepared to talk about it in a reasonable and personable manner. Think soft sell. Be prepared to concede some points. Be prepared to prioritize sub-issues, what's non-negotiable for your vote, why you feel that way, and also what you could live with. Be prepared to demonstrate the ramifications of possible legislation, how it affects you, and how it affects others (especially other constituents). If you're a business leader, or work for a notable employer, or are an influential and/or notable and respected citizen, your voice will carry some impact. If you can be a source of reliable information and input for your congressperson, his/her staffers will be grateful.
Got it?
Good.
-- Jon
Not to say that 18-month olds are stupid -- in fact -- I am continually amazed at how rapidly kids are able to acquire language. Nevertheless, the linguistic faculty of an average 18 month old would be relatively simple to model with a computer. (Yes, I'm a linguistics major.)
At that stage in development, kids have only the most basic grammar, and deal almost entirely with simple nouns and verbs. The non-lexical grammar could be described with probably 2 or 3 simple rules (eg. if the language is English, nouns precede verbs). What's left to input is the sub-categorization frame of each word in the model's lexicon; this is information stored for each word which tells in what context the word can be used in (it's pretty much possible to make such contexts as complex and deep as possible).
For a generative vocabulary of 50 words, as "Hal" has, this is not so much information to learn and store. Using brute force, you could relate every word to each other. So, let's say, you've got 50! relations. That's already a big number. Of course, how they got there was by trimming their graph back a little, to make things manageable, to impose hierarchies, so that some classes of words will never relate to each other and you don't have to store that information (think: a tree). Still, when you add a new word to the vocabulary, if you're trying to get the agent/model to learn the word, then it's going to relate the new word to every other word AT FIRST. Gradually, it'll learn where to put the word and trim the graph. Still, though, it's learning is essentially O(n!). I mean, it's incredibly hard to get away from O(n!) for learning vocabulary. Kids can cope because each and every neuron operates autonomously; neural nets can't, 'cuz they still run on single proc machines (or pathetically small multi-processor machines, when compared to our brains).
So, purely from a combinatorial standpoint, such an endeavor is doomed to failure. It cannot scale to an adult vocabulary.
From a linguistic standpoint, such learning techniques are laughable: kids come hard-wired, and this machine doesn't; it won't be able to keep up. Kids are born with innate knowledge about all of the morphological categories (ie nouns, verbs, adjectives, determiners, etc.) and only need to observe enough of a language to determine the specific ways in which these categories are treated in a particular language. Moreover, there are even constraints concerning the range of possible syntaxes built into our brains, which again limits the processing required drastically; Hal knows no such limits (a bad thing). Furthermore, the complexities of possible grammatical constructions multiply super-linearly as more linguistic features are added to a grammar; adverbs, clefting, subject-auxiliary inversion, parasitic gaps, pronominalization, etc. are all features of adult natural language -- which adults have trouble with, btw -- which have subtleties that cannot even be explained with current linguistic analysis (some to a greater extent than others, of course). How can we teach a computer something which we do not yet understand? The only way people learn language is because we have it hard-wired into our brains.
Finally, as a previous poster admonished, nothing is said of the ontological system underlying Hal. Ontology is an order of magnitude harder than linguistics. If Hal is to obtain adult discursive capabilities, it had better have some idea, however loosely, of what it's saying. Since no one knows anything useful about ontology, methinks this company is just showing off some demoware so they can get some cash for a couple more years, without doing real work.
My $.02.
Jon
I've developed a note-taking application for my company. Although it's fairly portable, right now we only target DOS. Why DOS? Because there are a number of industrial-strength handheld computers which run DOS on top of an embedded x86 processor. They're exactly what you want in the middle of a corn field in November.
The current handhelds we're buying are made by Juniper Systems. They're AMD 486s with 16MB RAM which can dual-boot DOS and WinCE. They're $2500 a pop. They're waterproof. They're damn near drop-proof. They've got heaters on the LCD screen so they can be used outside in freezing temperatures.
By using x86 procs and OSes, one can use existing apps with them and use standard development tools to create new apps (and develop and test on a desktop system!). These types of computers are not revised too often. I'm sure my company won't be affected too much by this, but it is something for me to worry about, and for our supplier to work out. The embedded market may be contracting because of the networking slowdown, but there's still demand for old AMD 486s, nonetheless.
Jon
Languages are not drastically different; they are eerily similar. The differences between languages are like a fugue: variations on the same theme.
In particular, most linguists believe that all languages are governed by something called Universal Grammar (UG). UG very much restricts the set of possible languages.
As for "what if ROT-13" was a language, I don't think it would hold up; any judge would throw it out. There's really no grammar at all to ROT-13, certainly not one that even comes close to what's required by UG.
Jon
I don't usually criticize slashdot; I hardly comment at all.
:-) /.'s editors to make sure they have a good source of information to base discussions on, to ensure that we have a reasonably intelligent discussion. It seems that people here have more questions about this topic than answers, and no obvious way (ie. linkage) to find the necessary answers.
But why was this posted? I'm a longtime Mac fan, and a CS student, so, naturally, I'm very excited about what the amalgation of NetBSD, OpenStep, and MacOS that is MacOS X will bring to my computing experience.
The article at MacCentral is hardly "news for nerds", however. There's much better sources for technical information concerning MacOS X. Plus, the article doesn't seem especially central to the topic of the post itself.
Now, because the article doesn't really serve as a good source of information, essentially what we have is a discussion about porting issues in MacOS X -- not a bad thing -- but a discussion without a foundation of facts.
Consequently, I see a lot of ill-informed posts here. Few of them are trolls, which is quite heartening, but it would behoove (I love that word
My two cents.
Jon
P.S. Check out http://developer.apple.com/macosx/ and http://developer.apple.com/techpubs/ index.html for tech info from Apple.
One of the main problems with doing natural language processing is that linguistics is about as old as computer science. And while CS has had a pretty firm theoretical foundation since Day One (thank you, Mr. Turing), debate rages on to this day as to how language really works. So not only is the domain quite complex (ie. you need damn good programmers who have good knowledge of linguistics), no one even completely understands the domain.
That's not gonna' stop me from goin' into the field, though...
Jon
The Algorithms class I'm currently in uses this text. Of course, we've only done a few chapters, but it has been an excellent book so far -- it's wide-ranging and includes many graph algorithms (most of which are missing from my other algorithms books) as well as a good description of NP problems (ie. most people who have posted here should read this). One of the best things about the book is the bibliography at the back -- you know where to turn to for more information.
It doesn't include splay trees, however. They're one of my favorite data structures.
Jon
See my above post. The ABC is a computer only in the eyes of the courts (and Iowa State!). It was not generally programmable, even mechanically. All it did was solve systems of linear equations.
Jon