There are more buttons on most, and there are some quicker ways to do things, but the old manual cameras are a significant amount faster and easier to use than todays digital equivalents.
I dunno about that. It seems to be that to a large extent, the controls DSLRs have less accessible than film SLRs are specific to the digital nature.
For instance, if you go back three decades, what did a SLR have? You have focus on the lens, fstop on the lens, shutter speed on the top of the camera, ISO setting on the top of the camera, film advance, depth of field preview button on the front, a self timer control somewhere, and of course the shutter release.
Look at a DSLR. Focus is still on the lens. F-stop control moved to the camera body; on the lowest end cameras (like the Digital Rebel) it's harder to access because you need a chord (hold down a button while turning a wheel), but on the better cameras shutter and f-stop are accessible by different wheels without chords. (And in fact, the shutter speed control is probably easier to use because you don't need to move your hand between the top of the camera and where the button is; you can just move your index finger.) Film advance and rewind controls are of course gone entirely. Depth of field preview is still in the old location, as is the shutter release.
About the only control that you had before that you could even argue is harder to access in some sense is the self timer and the ISO setting, because those are the only controls that have really changed. The self timer setting is typically modal now; you press a button to change between one-shot, continuous, and self-timer, and it's really easy to forget what mode you're in. The ISO setting you have to get to from a menu now, but that's not something that you're usually going to be changing between shots anyway. (And on the Rebel XT at least, it's not even hard to get to the ISO setting at all; it's one button press to go right to the list of modes. No need to navigate menus.)
(There's also a matter of the additional control of like full auto vs. portrait vs. program vs. Tv vs. Ta vs. manual etc., as well as having to set a switch on the lens to be able to manually focus. But if you set the former to full manual and the latter to manual focus, you've got the controls of an old camera. About the only drawback is the lack of a viewscreen that gives focus feedback hints, but you can get ones for the high-end DSLR that will give you that.)
If you base your comparison to 80s and 90s film cameras instead of the pre-AF days, the situation is even better in favor of my argument. Many of the differences (film advance, where and how the fstop is controlled, self-timer) go away, and some of the other settings (ISO) move into menus that are much harder to navigate than on a DSLR because they are using very short abbreviations and icons instead of spelling things out.
So I don't really buy the argument you're making. You should be able to operate about as quickly on a DSLR as you can on a film SLR, because everything you do on a film SLR you do in about the same way on digital.
So, really, it doesn't qualify as a bug-as-feature since there is no bug, just a user error:-)
Just because it's user error doesn't mean it's not a bug.
In some cases, an interface that makes it easy to bad things by mistake is a bug. I don't know if this case qualifies, but the lack of any way to undo the action means that it's at least close to the line..
Disclaimer: I have never used this tool and actually know relatively little about it. However, my current research uses other software the same company makes (CodeSurfer) and is very much tied to this company, and I have an internship with them this summer. The company was started by my adviser and his adviser, employs a couple former advisees of my adviser, etc.
If the program you're writing is, say,/., it's important but not absolutely critical. If you're my bank, or you're paypal, or you're a health insurance provider, it's essential.
(Or more commonly, I'll just use the MIT license. It's shorter and more permissive.)
But then some third party could take your code, reuse it, and release their modifications with the GPL3, which means you can't use their code unless you switch to GPL3. Oh look, it's the same "problem" as before.
(Not saying that it IS a problem, but be consistent...;-))
Last time I checked I could compile a program under Mono and run it on windows and linux...
Only if you restrict yourself to console apps or a 5-year-old API that's seen a new minor version and a new major versions go into production, and a second new major version on the horizon...
(Or if you use a 3rd party toolkit, which removes one of the big benefits of developing on.Net...)
The governments of the world have demonstrated themselves completely incapable of responsibly allocating the resources of the citizenry for the common good. Why do we still let them?
"Democracy is the worst form of government except all those other forms that have been tried from time to time."
If I pay $6 to the government, it goes to enforcing the WO(s)D, to killing Iraqis...
I think you need to study the difference between states and the federal government a little closer. States aren't funding the war, and your sales tax goes to the state.
Let the old guys do the incremental improvements, young programmers should spend one summer doing things no one has ever tried, or at least things they never heard about.
In one summer, for the equivalent of a grad student's stipend?
It's probably a device driver issue. A bad kernel module will cause almost exactly the same error on Linux, only they call it a kernel panic instead of BSOD and write "sleeping function called from invalid context" instead of "IRQ_NOT_LESS_OR_EQUAL."
As long as the OS provides atomic I/O operations on individual files, the logic for implementing two-phase commit is the same in userland or in kernel space.
Really? How?
You CAN'T do it without kernel support. You can do it for cooperating programs through auxilary files and such, but not in general. If you have a program create two files, even if you can create each file atomically, you have to make two system calls which means you could be preempted between them and have another program see only one file.
I'm not *totally* convinced of the real world benefits of this, but it's something that *can't* be done in userspace.
And the preprocessor directives are part of that language. Or perhaps you missed sections 5.1.1 and 6.10 of the description of that language? (Assuming the numbering stayed the same from draft to final.)
Windows NT was initially designed to use single kernel for different subsytems (OS/2 subsystem, POSIX subsystems, etc.)
Not just initially designed, it DOES use a single kernel for different subsystems. You can't get the OS/2 one any more, but the POSIX subsystem morphed into (part of) the Services for Unix which has become the Subsystem for Unix-based applications.
On 32-bit Windows, 16-bit Windows applications are handled by the "Windows on Windows" subsystem. On 64-bit Windows, 32-bit Windows applications are also handled by a "Windows on Windows" subsystem, though a different one than WOW16.
Slashdot Mirror
There are more buttons on most, and there are some quicker ways to do things, but the old manual cameras are a significant amount faster and easier to use than todays digital equivalents.
I dunno about that. It seems to be that to a large extent, the controls DSLRs have less accessible than film SLRs are specific to the digital nature.
For instance, if you go back three decades, what did a SLR have? You have focus on the lens, fstop on the lens, shutter speed on the top of the camera, ISO setting on the top of the camera, film advance, depth of field preview button on the front, a self timer control somewhere, and of course the shutter release.
Look at a DSLR. Focus is still on the lens. F-stop control moved to the camera body; on the lowest end cameras (like the Digital Rebel) it's harder to access because you need a chord (hold down a button while turning a wheel), but on the better cameras shutter and f-stop are accessible by different wheels without chords. (And in fact, the shutter speed control is probably easier to use because you don't need to move your hand between the top of the camera and where the button is; you can just move your index finger.) Film advance and rewind controls are of course gone entirely. Depth of field preview is still in the old location, as is the shutter release.
About the only control that you had before that you could even argue is harder to access in some sense is the self timer and the ISO setting, because those are the only controls that have really changed. The self timer setting is typically modal now; you press a button to change between one-shot, continuous, and self-timer, and it's really easy to forget what mode you're in. The ISO setting you have to get to from a menu now, but that's not something that you're usually going to be changing between shots anyway. (And on the Rebel XT at least, it's not even hard to get to the ISO setting at all; it's one button press to go right to the list of modes. No need to navigate menus.)
(There's also a matter of the additional control of like full auto vs. portrait vs. program vs. Tv vs. Ta vs. manual etc., as well as having to set a switch on the lens to be able to manually focus. But if you set the former to full manual and the latter to manual focus, you've got the controls of an old camera. About the only drawback is the lack of a viewscreen that gives focus feedback hints, but you can get ones for the high-end DSLR that will give you that.)
If you base your comparison to 80s and 90s film cameras instead of the pre-AF days, the situation is even better in favor of my argument. Many of the differences (film advance, where and how the fstop is controlled, self-timer) go away, and some of the other settings (ISO) move into menus that are much harder to navigate than on a DSLR because they are using very short abbreviations and icons instead of spelling things out.
So I don't really buy the argument you're making. You should be able to operate about as quickly on a DSLR as you can on a film SLR, because everything you do on a film SLR you do in about the same way on digital.
So, really, it doesn't qualify as a bug-as-feature since there is no bug, just a user error :-)
Just because it's user error doesn't mean it's not a bug.
In some cases, an interface that makes it easy to bad things by mistake is a bug. I don't know if this case qualifies, but the lack of any way to undo the action means that it's at least close to the line..
One more in the same genre as coverity: http://www.grammatech.com/products/codesonar/overv iew.html
Disclaimer: I have never used this tool and actually know relatively little about it. However, my current research uses other software the same company makes (CodeSurfer) and is very much tied to this company, and I have an internship with them this summer. The company was started by my adviser and his adviser, employs a couple former advisees of my adviser, etc.
That depends. How long will it take forum posters to realize that "/" is often used as abbreviation for "and" and "or"?
If the program you're writing is, say, /., it's important but not absolutely critical. If you're my bank, or you're paypal, or you're a health insurance provider, it's essential.
(Or more commonly, I'll just use the MIT license. It's shorter and more permissive.)
;-))
But then some third party could take your code, reuse it, and release their modifications with the GPL3, which means you can't use their code unless you switch to GPL3. Oh look, it's the same "problem" as before.
(Not saying that it IS a problem, but be consistent...
Maybe you could make it with polarization.
(I came here to see how long it took for someone to post the Hitchhiker's reference. I wasn't disappointed.)
Last time I checked I could compile a program under Mono and run it on windows and linux...
.Net...)
Only if you restrict yourself to console apps or a 5-year-old API that's seen a new minor version and a new major versions go into production, and a second new major version on the horizon...
(Or if you use a 3rd party toolkit, which removes one of the big benefits of developing on
why the hell is "aggregator" not in the Firefox 2 US English dictionary?
"Okay" isn't in Firefox's dictionary; you expect "aggregator" to be?
What do you want to bet that these dinosaurs lived in bigger "dens" than my apartment?
The governments of the world have demonstrated themselves completely incapable of responsibly allocating the resources of the citizenry for the common good. Why do we still let them?
"Democracy is the worst form of government except all those other forms that have been tried from time to time."
If I pay $6 to the government, it goes to enforcing the WO(s)D, to killing Iraqis...
I think you need to study the difference between states and the federal government a little closer. States aren't funding the war, and your sales tax goes to the state.
Let the old guys do the incremental improvements, young programmers should spend one summer doing things no one has ever tried, or at least things they never heard about.
In one summer, for the equivalent of a grad student's stipend?
mkdir newdir; touch newdir/file1; touch newdir/file2; mv newdir dir
If dir/ already exists, that will move newdir/ INTO dir/.
Perhaps I should have said that you need to create two files in an existing directory.
(I'm not sure about the use cases of this, if they are actually helpful in any real world programs, but that's not what I'm arguing.)
It's probably a device driver issue. A bad kernel module will cause almost exactly the same error on Linux, only they call it a kernel panic instead of BSOD and write "sleeping function called from invalid context" instead of "IRQ_NOT_LESS_OR_EQUAL."
Agreed! It's copyright infringement too!
Anyway, what I am asking is if anybody knows if the Linux Kernel and/or popular file systems have support for this. How about Mac?
AFAICT, this is a feature unique to NTFS/Vista and maybe VMS. (The latter wouldn't surprise me; NT is a descendant of VMS designwise.)
Give me a program that will create two files in a directory while guaranteeing that no program can see only one of them.
As long as the OS provides atomic I/O operations on individual files, the logic for implementing two-phase commit is the same in userland or in kernel space.
Really? How?
You CAN'T do it without kernel support. You can do it for cooperating programs through auxilary files and such, but not in general. If you have a program create two files, even if you can create each file atomically, you have to make two system calls which means you could be preempted between them and have another program see only one file.
I'm not *totally* convinced of the real world benefits of this, but it's something that *can't* be done in userspace.
Wow, 11 comments and only 2 that are making variants of this joke. I am UNIMPRESSED people, get to work!
The registry is no more vulnerable than any number of Unix config files. An extra newline in /etc/password will cause the same problem.
Even if you accept that, it's still easier to diagnose and recover from the extra newline.
It seems to be: every database more complex than a flat file processed by a pair of simple perl scripts has support for transactions like this.
Yes, DBs do. But traditionally file systems don't. The only other system that provides this that I know of that isn't a full-fledged database is VMS.
C is a language, not a program.
Yes, I realize that.
And the preprocessor directives are part of that language. Or perhaps you missed sections 5.1.1 and 6.10 of the description of that language? (Assuming the numbering stayed the same from draft to final.)
Here's another top... the preprocessor is part of C.
Not that you should be using ifdef to separate platform-specific code anyway... it should be put into another file.
Windows NT was initially designed to use single kernel for different subsytems (OS/2 subsystem, POSIX subsystems, etc.)
Not just initially designed, it DOES use a single kernel for different subsystems. You can't get the OS/2 one any more, but the POSIX subsystem morphed into (part of) the Services for Unix which has become the Subsystem for Unix-based applications.
On 32-bit Windows, 16-bit Windows applications are handled by the "Windows on Windows" subsystem. On 64-bit Windows, 32-bit Windows applications are also handled by a "Windows on Windows" subsystem, though a different one than WOW16.