Yes, and that is what Variable Bit Rate / Variable Frame Rate is all about. Without VBR, the encoder knows "I have 192 Kbits (or whatever) to fill for this second of video." At some point where there is a lot of motion, the encoder has to cut the quality to make it all fit in 192 Kbits. Another time, where it is just 10 seconds of a single cel of some character pondering why girls are the way they are (or whatever), the encoder has 1920 Kbits that it doesn't know what to do with -- perhaps make that one frame look really really nice?
This is a good thing in some situations. Rationing the bandwidth allows you to make fairly good predictions about how much space the file will take on disk, or to properly get the data streamed in real time over the network. Predictability is a nice thing.
So VBR says that you're willing to trade a little bit of predictability in data rate for improved allocation of that bandwidth. More bandwidth is used for parts of the video that are hard to compress well. Less is used where less is going on. Overall, the result is usually somewhat better than you would have gotten if you were limited to a single bitrate. The disadvantages are: it is a bit harder to encode quickly when you add the task of figuring out how to allocate the bandwidth; sometimes the accuracy of your requested file size goes down (I asked for 192Kbits, but got more like 213Kbits), or the video bogs down during the action scenes when you're viewing it over the net.
You missed the part where he said "look at the way.Net handles versioning." Versioning is set up so that the Framework never gets upgraded. Instead of upgrading to a Framework version, you ADD an ADDITIONAL Framework version. Existing products will continue to use the version they were built for. This means that the old stuff will work fine.
It also means that Microsoft is much more free to completely rewrite the API since they won't be breaking any existing products. Sure, it breaks source code, but only for developers who want to build their product against the new Framework. So as the grandparent said, they're more willing to mess with devs.
But FireBird is great. No stability problems, no lack of features, and no installation issues.
Sure, you have to know how to unzip it by yourself. And if you want to upgrade, you have to remove the old version yourself, perhaps remove your profile, and you have to manually re-import any bookmarks and reinstall any plugins. But it isn't that hard.
Really, it is the best browser for general purpose browsing I've been able to get my hands on. Like any software, it has a few rough edges and quirks, but none of them are serious enough to not use it. Very few crashes, very few times when it doesn't let me do what I need to do. Better for general browsing than Explorer. I've been using it since 0.5 release, and I'm a convert. (Heck, I even work for Microsoft! Don't tell anyone that I'm using FireBird, or I might get in trouble (grin).)
1. Drivers. 'Nuff sed. 2. Performance. If they made the emulation perfect, everything would run perfectly, but there would be an unacceptably big hit on perf. Instead, they can adapt their emulation according to what the OS can tolerate reliably.
I work with some professors at BYU who produce similar courses-on-CD. These CDs are bundled with a 4-month (one semester) license to Enounce 2xAV for exactly the reasons you mention. Our system has explicit support for allowing the student to adjust the rate of delivery.
Of course (obligatory Slashdot dissing of Microsoft), if Microsoft had enabled the speed control feature of Media Player (pretty cool feature) on all operating systems that support Media Player 9 instead of just XP and beyond, we wouldn't even have to bundle Enounce. I suppose this is one case where Microsoft is helping smaller businesses!
Works fine in Windows, except when each mouse has special features. If you want the special features for just one of them, fine. Just install the driver that came with it. The default driver will kick in for the other one. If you want special features for both, it is a bit tricky to get both drivers to get along with each other in the control panel. The hardware drivers are fine. It is just the control panel that gets confused.
1.0 Library: Yeah, you have to do the COM thing. But it really isn't that bad, and the problem has been solved for you -- just take the file (160 lines of code), add it to your assembly, then call the function. That wasn't so bad, was it?
1.1 Library: Use System.Windows.Forms.FolderBrowserDialog.
Classes can have inner classes as well as typedefs. Those are in the namespace of the class, so the namespace operator:: is used to access them.
And the sort question was answered by somebody else, but here is a bit more on the subject: if a bunch of classes share portions of their interfaces, and the shared subset is enough to perform a useful operation, why not share the implementation of the operation? While you could certainly "tell a vector to sort itself", it makes just as much sense to "apply the sort operation to a vector". Sort is not a primitive operation on a vector, it doesn't require access to the internals of the vector for efficient implementation, so there is no reason to make it a member.
The rest I agree with. A C++ master can do wonderous things, but there are few C++ masters out there. Very simply put, it is really tough to come up with the BEST way to do something in C++ -- there is always more than one way to do it, and doing it perfectly can take an impossible amount of time.
Also, since many useful concepts are possible to implement optimally, yet not built-in to the language, there are way too many libraries. How many different ways are strings expressed? Too many.
I didn't say they succeeded, only that they try...
Yes, everything is a tradeoff. That is why it takes experience to become a good programmer, so you have a feeling of which method is most appropriate.
From my experience, OOP is most important in application and systems development. OOP means that you can provide very specific and enforceable rules about how data can be manipulated and used, and a very limited set of code that can be blamed if any of the rules are broken. The private data of a class is only accessible by members of the class, so if the private data gets into an invalid state, you know that one of the class members has to be at fault (barring spurious pointers or hardware errors). Hopefully, all of the details you need to know about when working with the class are all right there within the class, so you can see them all at once. You don't have to make as many assumptions if all of the necessary details are all together, and class organization is a good way to create independent units of functionality.
If this kind of thing isn't important (it often isn't for simpler programs), then it is just a waste of time. But for complex systems, it is always crucial. Even systems that aren't really "object oriented" from a language perspective tend to be "object oriented" from a usage perspective. Windows does it with handles. UNIX also uses handles for files and sockets. Within the Linux kernel, there are a bunch of pointers that are only supposed to be accessed via macros or accessor functions -- that is nothing short of manually-enforced object oriented programming.
Re:I've been coding most of...
on
Does C# Measure Up?
·
· Score: 4, Informative
Very complicated question. Ughh, there are answers at many levels, and they are all different. But here goes.
Any decent linker nowadays is "smart." This means that it already does what you are asking for -- it knows how to figure out exactly what the dependencies are, and bring in only the symbols (a symbol in this context is a chunk of code or data) that are (directly or indirectly) referenced by your code. Even though you link against all of the C Runtime, or all of the string library, the linker realizes that you are only using strcat. For this example, we'll assume that strcat uses strlen and strcpy. So your call to strcat pulls in strcat, strcpy, and strlen, but nothing else. So what you mention actually is already happening. (Unless you turn off the "smart" linking, as is common for debugging purposes.)
However, there are some additional factors at work. The first is the C Runtime (CRT). ANSI C has some very specific requirements about how the environment is to be set up before main() is called, and how the system is to be cleaned up after main() exits. C also has specs about how to prepare the system for unexpected termination and signal handling. Setup and cleanup reference a bunch of additional symbols, so you end up with much more than just main(), strcat(), strcpy(), and strlen() -- you also have atexit(), exit() and etc. There is usually a process by which you can get rid of this and start directly in main with no setup code, but then you can't use any of the CRT-supplied functions (since the CRT isn't initialized) -- you have to set up your process yourself, handle signals yourself, and are limited to calling OS functions directly (no nice wrappers like fopen, printf or such).
Then there is the issue of linking. Static or dynamic? Static linking means that all of the symbols you reference, directly or indirectly, are compiled into your binary. Dynamic linking means that all of the symbols are converted to references to external binaries, and when your binary loads, the external binaries will also load and you will use the symbol as defined in the external binary. Static linking means everything you need (and nothing you don't) is right there, compiled into your binary, so you'll never load anything you don't need. On the other hand, every program that is statically linked has its own copy of the linked-in routines, which can be wasteful of disk space and memory. With dynamic linking, the entire external binary has to be available, even if you only need one symbol from it. On the other hand, there only needs to be one copy of the binary on disk, no matter how many times it is used. And most of the time, the operating system can arrange things so that only one copy of the binary's code is loaded into memory, no matter how many processes are using it. This can save a lot of memory. For most systems, it turns out to be much more efficient to load a multi-megabyte dynamic link library into every process rather than statically link just the 200k that you actually need from that library.
Finally, there is the OS involvement. The OS has to do a certain amount of setup for any process, no matter how trivial that process is. It has to allocate a stack, map the process into memory, set up virtual memory tables for it, etc. On a modern OS, in order for it to provide the services we expect, it has to set up a bunch of stuff just in case the process decides to make use of it. It is the price we pay for having a lot of power available to us.
So for an example, I wrote up two test programs. I'm a Windows guy, so everything was done using Visual C++ 7.1. The first test was just an empty main(). Compiled and linked statically, it takes 24k on disk. That is basically just the CRT startup and shutdown code and the signal handlers (plus error message strings, etc.). It also links (dynamically) to kernel32.dll, ntdll.dll, and the OS itself. It allocates 568k of user memory/136k VM, 7k of kernel memory, and holds 14 kernel objects (thread handle, process han
For one thing, I think it is reasonable to be upset about the vulnerabilities, and to hold Microsoft at least somewhat accountable -- even if it is almost impossible to catch all vulnerabilities, it still causes problems to people. It is hard to determine whether or not Microsoft has "more than their share" of vulnerabilities, since any comparison I can think of is like apples to oranges. But they do have more than anybody would like them to have (except hackers and people who want to see them fall).
For another thing, I'm not sure that anyone would listen or care. This is Slashdot, remember? People tend to accept the evidence that reinforces their current opinions, and reject the evidence that is contrary. So I don't have a lot of faith that any posting of this kind would really make any difference. Those who are determined to find fault in others (i.e. find fault in Microsoft) are probably going to find a way to blame them for all of the troubles in the world, and I can't say anything to stop them. Those who take a more reasonable approach are probably going to stay reasonable. Of course, this doesn't mean that we shouldn't post our views, but it makes me less inclined to try to do it every single time the issue arises. That would get boring really quickly (like the BSD is Dead post).
Disclaimer: I actually work for Microsoft, but they have nothing to do with my posts. Read my journal if you want to know more about where I stand. I like a lot of open source stuff, and I like a lot of Microsoft stuff. I have both a FreeBSD box and a Windows XP box running at home, and I break out the Knoppix CD every once in a while just for kicks. I really wish software were perfect, but it isn't, and the best we can do is get things fixed instead of pointing fingers (although sometimes pointing fingers is a good thing when it motivates the pointee to do a better job next time). I also use a lot of parenthesis, and I'm trying to break that habit.
The question shows that you haven't done a lot of real world programming, or if you have, you don't understand a lot of the issues. MySQL has been very carefully searched for overflows, but some overflows are very subtle and much harder to find than you might imagine.
It isn't that programmers are lazy (which we are, but that isn't the problem). It is that programmers can't keep perfect track of everything at once, and have to make assumptions. What am I supposed to tell my boss, something like "I can't start on that bug fix until I have read and perfectly comprehend all 1,500,000 lines of code in the product"? No, I have to try to get an overall idea of how things work, and dig into the details as I think necessary. This sometimes means I will miss a detail that is indirectly connected to the work at hand, and therefore make a mistake. The most important (in my opinion) and difficult work being done in computer science is in ways to organize things so that all of the details needed for a single problem are obvious and connected. Thus comes OOP and other programming methodologies that try to keep programs organized and well-structured.
If you read the article, it showed the code at fault. It wasn't just one function, but two. One function "validated" the password. Later, another function worked with the password, assuming (correctly) that it had already been "validated". The problem was that the two functions had different ideas about what it meant to be "validated". If the error had all been within one single function, then this would be almost inexcusable. But since the problem was a coincidence of two less significant flaws, it was much harder to detect. And if some automatic overrun detection tool were to flag the code, the programmer examining the warning would very likely have determined that the tool's warning was incorrect -- "the parameter was validated already before this function call, so the buffer overrun cannot happen."
Next, you can't just enter larger values to detect everything. In this case, the database ships with a 16 char limit on the password field. So sending a large value for password wouldn't work -- the value would be truncated when it went into the database. The bug is triggered by three unrelated operations in sequence: you alter the database to allow for larger values, THEN set a large value for password, and THEN flush the table. Automatic tools can't try every possible sequence of input, just a subset.
Aside from simply "getting it right in the first place" (i.e. never making invalid assumptions, which is pretty much impossible) this kind of problem can be avoided by using one of two programming.
The first is "Defense in Depth", which means that a function isn't allowed to assume that a parameter has been validated -- every function must validate every parameter ever time it is called. This works, but it has performance penalties (a parameter can be passed around hundreds of times, so now we validate it hundreds of times instead of just once). It also is boring to program the validation code, and therefore likely to be forgotten in some crucial function. Finally, validation is hard to get exactly right, and if the concept of a valid parameter changes, you have to go change it in every place it is validated.
The second is automatic handling of the situation. Use a string class of some sort, like STL's string, or use a "safe" language like Java or C#. This is better, but again it has costs in performance, as well as ignores the problem of interoperating with existing code.
So the "deeper problem" is that we can never get everything perfect by hand, and the automatic solutions come at a price we often aren't willing to pay. Solution? None at the moment. Perhaps in the future, less code will be written in "unsafe" languages (languages with potential for overflows), so buffer overflows will only be a problem for those who write the compilers and runtimes for those safe languages. But I wouldn't hold my breath -- it will be a while. And when that day finally comes, there will still be plenty of other ways to "root" a machine -- buffer overflows aren't the only way to overcome security measures.
First, ALTER the User table of the mysql database (the table that contains the usernames and passwords of users allowed to connect to the database server) so that the Password column can have more than 16 characters.
Second, UPDATE a row in the User table to give a user a "password" consisting of your buffer overflow code.
Third, get MySQL to try to process that user's login info. This is done with "FLUSH PRIVILEDGES" which flushes the cache of users and their passwords.
You now can execute code in the context of the MySQL server.
Of course, the MySQL server should be running as an unpriviledged user anyway. And most people who can admin the MySQL server can probably admin the whole box.
At Blue Screen, it will make a dump in the swap partition if so configured. The dump can be a 64k error summary (MiniDump), kernel memory dump, or a full physical memory dump (if swap > physical memory). While there is a slim possibility that doing this might make things worse (if the code to write the dump is corrupted, or the disk driver is corrupted), it is MUCH more likely that the information written will be useful. Also, the swap partition driver is pretty stable and simple, so chances are very good that it won't mess up anything that wasn't already messed up. If you're paranoid, you can turn off this feature.
At clean shutdown, it writes an event to the event log indicating clean shutdown.
At boot, if there is no "clean shutdown" event, it writes an "unexpected shutdown" event to the event log. It estimates the time of the crash based on the last events in the event log. Since Windows has periodic "I am running ok" events recorded to the event log, it can use the last "I am ok" event to guess at the crash time.
At boot, if there is a crash dump in the swap partition, it is recovered and copied to a file for subsequent analysis.
Two concepts are often confused: High Availability and Scalability. Probably because they have some solutions (clustering) in common. But they aren't the same, and I got the impression that the Comment was asking more about Scalability.
I think HA is a somewhat easier nut to crack than scalability. Make everything redundant, keep the copies in sync, and you're probably ok. Or as you mentioned, come up with a way that any single point of failure can be handled within a reasonable amount of time.
Scalability is a bit more difficult, esp. when the database must be updatable, or where the queries must be real-time and in sync with each other. You can't simply have mirrors or replacement components -- the systems have to talk to each other.
I can't think of a better way to exponentially increase the number of domains registered. Currently, FooBar company knows that nobody has registered any typo names, and that if anybody does, they can probably get rid of the type names through a lawsuit. Therefore, FooBar registers only foobar.com.
If this takes effect, the story changes. FooBar knows that if any customer makes a typo, Verisign will get to show an ad for Widget.com. The only way to make this go away is to register all of the possible typo names. So FooBar registers every single possible domain name that could possibly be considered close to FooBar. Bad for FooBar. Bad for anybody who wants a domain name (now they will ALL be taken), but good for Verisign.
Ok, this guy is mostly correct, but it is sure hard to read and get the real point. So here is a (hopefully more understandable) summary of what he was trying to say.
TV and movies can get away with 24 to 30 FPS mainly because the CAMERA that took the actor's picture kept the shutter open for almost the entire 1/24th of a second, so moving objects are blurry. That hides the fact that the actor moved quite a bit from one frame to the next, since the area between point A and point B is filled in with the blur. And since we don't have to shoot a railgun at the actor, this blur isn't a problem.
Games can't get away with that frame rate because they render for a single instant in time, and there isn't any blur to fill in the gap. Computers render instants, and figuring out blur isn't something that is really easy to do. And even if there were some blur to make the graphics move more smoothly, we might not like it as much as we do in movies -- you don't shoot railguns at blurs, you shoot them at actual heads.
The point at which the "instants" blur together in our brains is hard to determine. He claims that 72 FPS is good enough since we don't see the monitor flicker at that rate, but that is faulty reasoning. 72 Hz (or whatever) makes the flicker go away because the phosphors are still glowing pretty brightly by the time the next frame comes around, not because 72 Hz is good enough to fool our eyes. That is why the TV looks fine at 60 Hz Interlaced, and the IBM CGA monitor could get away with 60 Hz Interlaced, but a modern SVGA monitor at 60 Hz Interlaced would drive you nuts -- the phosphors don't glow as long in a modern monitor. Nevertheless, he is still correct in saying that it doesn't do much good to get a higher FPS than your monitor refresh rate can display -- at least as far as jumpiness is concerned. (As an aside, we may see future games that blend together the 5 frames that were generated while waiting for the V Synch, thus creating the same blur that makes TV and movies smooth.)
However, for fast reaction games, jumpiness isn't the only problem. You also have to consider latency.
Computer calculates and then records the position of items on the screen at a particular instant.
Computer renders items to a frame. (Elapsed time: 1/FPS seconds.)
Computer waits for V Sync (to avoid shearing) before changing to the newly rendered frame. (Average time is half of the monitor's refresh rate, so elapsed time is 1/FPS + 0.5/Hz seconds.)
CRT or LCD displays frame. (Elapsed time is 1/FPS + 1.5/Hz seconds.)
This is the latency between when something happens (according to the computer) and when that event actually appears on the screen. Of course, the frame appears over the period of time 1/FPS + 0.5/Hz (when the top of the frame appears on the screen) through 1/FPS + 1.5/Hz (when the frame is completely drawn on the screen), but the complete image doesn't appear until the end. If FPS is larger than the monitor's refresh rate, you can reduce the average 0.5/Hz time waiting for refresh by rendering new frames until the monitor is ready to display one of them, making the latency 1.5/FPS+1/Hz instead of 1/FPS+1.5/Hz.
Finally, he makes the good point that it isn't the average FPS that matters, even though it is the average that is always reported in the benchmarks. It is the minimum! It doesn't matter that the new "Fee Fie Fo Fum" adventure averages 200 FPS if it always slows to 4 FPS right when you are chopping down the beanstalk. The giant will still get you every time.
1. SMTP is not a one-hop operation. Mail goes from client to server 1 to server 2 to (destination) server 3. If server 3 decides to reject, you've just moved the problem to server 2, who has already accepted the mail. You haven't solved anything.
2. Not all servers are as efficient as yours seems to be. Some can't make such snappy decisions. Some actually scan for viruses or apply heuristics instead of rejecting anything with a scary attachment. Often, the scanning is done by a different system that pulls emails out of an "Incoming, unscanned" queue and puts them into an "Incoming, scanned" queue. This kind of situation makes it unreasonable to demand that all scanning take place before the 2xx response is sent.
3. Email simply can't be reliable once you introduce forged FROM headers into the equation. If the real sender can't be tracked down, then there is absolutely no better alternative than/dev/null.
You're speaking out of your rear. You've obviously never tried it. It defaults to allow outgoing connections only, and then you check a box next to each service you want to allow for incoming connections. If your service isn't listed, you can add one. That's way easier than iptables.
It's called the Internet Connection Firewall, and it is available on Win2k. It is under the Advanced tab of your network connection properties. It blocks all ports you don't want opened without forcing you to deal with figuring out how to shut down or reconfigure the corresponding service.
Slashdot Mirror
Yes, and that is what Variable Bit Rate / Variable Frame Rate is all about. Without VBR, the encoder knows "I have 192 Kbits (or whatever) to fill for this second of video." At some point where there is a lot of motion, the encoder has to cut the quality to make it all fit in 192 Kbits. Another time, where it is just 10 seconds of a single cel of some character pondering why girls are the way they are (or whatever), the encoder has 1920 Kbits that it doesn't know what to do with -- perhaps make that one frame look really really nice?
This is a good thing in some situations. Rationing the bandwidth allows you to make fairly good predictions about how much space the file will take on disk, or to properly get the data streamed in real time over the network. Predictability is a nice thing.
So VBR says that you're willing to trade a little bit of predictability in data rate for improved allocation of that bandwidth. More bandwidth is used for parts of the video that are hard to compress well. Less is used where less is going on. Overall, the result is usually somewhat better than you would have gotten if you were limited to a single bitrate. The disadvantages are: it is a bit harder to encode quickly when you add the task of figuring out how to allocate the bandwidth; sometimes the accuracy of your requested file size goes down (I asked for 192Kbits, but got more like 213Kbits), or the video bogs down during the action scenes when you're viewing it over the net.
You missed the part where he said "look at the way .Net handles versioning." Versioning is set up so that the Framework never gets upgraded. Instead of upgrading to a Framework version, you ADD an ADDITIONAL Framework version. Existing products will continue to use the version they were built for. This means that the old stuff will work fine.
It also means that Microsoft is much more free to completely rewrite the API since they won't be breaking any existing products. Sure, it breaks source code, but only for developers who want to build their product against the new Framework. So as the grandparent said, they're more willing to mess with devs.
No clue about Thunderbird.
But FireBird is great. No stability problems, no lack of features, and no installation issues.
Sure, you have to know how to unzip it by yourself. And if you want to upgrade, you have to remove the old version yourself, perhaps remove your profile, and you have to manually re-import any bookmarks and reinstall any plugins. But it isn't that hard.
Really, it is the best browser for general purpose browsing I've been able to get my hands on. Like any software, it has a few rough edges and quirks, but none of them are serious enough to not use it. Very few crashes, very few times when it doesn't let me do what I need to do. Better for general browsing than Explorer. I've been using it since 0.5 release, and I'm a convert. (Heck, I even work for Microsoft! Don't tell anyone that I'm using FireBird, or I might get in trouble (grin).)
1. Drivers. 'Nuff sed.
2. Performance. If they made the emulation perfect, everything would run perfectly, but there would be an unacceptably big hit on perf. Instead, they can adapt their emulation according to what the OS can tolerate reliably.
I work with some professors at BYU who produce similar courses-on-CD. These CDs are bundled with a 4-month (one semester) license to Enounce 2xAV for exactly the reasons you mention. Our system has explicit support for allowing the student to adjust the rate of delivery.
Of course (obligatory Slashdot dissing of Microsoft), if Microsoft had enabled the speed control feature of Media Player (pretty cool feature) on all operating systems that support Media Player 9 instead of just XP and beyond, we wouldn't even have to bundle Enounce. I suppose this is one case where Microsoft is helping smaller businesses!
Works fine in Windows, except when each mouse has special features. If you want the special features for just one of them, fine. Just install the driver that came with it. The default driver will kick in for the other one. If you want special features for both, it is a bit tricky to get both drivers to get along with each other in the control panel. The hardware drivers are fine. It is just the control panel that gets confused.
Are you serious or trolling?
1.0 Library: Yeah, you have to do the COM thing. But it really isn't that bad, and the problem has been solved for you -- just take the file (160 lines of code), add it to your assembly, then call the function. That wasn't so bad, was it?
1.1 Library: Use System.Windows.Forms.FolderBrowserDialog.
Classes can have inner classes as well as typedefs. Those are in the namespace of the class, so the namespace operator :: is used to access them.
And the sort question was answered by somebody else, but here is a bit more on the subject: if a bunch of classes share portions of their interfaces, and the shared subset is enough to perform a useful operation, why not share the implementation of the operation? While you could certainly "tell a vector to sort itself", it makes just as much sense to "apply the sort operation to a vector". Sort is not a primitive operation on a vector, it doesn't require access to the internals of the vector for efficient implementation, so there is no reason to make it a member.
The rest I agree with. A C++ master can do wonderous things, but there are few C++ masters out there. Very simply put, it is really tough to come up with the BEST way to do something in C++ -- there is always more than one way to do it, and doing it perfectly can take an impossible amount of time.
Also, since many useful concepts are possible to implement optimally, yet not built-in to the language, there are way too many libraries. How many different ways are strings expressed? Too many.
I didn't say they succeeded, only that they try...
Yes, everything is a tradeoff. That is why it takes experience to become a good programmer, so you have a feeling of which method is most appropriate.
From my experience, OOP is most important in application and systems development. OOP means that you can provide very specific and enforceable rules about how data can be manipulated and used, and a very limited set of code that can be blamed if any of the rules are broken. The private data of a class is only accessible by members of the class, so if the private data gets into an invalid state, you know that one of the class members has to be at fault (barring spurious pointers or hardware errors). Hopefully, all of the details you need to know about when working with the class are all right there within the class, so you can see them all at once. You don't have to make as many assumptions if all of the necessary details are all together, and class organization is a good way to create independent units of functionality.
If this kind of thing isn't important (it often isn't for simpler programs), then it is just a waste of time. But for complex systems, it is always crucial. Even systems that aren't really "object oriented" from a language perspective tend to be "object oriented" from a usage perspective. Windows does it with handles. UNIX also uses handles for files and sockets. Within the Linux kernel, there are a bunch of pointers that are only supposed to be accessed via macros or accessor functions -- that is nothing short of manually-enforced object oriented programming.
Very complicated question. Ughh, there are answers at many levels, and they are all different. But here goes.
Any decent linker nowadays is "smart." This means that it already does what you are asking for -- it knows how to figure out exactly what the dependencies are, and bring in only the symbols (a symbol in this context is a chunk of code or data) that are (directly or indirectly) referenced by your code. Even though you link against all of the C Runtime, or all of the string library, the linker realizes that you are only using strcat. For this example, we'll assume that strcat uses strlen and strcpy. So your call to strcat pulls in strcat, strcpy, and strlen, but nothing else. So what you mention actually is already happening. (Unless you turn off the "smart" linking, as is common for debugging purposes.)
However, there are some additional factors at work. The first is the C Runtime (CRT). ANSI C has some very specific requirements about how the environment is to be set up before main() is called, and how the system is to be cleaned up after main() exits. C also has specs about how to prepare the system for unexpected termination and signal handling. Setup and cleanup reference a bunch of additional symbols, so you end up with much more than just main(), strcat(), strcpy(), and strlen() -- you also have atexit(), exit() and etc. There is usually a process by which you can get rid of this and start directly in main with no setup code, but then you can't use any of the CRT-supplied functions (since the CRT isn't initialized) -- you have to set up your process yourself, handle signals yourself, and are limited to calling OS functions directly (no nice wrappers like fopen, printf or such).
Then there is the issue of linking. Static or dynamic? Static linking means that all of the symbols you reference, directly or indirectly, are compiled into your binary. Dynamic linking means that all of the symbols are converted to references to external binaries, and when your binary loads, the external binaries will also load and you will use the symbol as defined in the external binary. Static linking means everything you need (and nothing you don't) is right there, compiled into your binary, so you'll never load anything you don't need. On the other hand, every program that is statically linked has its own copy of the linked-in routines, which can be wasteful of disk space and memory. With dynamic linking, the entire external binary has to be available, even if you only need one symbol from it. On the other hand, there only needs to be one copy of the binary on disk, no matter how many times it is used. And most of the time, the operating system can arrange things so that only one copy of the binary's code is loaded into memory, no matter how many processes are using it. This can save a lot of memory. For most systems, it turns out to be much more efficient to load a multi-megabyte dynamic link library into every process rather than statically link just the 200k that you actually need from that library.
Finally, there is the OS involvement. The OS has to do a certain amount of setup for any process, no matter how trivial that process is. It has to allocate a stack, map the process into memory, set up virtual memory tables for it, etc. On a modern OS, in order for it to provide the services we expect, it has to set up a bunch of stuff just in case the process decides to make use of it. It is the price we pay for having a lot of power available to us.
So for an example, I wrote up two test programs. I'm a Windows guy, so everything was done using Visual C++ 7.1. The first test was just an empty main(). Compiled and linked statically, it takes 24k on disk. That is basically just the CRT startup and shutdown code and the signal handlers (plus error message strings, etc.). It also links (dynamically) to kernel32.dll, ntdll.dll, and the OS itself. It allocates 568k of user memory/136k VM, 7k of kernel memory, and holds 14 kernel objects (thread handle, process han
Sure, go ahead, if you think it'll do any good.
I dunno.
For one thing, I think it is reasonable to be upset about the vulnerabilities, and to hold Microsoft at least somewhat accountable -- even if it is almost impossible to catch all vulnerabilities, it still causes problems to people. It is hard to determine whether or not Microsoft has "more than their share" of vulnerabilities, since any comparison I can think of is like apples to oranges. But they do have more than anybody would like them to have (except hackers and people who want to see them fall).
For another thing, I'm not sure that anyone would listen or care. This is Slashdot, remember? People tend to accept the evidence that reinforces their current opinions, and reject the evidence that is contrary. So I don't have a lot of faith that any posting of this kind would really make any difference. Those who are determined to find fault in others (i.e. find fault in Microsoft) are probably going to find a way to blame them for all of the troubles in the world, and I can't say anything to stop them. Those who take a more reasonable approach are probably going to stay reasonable. Of course, this doesn't mean that we shouldn't post our views, but it makes me less inclined to try to do it every single time the issue arises. That would get boring really quickly (like the BSD is Dead post).
Disclaimer: I actually work for Microsoft, but they have nothing to do with my posts. Read my journal if you want to know more about where I stand. I like a lot of open source stuff, and I like a lot of Microsoft stuff. I have both a FreeBSD box and a Windows XP box running at home, and I break out the Knoppix CD every once in a while just for kicks. I really wish software were perfect, but it isn't, and the best we can do is get things fixed instead of pointing fingers (although sometimes pointing fingers is a good thing when it motivates the pointee to do a better job next time). I also use a lot of parenthesis, and I'm trying to break that habit.
The question shows that you haven't done a lot of real world programming, or if you have, you don't understand a lot of the issues. MySQL has been very carefully searched for overflows, but some overflows are very subtle and much harder to find than you might imagine.
It isn't that programmers are lazy (which we are, but that isn't the problem). It is that programmers can't keep perfect track of everything at once, and have to make assumptions. What am I supposed to tell my boss, something like "I can't start on that bug fix until I have read and perfectly comprehend all 1,500,000 lines of code in the product"? No, I have to try to get an overall idea of how things work, and dig into the details as I think necessary. This sometimes means I will miss a detail that is indirectly connected to the work at hand, and therefore make a mistake. The most important (in my opinion) and difficult work being done in computer science is in ways to organize things so that all of the details needed for a single problem are obvious and connected. Thus comes OOP and other programming methodologies that try to keep programs organized and well-structured.
If you read the article, it showed the code at fault. It wasn't just one function, but two. One function "validated" the password. Later, another function worked with the password, assuming (correctly) that it had already been "validated". The problem was that the two functions had different ideas about what it meant to be "validated". If the error had all been within one single function, then this would be almost inexcusable. But since the problem was a coincidence of two less significant flaws, it was much harder to detect. And if some automatic overrun detection tool were to flag the code, the programmer examining the warning would very likely have determined that the tool's warning was incorrect -- "the parameter was validated already before this function call, so the buffer overrun cannot happen."
Next, you can't just enter larger values to detect everything. In this case, the database ships with a 16 char limit on the password field. So sending a large value for password wouldn't work -- the value would be truncated when it went into the database. The bug is triggered by three unrelated operations in sequence: you alter the database to allow for larger values, THEN set a large value for password, and THEN flush the table. Automatic tools can't try every possible sequence of input, just a subset.
Aside from simply "getting it right in the first place" (i.e. never making invalid assumptions, which is pretty much impossible) this kind of problem can be avoided by using one of two programming.
The first is "Defense in Depth", which means that a function isn't allowed to assume that a parameter has been validated -- every function must validate every parameter ever time it is called. This works, but it has performance penalties (a parameter can be passed around hundreds of times, so now we validate it hundreds of times instead of just once). It also is boring to program the validation code, and therefore likely to be forgotten in some crucial function. Finally, validation is hard to get exactly right, and if the concept of a valid parameter changes, you have to go change it in every place it is validated.
The second is automatic handling of the situation. Use a string class of some sort, like STL's string, or use a "safe" language like Java or C#. This is better, but again it has costs in performance, as well as ignores the problem of interoperating with existing code.
So the "deeper problem" is that we can never get everything perfect by hand, and the automatic solutions come at a price we often aren't willing to pay. Solution? None at the moment. Perhaps in the future, less code will be written in "unsafe" languages (languages with potential for overflows), so buffer overflows will only be a problem for those who write the compilers and runtimes for those safe languages. But I wouldn't hold my breath -- it will be a while. And when that day finally comes, there will still be plenty of other ways to "root" a machine -- buffer overflows aren't the only way to overcome security measures.
More detail:
First, ALTER the User table of the mysql database (the table that contains the usernames and passwords of users allowed to connect to the database server) so that the Password column can have more than 16 characters.
Second, UPDATE a row in the User table to give a user a "password" consisting of your buffer overflow code.
Third, get MySQL to try to process that user's login info. This is done with "FLUSH PRIVILEDGES" which flushes the cache of users and their passwords.
You now can execute code in the context of the MySQL server.
Of course, the MySQL server should be running as an unpriviledged user anyway. And most people who can admin the MySQL server can probably admin the whole box.
Just goes to show that nobody's perfect, I guess.
Windows does something like this too.
At Blue Screen, it will make a dump in the swap partition if so configured. The dump can be a 64k error summary (MiniDump), kernel memory dump, or a full physical memory dump (if swap > physical memory). While there is a slim possibility that doing this might make things worse (if the code to write the dump is corrupted, or the disk driver is corrupted), it is MUCH more likely that the information written will be useful. Also, the swap partition driver is pretty stable and simple, so chances are very good that it won't mess up anything that wasn't already messed up. If you're paranoid, you can turn off this feature.
At clean shutdown, it writes an event to the event log indicating clean shutdown.
At boot, if there is no "clean shutdown" event, it writes an "unexpected shutdown" event to the event log. It estimates the time of the crash based on the last events in the event log. Since Windows has periodic "I am running ok" events recorded to the event log, it can use the last "I am ok" event to guess at the crash time.
At boot, if there is a crash dump in the swap partition, it is recovered and copied to a file for subsequent analysis.
Two concepts are often confused: High Availability and Scalability. Probably because they have some solutions (clustering) in common. But they aren't the same, and I got the impression that the Comment was asking more about Scalability.
I think HA is a somewhat easier nut to crack than scalability. Make everything redundant, keep the copies in sync, and you're probably ok. Or as you mentioned, come up with a way that any single point of failure can be handled within a reasonable amount of time.
Scalability is a bit more difficult, esp. when the database must be updatable, or where the queries must be real-time and in sync with each other. You can't simply have mirrors or replacement components -- the systems have to talk to each other.
I can't think of a better way to exponentially increase the number of domains registered. Currently, FooBar company knows that nobody has registered any typo names, and that if anybody does, they can probably get rid of the type names through a lawsuit. Therefore, FooBar registers only foobar.com.
If this takes effect, the story changes. FooBar knows that if any customer makes a typo, Verisign will get to show an ad for Widget.com. The only way to make this go away is to register all of the possible typo names. So FooBar registers every single possible domain name that could possibly be considered close to FooBar. Bad for FooBar. Bad for anybody who wants a domain name (now they will ALL be taken), but good for Verisign.
TV and movies can get away with 24 to 30 FPS mainly because the CAMERA that took the actor's picture kept the shutter open for almost the entire 1/24th of a second, so moving objects are blurry. That hides the fact that the actor moved quite a bit from one frame to the next, since the area between point A and point B is filled in with the blur. And since we don't have to shoot a railgun at the actor, this blur isn't a problem.
Games can't get away with that frame rate because they render for a single instant in time, and there isn't any blur to fill in the gap. Computers render instants, and figuring out blur isn't something that is really easy to do. And even if there were some blur to make the graphics move more smoothly, we might not like it as much as we do in movies -- you don't shoot railguns at blurs, you shoot them at actual heads.
The point at which the "instants" blur together in our brains is hard to determine. He claims that 72 FPS is good enough since we don't see the monitor flicker at that rate, but that is faulty reasoning. 72 Hz (or whatever) makes the flicker go away because the phosphors are still glowing pretty brightly by the time the next frame comes around, not because 72 Hz is good enough to fool our eyes. That is why the TV looks fine at 60 Hz Interlaced, and the IBM CGA monitor could get away with 60 Hz Interlaced, but a modern SVGA monitor at 60 Hz Interlaced would drive you nuts -- the phosphors don't glow as long in a modern monitor. Nevertheless, he is still correct in saying that it doesn't do much good to get a higher FPS than your monitor refresh rate can display -- at least as far as jumpiness is concerned. (As an aside, we may see future games that blend together the 5 frames that were generated while waiting for the V Synch, thus creating the same blur that makes TV and movies smooth.)
However, for fast reaction games, jumpiness isn't the only problem. You also have to consider latency.
- Computer calculates and then records the position of items on the screen at a particular instant.
- Computer renders items to a frame. (Elapsed time: 1/FPS seconds.)
- Computer waits for V Sync (to avoid shearing) before changing to the newly rendered frame. (Average time is half of the monitor's refresh rate, so elapsed time is 1/FPS + 0.5/Hz seconds.)
- CRT or LCD displays frame. (Elapsed time is 1/FPS + 1.5/Hz seconds.)
This is the latency between when something happens (according to the computer) and when that event actually appears on the screen. Of course, the frame appears over the period of time 1/FPS + 0.5/Hz (when the top of the frame appears on the screen) through 1/FPS + 1.5/Hz (when the frame is completely drawn on the screen), but the complete image doesn't appear until the end. If FPS is larger than the monitor's refresh rate, you can reduce the average 0.5/Hz time waiting for refresh by rendering new frames until the monitor is ready to display one of them, making the latency 1.5/FPS+1/Hz instead of 1/FPS+1.5/Hz.Finally, he makes the good point that it isn't the average FPS that matters, even though it is the average that is always reported in the benchmarks. It is the minimum! It doesn't matter that the new "Fee Fie Fo Fum" adventure averages 200 FPS if it always slows to 4 FPS right when you are chopping down the beanstalk. The giant will still get you every time.
That explains it. I've always wondered why the default netmask was always wrong for my 192.168 network.
1. SMTP is not a one-hop operation. Mail goes from client to server 1 to server 2 to (destination) server 3. If server 3 decides to reject, you've just moved the problem to server 2, who has already accepted the mail. You haven't solved anything.
/dev/null.
2. Not all servers are as efficient as yours seems to be. Some can't make such snappy decisions. Some actually scan for viruses or apply heuristics instead of rejecting anything with a scary attachment. Often, the scanning is done by a different system that pulls emails out of an "Incoming, unscanned" queue and puts them into an "Incoming, scanned" queue. This kind of situation makes it unreasonable to demand that all scanning take place before the 2xx response is sent.
3. Email simply can't be reliable once you introduce forged FROM headers into the equation. If the real sender can't be tracked down, then there is absolutely no better alternative than
You're speaking out of your rear. You've obviously never tried it. It defaults to allow outgoing connections only, and then you check a box next to each service you want to allow for incoming connections. If your service isn't listed, you can add one. That's way easier than iptables.
It's called the Internet Connection Firewall, and it is available on Win2k. It is under the Advanced tab of your network connection properties. It blocks all ports you don't want opened without forcing you to deal with figuring out how to shut down or reconfigure the corresponding service.
WinFS?
Essential COM .NET
.ORG and Essential .GOV?
Essential
So what's next, Essential