It's just a question of money. If you let jurors go home at the end of the day, then there's no way to control what they see or do. The solution is to keep jurors confined to hotel rooms for the full duration of the trial, or if that's too expensive in a lawsuit-addicted society like the US, to build juror barracks for this purpose.
Congratulations, you just turned jury duty into something that is inconvenient to one that would be utterly terrible. What do you do for the trials that go on for a week or two? (Or a year!) Do you keep the jurors locked in their admittedly-comfy prisons the whole time? What if they're a single parent?
On the other hand, looking up terms or information about the trial, I think, only makes for a more informed jury. Otherwise, your only piece of information is from the prosecutor and defense lawyer, which are both extremely biased opinions. Granted, jurors have to be careful to judge information on the web carefully, but we're asking them to do the same thing in the courtroom as well.
There are some extremely important differences in both questions of law and questions of fact (particularly the latter) between the two situations.
In the case of questions of law, there are very few people who I think are equipped to read, understand, and determine the applicability of existing statutes and court decisions. I have a small interest in the law, did mock trial for a couple years and have read many opinions, and I wouldn't put a whole lot of trust myself to have done enough investigation into most matters to determine whether a particular opinion is controlling in a case at hand.
In the case of questions of fact, it's even more important. It's not just a matter of "you have to decide how trustworthy it is" because both sides have the right to cross examine the opposing witnesses. Further, there are very good reasons to suppress certain evidence even if it leads to a false acquittal. If you read an article that says "the defendent's blood was found at the scene" but that was never brought up at trial, why was that? Was it because there was a telephone-game-style miscommunication from the source to the newspaper? Was it because that evidence was later found to not be trustworthy? Was it because that evidence was suppressed because it was gathered illegally? In almost all cases, the only fair and safe option is to disregard any externally-gathered information.
What's really nice in this country, among other rights, is the one that allows the accused to cross-examine their accusers. Are you going to make a full report to the defense council of the sources you consulted so that their authors can be called to the stand if the defendant wants to exercise that right?
In a similar vein, it's not like things have really changed. I bet just as many people talked about the case with friends and family, heard things they weren't supposed to, and had just as many pre-trial prejudices before the connected age as they do now. It's just that the new methods of communication leave a trail that public, near permanent, and easily searchable.
I disagree; I think it's also a scale issue. Now instead of talking about the case with their husband or wife and maybe a couple friends, they talk about it with everyone who's following them on Twitter or friends with them on Facebook. Instead of a few people, it's dozens.
And for all the denying this fact that people seem to do around here, making things easily searchable makes a big difference. If I'm on a jury, don't care about my instructions, and am curious what the press said about the case, it's entirely likely that I'll be curious to just type the guy's name into Google while I wouldn't have been curious enough to go to the local library and start pulling back issues of the local newspaper.
I was gonna say the same thing. I saw the light when I was in undergrad and used a old Sun keyboard on one of their Unix boxes, and have sometimes remapped caps ever since. (Sometimes I'm too lazy, mostly on Windows because it's not completely trivial there.)
Their backspace key placement was stupid stupid stupid though and more than made up for the caps lock placement in terms of making the keyboard stupid. I actually had ` mapped to delete-backwards-char or whatever Emacs calls it.
My setup has two monitors, and a REAL keyboard and mouse, not the toy ones on most laptops, and I can't even begin to imagine the carpel tunnel and thumb pain
Not to mention neck pain. For me to really be comfortable for long periods of time, the center line of my monitor really needs to be a foot and a half or so (I don't have a tape measure) above the top of my keyboard. That excludes even laptops for long-term use without a discrete keyboard and/or monitor.
And how do they know when the picture was taken? Think detectives are finished going over a crime scene a few minutes after getting there? Of course not. Even if they're done on-scene relatively quickly (large crimes can take days or longer), they'll box all the evidence up and take it back to the lab. Maybe they'll get to it by the end of the week. Maybe not.
Basically, courtworthy photos are being produced long after there's been time to do some photoshopping.
Fun fact: there's actually a second X selection buffer. It's not used very much at all, but it does mean that there are three separate clipboard-type entities that are available on most X systems.
If you know what's going on, the separate X selection and X clipboard can be occasionally useful (it essentially gives you two clipboards if you can manage to use them with accidentally overwriting stuff), but is mostly just annoying. Way better (both more useful and more predictable) would be to have just one clipboard entity, but have a global kill ring. I'm not sure exactly the best method here that makes both modern-style copy/paste and Unix-style select/middle-click interactions kind, but I feel almost certain you could come up with one that is better than the small mess that is present now.
Publish the original picture encrypted with the photographer's PUBLIC key in a public place or file it with 5 different legal firms. Then using an independent set of hardware/software have the photographer retrieve the encrypted copy, decrypt it, print it out with the meta-data in human-readable form and a signed digest in a human-readable form, attach a human-readable affidavit saying "I took this photo at this date and location and the metadata is true and accurate" and have him store that with his files. Have witnesses if it's that important.
You're missing the point. Filing with 5 different legal firms, encrypting it, etc.; all that doesn't help very much. If the point is to establish that a picture is unaltered and the way to get around that is "alter it before sending it to everyone" you haven't done much -- about the only thing you've protected against is people deciding later that they want to alter it, or knowing that they want to alter it but don't yet know how. Those are worthwhile things to protect against, but that still seems like it is locking half of a set of double doors. You still want to lock the other one. (In real life it might be more, say, 95% of the double doors.)
Reducing the trust in a system -- in this case, eliminating the trust of the police photographer -- is probably worthwhile.
[Note: this post is written pretty disconnected from the charges against Assange. I don't mean to suggest his guilt or innocence on the matter; I find it way more interesting to talk about questions of law rather than questions of fact.]
Of course she can change her mind, but saying that the guy who didn't stop when his GF asked him to stop in the middle of sex is exactly the same type of asshole who stalks your GF in a dark alley, hits her over the head, drags her to a corner, strips her and sticks his willy inside her body while she is crying and begging - if we are using the exact same word to describe both guys and we think they both deserve the same punishment, then I'm sorry - but something here is very wrong here!
No, the two acts are not on the same level. Fortunately, the two acts would very likely not result in the same sentence even ignoring the fact that your first example would get charged with a whole host of other charges.
But they're both rapists.
We could also classify the guy who didn't stop as being rude and insensitive and she shouldn't have sex with him again. There are a lot of rude people out there and they don't go to jail for it.
Whoa, after that first paragraph ranting about how the word "rapist" was used to describe two rather different acts, you go and describe failure to stop sex when consent is withdrawn (especially because of a perceived condom break) as merely "rude" and "insensitive"?!
Shouting "fuck you, now get out" after sex is rude and insensitive (and not illegal). Refusing to stop sex when your partner says "stop" is in an entirely different ballpark; I'd suggest that the difference between those two acts is at least as big as the difference between the two acts you talk about in the first paragraph.
That's so typically american - whenever I buy something, I'm expected to look and see if I paid tax. Then I'm supposed to put aside a percentage of that, then declare it and pay it in my tax return. Seems insane to me.
In some sense it is. I like NY's approach; you can either calculate the actual amount of tax and pay that, or you can just go to a chart and say "oh, my AGI is $30,000? Pay $50." (I made up those numbers.) Greatly simplifies bookkeeping.
That said, while I wouldn't necessarily be completely opposed to places like Amazon having to charge sales tax up front (I at least make at attempt to not tax dodge, so I pay them anyway), it would make their system a lot more complicated. Sales tax varies sometimes by city, often by county, and definitely by state; I wouldn't be surprised if there were thousands of tax jurisdictions in the country.
It's one of the things I hate about visiting the US - what you see is NOT what you pay.
What bothers me most about this is that it winds up being "harder" to wind up with prices that are nice round numbers because if you want the after-tax price to be, say, $10 even, you wind up with a weird price like $9.52 or something like that. I think if prices were required to be shown post-tax you'd have a lot more even-dollar prices.
That's interesting, and I never really thought about it that way, and didn't really know about the misconception. (I do think it'd be interesting to see concrete tests on how much the assumptions hold, but they probably aren't too out there.) So thanks for clearing that up.
(Though part of my wish still applies, though I didn't really say the whole thing. Because of what you say, I guess backing off on the resolution wouldn't help. However, putting R&D into improving noise performance instead of resolution still would. In the past, I've usually said it differently, something more along the lines of "I wish Canon would stop boosting megapixels and spend a couple generations working on noise instead." That part doesn't suffer from your objection much. However, I didn't realize that those two statements are actually a lot more different than what I thought.)
I agree with you about ISO being the new MP war, and seeing new bodies with less MP. I know we (the Canon community) were hoping prior to the 7D release and even specs were known, that they'd drop the MP back down to like 10 or 12mp. There was a huge debate about 18mp being too much for a crop body camera, but I think the 7D has turned out quite well.
Yeah... I'm less committed to that viewpoint than I was before upgrading. The extra MP can be very nice in a few circumstances (e.g. you're taking a picture you intend to crop substantially because you don't have a long enough lens), and does tend to give rather more detail.
Though the near-30-megabyte photos you get from the T2i on RAW can be a bit annoying too... I had to get new flash cards with the CF to SD switch, doubled the size of my main card, and still have like 2/3 the number of available shots that I used to. And of course you need fast cards too, which increases the price more. Ah well. Certainly you can't claim photography tends to be a cheap hobby.;-)
The other thing I'll say is that my impression is that the high end of at least the T2i is probably more noisy "natively" than it was on the XT (which maxed out at 1600), so effectively I'd say that the T2i is between one and two stops better than the XT on that count. However, it's a little hard to say; they've put more effort into noise reduction too, so I don't think it's quite a fair comparison.
That said, for amateur shots especially, many shots taken with ISO 6400 and with Lightroom 3's noise reduction (which pretty much rocks) still come out quite well. I'd say you can't quite rely on it, and you do lose some detail, but you could almost certainly shoot at 1600 with the T2i and have consistently good photos.
(I did see an article talking about camera manufacturers turning ISO into "the new megapixels" and cranking it up just because it sounds good, but they are slowly getting better. Personally, I'd love to see the T3i or whatever shed some megapixels and decrease noise.)
...Rebels top out at 1600 (although I may be wrong as I haven't checked the newer Rebels like the T1i/T2i)
Just for the sake of information and not because this is an important correction, the T1i goes to 3200 "natively" and offers 6,400 and 12,800 in boost mode*; the T2i goes to 6,400 natively (but still "only" to 12,800 in boost).
* For anyone who doesn't know, the "boost" means that the work is being done in software. My impression of "boost" ISO modes is that they are roughly equivalent to underexposing the image a corresponding amount then correcting that in postprocessing, except done in-camera. So on a T2i, setting the ISO to 12800 will do the same about thing as setting it to 6400, setting the exposure compensation down one stop, opening the photo in Photoshop/Lightroom/Aperture/whatever, and setting the exposure correction to +1. This could be totally off though.
Its not the camera that takes great photos, its the photographer. Ive seen great pics taken with a crappy disposable film camera. Ive seen shitty photos taken with a DSLR.
While this is absolutely true, having a good camera definitely makes it much easier to take good photos. The easiest place to see this IMO is in low-light situations. Even the Canon G12 and Nikon P7000, both high-end point & shoots, hit their highest ISO setting at half the speed of the highest (non-boosted) setting on the respective entry-level DSLRs. The flagship DSLRs increase that even more. Put a reasonably fast lens on, and you'll get pictures that are half as blurry. And the larger sensor means that the noise level is likely comparable at the high end, so it's not like the DSLRs present a tradeoff in that dept.
The way I describe camera choice is this. It is demonstratively possible to take great, interesting photos with even "crappy" cameras. But, if you have a specific image that you want to capture, it can easily be the case that if I give you a crappy camera you won't be able to take that shot and have it come out the way you envision.
2. make sure the hyperthreading is actually helping. Under many workloads it actually hurts performance.
I might be able to arrange that (though again it's not a personal box), but the stuttering shows up even when the overall CPU load is light. I can just have stuff like Thunderbird, Firefox, and a music player running and if I link one of our projects (one core, heavy on the I/O) sometimes the audio will stutter and the overall desktop will become extremely laggy (e.g. seconds to change virtual desktops).
Theoretically the kernel could be doing something stupid like scheduling the linker on core 1, thread 1 and Clementine on core 1, thread 2, but I'd expect even an older version to be smart enough to do that. Even so, I wouldn't expect it to be that bad even if the scheduling is fine.
It almost reminds me of a problem I had the first time I installed Gentoo. I didn't compile the right driver for my motherboard, which resulted in it not being able to do DMA to the hard drive. So theoretically it could be something stupid like that. (Actually, now that I think about it, it might be worthwhile to investigate. Anyone know how to tell whether it's doing DMA? Preferably as non-root because then I don't have to get the IT folks involved.)
It may be an old kernel problem or a configuration problem, but it certainly isn't an old machine problem. I'm posting from a dual quad core two-way hyperthreaded Xeon (yes, that's 16 HW contexts) and I've faced stuttering on a number of occasions. Sometimes it's app specific (Firefox, I'm looking at you) and sometimes it's been system-wide. Usually the latter seems to happy in periods of heavy I/O. OS is RHEL 5.
i know, i know; how the hell is someone supposed to guess that your type git log to see the log, it is a bit complex you see. what do you do when it doesnt merge cleanly? well you fix it of course, JUST LIKE YOUD HAVE TO DO WITH EVERY OTHER VERSION CONTROL SYSTEM.
Yes, you have to with every other version control system.
But THAT WAS THE POINT of the original poster. It's sort of an Amdahl's law-type argument: if most of your effort is going into looking through the logs to figure out what patches you need to apply, making sure they apply cleanly when they can, and adapting the patches when they don't, switching to a VCS that makes the rest of the process painless still leaves most of the difficulty with merging.
In my experience (which, admittedly, is meek compared with many, but I have worked with both Git and Subversion a lot, including on moderately-sized teams), the differences mostly boil down to the following:
Git has a mindset of "branching is good" behind it, while Subversion has somewhat of a mindset of "branching is bad"
Git's command-line syntax for creating and manipulating branches is dead simple in comparison to Subversion's obnoxious crap (really? you need to use full repository URLs in day-to-day operation? who's the genius who came up with that?)
The two of these together leads people to use branches differently: Git people create branches for smaller things and merge more often; longer, more painful to merge branches are more common in Subversion. This feeds back to (1).
Since Subversion implemented change tracking, basically all the operations that you do in one system have a reasonably direct correspondence in the other. You said git cherry-pick TREEISH was the magic that let you apply a change from another branch. But svn merge -cREV PATH does more-or-less the same thing. Git's SHA-1 becomes Subversion's revision number, and then you "just" need to specify the PATH, which isn't hard to come up with. (Take your path relative to the current branch's root, then append that to the path to the branch. Could easily be done by svn proper given just the name of the branch for repositories that follow the typical trunk/tags/branches layout if the devs weren't too set in their ways.) And of course there's an svn log too, but you knew that.
The two systems are close enough one is not substantially easier to use than the other when compared to the difficulties you face merging with any system.
Oh wait, no! You just didn't bother to think about what the poster you replied to said.
What magical invocation of git will tell you exactly which COMMIT_SHA_OF_FIX you need to port? (Remember, it may not just be one, and it may not be the last k commits either.) And what happens if that patch doesn't apply cleanly because there is some other change between the branches? What magical git invocation will figure out the semantic changes that need to be made so that that patch will actually work?
Compared to CVS and those that came before, you could say Subversion has some manner of distributed support out of the box -- you can see what files you've changed, and even get diffs, without contacting the main server. With CVS you can do next to nothing without a server connection, while with Subversion what (at least for me) are the most common operations are fully local.
But yeah, there are a bunch of mistakes in that post as I pointed out above.
If SVN could be made to fit that smoothly, I didn't see it. Admittedly, it could have been my ignorance.
Aside from putting the repo on your laptop and using it as a server which you connect to from your desktops, and being screwed if you leave your laptop behind, it wasn't just your ignorance.
The closest to what you want that you get is a tool called svk, which is a (heavy) wrapper around Svn that sort of turns it into a DVCS. By the time you're messing with that you might as well just be using Git if you have the choice.
Slashdot Mirror
It's just a question of money. If you let jurors go home at the end of the day, then there's no way to control what they see or do. The solution is to keep jurors confined to hotel rooms for the full duration of the trial, or if that's too expensive in a lawsuit-addicted society like the US, to build juror barracks for this purpose.
Congratulations, you just turned jury duty into something that is inconvenient to one that would be utterly terrible. What do you do for the trials that go on for a week or two? (Or a year!) Do you keep the jurors locked in their admittedly-comfy prisons the whole time? What if they're a single parent?
On the other hand, looking up terms or information about the trial, I think, only makes for a more informed jury. Otherwise, your only piece of information is from the prosecutor and defense lawyer, which are both extremely biased opinions. Granted, jurors have to be careful to judge information on the web carefully, but we're asking them to do the same thing in the courtroom as well.
There are some extremely important differences in both questions of law and questions of fact (particularly the latter) between the two situations.
In the case of questions of law, there are very few people who I think are equipped to read, understand, and determine the applicability of existing statutes and court decisions. I have a small interest in the law, did mock trial for a couple years and have read many opinions, and I wouldn't put a whole lot of trust myself to have done enough investigation into most matters to determine whether a particular opinion is controlling in a case at hand.
In the case of questions of fact, it's even more important. It's not just a matter of "you have to decide how trustworthy it is" because both sides have the right to cross examine the opposing witnesses. Further, there are very good reasons to suppress certain evidence even if it leads to a false acquittal. If you read an article that says "the defendent's blood was found at the scene" but that was never brought up at trial, why was that? Was it because there was a telephone-game-style miscommunication from the source to the newspaper? Was it because that evidence was later found to not be trustworthy? Was it because that evidence was suppressed because it was gathered illegally? In almost all cases, the only fair and safe option is to disregard any externally-gathered information.
What's really nice in this country, among other rights, is the one that allows the accused to cross-examine their accusers. Are you going to make a full report to the defense council of the sources you consulted so that their authors can be called to the stand if the defendant wants to exercise that right?
In a similar vein, it's not like things have really changed. I bet just as many people talked about the case with friends and family, heard things they weren't supposed to, and had just as many pre-trial prejudices before the connected age as they do now. It's just that the new methods of communication leave a trail that public, near permanent, and easily searchable.
I disagree; I think it's also a scale issue. Now instead of talking about the case with their husband or wife and maybe a couple friends, they talk about it with everyone who's following them on Twitter or friends with them on Facebook. Instead of a few people, it's dozens.
And for all the denying this fact that people seem to do around here, making things easily searchable makes a big difference. If I'm on a jury, don't care about my instructions, and am curious what the press said about the case, it's entirely likely that I'll be curious to just type the guy's name into Google while I wouldn't have been curious enough to go to the local library and start pulling back issues of the local newspaper.
I was gonna say the same thing. I saw the light when I was in undergrad and used a old Sun keyboard on one of their Unix boxes, and have sometimes remapped caps ever since. (Sometimes I'm too lazy, mostly on Windows because it's not completely trivial there.)
Their backspace key placement was stupid stupid stupid though and more than made up for the caps lock placement in terms of making the keyboard stupid. I actually had ` mapped to delete-backwards-char or whatever Emacs calls it.
My setup has two monitors, and a REAL keyboard and mouse, not the toy ones on most laptops, and I can't even begin to imagine the carpel tunnel and thumb pain
Not to mention neck pain. For me to really be comfortable for long periods of time, the center line of my monitor really needs to be a foot and a half or so (I don't have a tape measure) above the top of my keyboard. That excludes even laptops for long-term use without a discrete keyboard and/or monitor.
And how do they know when the picture was taken? Think detectives are finished going over a crime scene a few minutes after getting there? Of course not. Even if they're done on-scene relatively quickly (large crimes can take days or longer), they'll box all the evidence up and take it back to the lab. Maybe they'll get to it by the end of the week. Maybe not.
Basically, courtworthy photos are being produced long after there's been time to do some photoshopping.
Fun fact: there's actually a second X selection buffer. It's not used very much at all, but it does mean that there are three separate clipboard-type entities that are available on most X systems.
If you know what's going on, the separate X selection and X clipboard can be occasionally useful (it essentially gives you two clipboards if you can manage to use them with accidentally overwriting stuff), but is mostly just annoying. Way better (both more useful and more predictable) would be to have just one clipboard entity, but have a global kill ring. I'm not sure exactly the best method here that makes both modern-style copy/paste and Unix-style select/middle-click interactions kind, but I feel almost certain you could come up with one that is better than the small mess that is present now.
Publish the original picture encrypted with the photographer's PUBLIC key in a public place or file it with 5 different legal firms. Then using an independent set of hardware/software have the photographer retrieve the encrypted copy, decrypt it, print it out with the meta-data in human-readable form and a signed digest in a human-readable form, attach a human-readable affidavit saying "I took this photo at this date and location and the metadata is true and accurate" and have him store that with his files. Have witnesses if it's that important.
You're missing the point. Filing with 5 different legal firms, encrypting it, etc.; all that doesn't help very much. If the point is to establish that a picture is unaltered and the way to get around that is "alter it before sending it to everyone" you haven't done much -- about the only thing you've protected against is people deciding later that they want to alter it, or knowing that they want to alter it but don't yet know how. Those are worthwhile things to protect against, but that still seems like it is locking half of a set of double doors. You still want to lock the other one. (In real life it might be more, say, 95% of the double doors.)
Reducing the trust in a system -- in this case, eliminating the trust of the police photographer -- is probably worthwhile.
"providence" should, of course, have been "provenance".
How do those firms know they're getting the original picture?
The providence has to start at the camera.
[Note: this post is written pretty disconnected from the charges against Assange. I don't mean to suggest his guilt or innocence on the matter; I find it way more interesting to talk about questions of law rather than questions of fact.]
Of course she can change her mind, but saying that the guy who didn't stop when his GF asked him to stop in the middle of sex is exactly the same type of asshole who stalks your GF in a dark alley, hits her over the head, drags her to a corner, strips her and sticks his willy inside her body while she is crying and begging - if we are using the exact same word to describe both guys and we think they both deserve the same punishment, then I'm sorry - but something here is very wrong here!
No, the two acts are not on the same level. Fortunately, the two acts would very likely not result in the same sentence even ignoring the fact that your first example would get charged with a whole host of other charges.
But they're both rapists.
We could also classify the guy who didn't stop as being rude and insensitive and she shouldn't have sex with him again. There are a lot of rude people out there and they don't go to jail for it.
Whoa, after that first paragraph ranting about how the word "rapist" was used to describe two rather different acts, you go and describe failure to stop sex when consent is withdrawn (especially because of a perceived condom break) as merely "rude" and "insensitive"?!
Shouting "fuck you, now get out" after sex is rude and insensitive (and not illegal). Refusing to stop sex when your partner says "stop" is in an entirely different ballpark; I'd suggest that the difference between those two acts is at least as big as the difference between the two acts you talk about in the first paragraph.
By Swedish law, you are then required to stop, and not doing so is considered rape (but often with mitigating circumstances).
Isn't that law, I dunno, almost everywhere?
That's so typically american - whenever I buy something, I'm expected to look and see if I paid tax. Then I'm supposed to put aside a percentage of that, then declare it and pay it in my tax return. Seems insane to me.
In some sense it is. I like NY's approach; you can either calculate the actual amount of tax and pay that, or you can just go to a chart and say "oh, my AGI is $30,000? Pay $50." (I made up those numbers.) Greatly simplifies bookkeeping.
That said, while I wouldn't necessarily be completely opposed to places like Amazon having to charge sales tax up front (I at least make at attempt to not tax dodge, so I pay them anyway), it would make their system a lot more complicated. Sales tax varies sometimes by city, often by county, and definitely by state; I wouldn't be surprised if there were thousands of tax jurisdictions in the country.
It's one of the things I hate about visiting the US - what you see is NOT what you pay.
What bothers me most about this is that it winds up being "harder" to wind up with prices that are nice round numbers because if you want the after-tax price to be, say, $10 even, you wind up with a weird price like $9.52 or something like that. I think if prices were required to be shown post-tax you'd have a lot more even-dollar prices.
That's interesting, and I never really thought about it that way, and didn't really know about the misconception. (I do think it'd be interesting to see concrete tests on how much the assumptions hold, but they probably aren't too out there.) So thanks for clearing that up.
(Though part of my wish still applies, though I didn't really say the whole thing. Because of what you say, I guess backing off on the resolution wouldn't help. However, putting R&D into improving noise performance instead of resolution still would. In the past, I've usually said it differently, something more along the lines of "I wish Canon would stop boosting megapixels and spend a couple generations working on noise instead." That part doesn't suffer from your objection much. However, I didn't realize that those two statements are actually a lot more different than what I thought.)
I agree with you about ISO being the new MP war, and seeing new bodies with less MP. I know we (the Canon community) were hoping prior to the 7D release and even specs were known, that they'd drop the MP back down to like 10 or 12mp. There was a huge debate about 18mp being too much for a crop body camera, but I think the 7D has turned out quite well.
Yeah... I'm less committed to that viewpoint than I was before upgrading. The extra MP can be very nice in a few circumstances (e.g. you're taking a picture you intend to crop substantially because you don't have a long enough lens), and does tend to give rather more detail.
Though the near-30-megabyte photos you get from the T2i on RAW can be a bit annoying too... I had to get new flash cards with the CF to SD switch, doubled the size of my main card, and still have like 2/3 the number of available shots that I used to. And of course you need fast cards too, which increases the price more. Ah well. Certainly you can't claim photography tends to be a cheap hobby. ;-)
The other thing I'll say is that my impression is that the high end of at least the T2i is probably more noisy "natively" than it was on the XT (which maxed out at 1600), so effectively I'd say that the T2i is between one and two stops better than the XT on that count. However, it's a little hard to say; they've put more effort into noise reduction too, so I don't think it's quite a fair comparison.
That said, for amateur shots especially, many shots taken with ISO 6400 and with Lightroom 3's noise reduction (which pretty much rocks) still come out quite well. I'd say you can't quite rely on it, and you do lose some detail, but you could almost certainly shoot at 1600 with the T2i and have consistently good photos.
(I did see an article talking about camera manufacturers turning ISO into "the new megapixels" and cranking it up just because it sounds good, but they are slowly getting better. Personally, I'd love to see the T3i or whatever shed some megapixels and decrease noise.)
...Rebels top out at 1600 (although I may be wrong as I haven't checked the newer Rebels like the T1i/T2i)
Just for the sake of information and not because this is an important correction, the T1i goes to 3200 "natively" and offers 6,400 and 12,800 in boost mode*; the T2i goes to 6,400 natively (but still "only" to 12,800 in boost).
* For anyone who doesn't know, the "boost" means that the work is being done in software. My impression of "boost" ISO modes is that they are roughly equivalent to underexposing the image a corresponding amount then correcting that in postprocessing, except done in-camera. So on a T2i, setting the ISO to 12800 will do the same about thing as setting it to 6400, setting the exposure compensation down one stop, opening the photo in Photoshop/Lightroom/Aperture/whatever, and setting the exposure correction to +1. This could be totally off though.
Its not the camera that takes great photos, its the photographer. Ive seen great pics taken with a crappy disposable film camera. Ive seen shitty photos taken with a DSLR.
While this is absolutely true, having a good camera definitely makes it much easier to take good photos. The easiest place to see this IMO is in low-light situations. Even the Canon G12 and Nikon P7000, both high-end point & shoots, hit their highest ISO setting at half the speed of the highest (non-boosted) setting on the respective entry-level DSLRs. The flagship DSLRs increase that even more. Put a reasonably fast lens on, and you'll get pictures that are half as blurry. And the larger sensor means that the noise level is likely comparable at the high end, so it's not like the DSLRs present a tradeoff in that dept.
The way I describe camera choice is this. It is demonstratively possible to take great, interesting photos with even "crappy" cameras. But, if you have a specific image that you want to capture, it can easily be the case that if I give you a crappy camera you won't be able to take that shot and have it come out the way you envision.
1. stop using RHEL 5
Not an option; it's not a personal box.
2. make sure the hyperthreading is actually helping. Under many workloads it actually hurts performance.
I might be able to arrange that (though again it's not a personal box), but the stuttering shows up even when the overall CPU load is light. I can just have stuff like Thunderbird, Firefox, and a music player running and if I link one of our projects (one core, heavy on the I/O) sometimes the audio will stutter and the overall desktop will become extremely laggy (e.g. seconds to change virtual desktops).
Theoretically the kernel could be doing something stupid like scheduling the linker on core 1, thread 1 and Clementine on core 1, thread 2, but I'd expect even an older version to be smart enough to do that. Even so, I wouldn't expect it to be that bad even if the scheduling is fine.
It almost reminds me of a problem I had the first time I installed Gentoo. I didn't compile the right driver for my motherboard, which resulted in it not being able to do DMA to the hard drive. So theoretically it could be something stupid like that. (Actually, now that I think about it, it might be worthwhile to investigate. Anyone know how to tell whether it's doing DMA? Preferably as non-root because then I don't have to get the IT folks involved.)
It may be an old kernel problem or a configuration problem, but it certainly isn't an old machine problem. I'm posting from a dual quad core two-way hyperthreaded Xeon (yes, that's 16 HW contexts) and I've faced stuttering on a number of occasions. Sometimes it's app specific (Firefox, I'm looking at you) and sometimes it's been system-wide. Usually the latter seems to happy in periods of heavy I/O. OS is RHEL 5.
i know, i know; how the hell is someone supposed to guess that your type git log to see the log, it is a bit complex you see. what do you do when it doesnt merge cleanly? well you fix it of course, JUST LIKE YOUD HAVE TO DO WITH EVERY OTHER VERSION CONTROL SYSTEM.
Yes, you have to with every other version control system.
But THAT WAS THE POINT of the original poster. It's sort of an Amdahl's law-type argument: if most of your effort is going into looking through the logs to figure out what patches you need to apply, making sure they apply cleanly when they can, and adapting the patches when they don't, switching to a VCS that makes the rest of the process painless still leaves most of the difficulty with merging.
In my experience (which, admittedly, is meek compared with many, but I have worked with both Git and Subversion a lot, including on moderately-sized teams), the differences mostly boil down to the following:
Since Subversion implemented change tracking, basically all the operations that you do in one system have a reasonably direct correspondence in the other. You said git cherry-pick TREEISH was the magic that let you apply a change from another branch. But svn merge -cREV PATH does more-or-less the same thing. Git's SHA-1 becomes Subversion's revision number, and then you "just" need to specify the PATH, which isn't hard to come up with. (Take your path relative to the current branch's root, then append that to the path to the branch. Could easily be done by svn proper given just the name of the branch for repositories that follow the typical trunk/tags/branches layout if the devs weren't too set in their ways.) And of course there's an svn log too, but you knew that.
The two systems are close enough one is not substantially easier to use than the other when compared to the difficulties you face merging with any system.
Oh wait, no! You just didn't bother to think about what the poster you replied to said.
What magical invocation of git will tell you exactly which COMMIT_SHA_OF_FIX you need to port? (Remember, it may not just be one, and it may not be the last k commits either.) And what happens if that patch doesn't apply cleanly because there is some other change between the branches? What magical git invocation will figure out the semantic changes that need to be made so that that patch will actually work?
Compared to CVS and those that came before, you could say Subversion has some manner of distributed support out of the box -- you can see what files you've changed, and even get diffs, without contacting the main server. With CVS you can do next to nothing without a server connection, while with Subversion what (at least for me) are the most common operations are fully local.
But yeah, there are a bunch of mistakes in that post as I pointed out above.
If SVN could be made to fit that smoothly, I didn't see it. Admittedly, it could have been my ignorance.
Aside from putting the repo on your laptop and using it as a server which you connect to from your desktops, and being screwed if you leave your laptop behind, it wasn't just your ignorance.
The closest to what you want that you get is a tool called svk, which is a (heavy) wrapper around Svn that sort of turns it into a DVCS. By the time you're messing with that you might as well just be using Git if you have the choice.