First, 3 drives in RAID-5 is not very useful. You get a lot of the disadvantages with few of the benefits. Having more drives really helps throughput. So go for more smaller drives over fewer faster drives for RAID-5.
Second, RAID-5 is great for read speeds, but less great for write speeds. A good caching controller will help hide this, but a small write operation requires a read from each disk in the set before the write can be completed (in order to recompute parity for the stripe). If this is mostly reading, or if most writes are large (not small and random), RAID-5 will work fine (data storage, data mining, etc). If writes are frequent (transactions), RAID-5 is painful. RAID-10 might be better.
Problem was that it was WordPerfect 6.0 for Windows competing against Word 95, and WordPerfect 6.0 for Windows was one screwed-up piece of work. Crashed a lot. Trouble with installation. Strange glitches with printing. I used it for a month of college, then switched to Word in desperation so I could get my paper in on time. And I'm a real geek. My aunt, who isn't a real geek, was calling me weekly with some glitch in her copy.
6.1 was better, but still barely usable. I never tried 6.2 or beyond. Sure, WordPerfect had great features, but Word did what I needed to do without crashing too often and without screwing up my whole system at install time.
Novell got behind at a critical point in the Word Processor Wars, and it cost them the industry. Too bad, so sad. They had a monopoly and they lost it, not vice-versa.
Same with Netware, if you ask me. Novell didn't go from 70% market share to (whatever it is now) by being the best. They were the best, but they got too far behind on Windows integration. Can't even start to tell you how many hours I wasted because the computer lab's login and file servers (Netware-based) were on the fritz. Again, by the time Novell got that fixed (I assume they got that fixed), they had lost a LOT of business. Sorry, dudes, you missed the boat.
Now, it looks like Novell is doing a lot of things right again. And maybe they can turn around. But they shouldn't be blaming Microsoft for their woes (er, I guess maybe they should, if it is an easy way to pick up a cool $500,000,000). They had a good thing going, but then they released crappy products (translation: worse than Microsoft's) for too many years in a row. Tough beans.
The same way we decide about a recount in any other situation. Whether electronic voting machines are involved has nothing to do with it. If (we need a recount) { do a recount; } The type of vote tabulation system doesn't enter into the equation, unless the system doesn't allow for recounts, which is a Bad Thing(TM).
There are laws about how to determine the value of (we need a recount). Generally, if one of those laws applies, a party can sue for a recount, and if the judge agrees that the law applies, a recount is ordered.
Current methods of determining (we need a recount) include:
-- Was the vote sufficiently close that the margin of error in the vote tabulation system might have been enough to swing the vote? (Most systems have a reasonably well known margin of error. A few tenths of a percent of bubbles don't get read correctly by the bubble-sheet scanners, a few percent of holes don't get read correctly on punch cards, etc.)
-- Were the results of the vote significantly different from exit polls or opinion polls?
Where does it say that this was due to the Win95/Win98 bug? (If I missed something, please let me know.) Just because it happens to be the same amount of time as the Win95 bug doesn't mean it is the same bug. The bug was never present in Windows 2000, AFAIK. And in any case, there's a reason why 49.7 is a "magic number" for uptime (hint: how many milliseconds are there in 49.7 days?), just as there was a reason why "2000" was a magic number for date problems and why 2037 will be another magic number for date problems.
Just because it runs on (OS) and just because it crashes doesn't mean it is (OS vendor)'s fault. In this case, you certainly can't blame Microsoft: there was a problem in the radio software, the software developers knew about it, the maintenance staff knew about it, it didn't get fixed, and it caused a problem. Where does Microsoft fit into that?
Did some research. The security cookie is used on a function if the following conditions hold true: The function must have a string array (char or wchar, int doesn't count) and the array must be "large enough" (larger than 4 or 8 bytes or so).
I suspect you're doing something wrong. The buffer overflow code works quite well, but I've seen two things that can go wrong with using it.
First, make sure you're using the/GS flag, not the/Gs flag. The capital S makes all the difference, but is often confused.
Second, the check only happens before the return from the function, and the error is raised only if the buffer overflowed to the return address. If the buffer overflow doesn't overwrite a return address, or if the function whose address was overwritten doesn't return, the buffer overflow detection will never trigger.
That said, the compiler uses some heuristics to determine whether a function has a dangerous buffer or not, and I've seen a couple of cases where it decides that the function must be safe even when it isn't. There is definitely some room for improvement.
On systems without hardware support for NX pages, DEP means that programs compiled with "Safe-SEH" enabled will have an check performed to verify that all exception handlers are valid (pre-registered).
On systems with hardware support for NX pages, DEP means that a page must be marked as executable before any code in that page can be executed.
Neither of these are the same as the/GS switch in newer Visual C++ compilers. (Not to be confused with the/Gs switch, which almost nobody should really ever be messing with anymore.) I suspect the grandparent poster is using/Gs, which is often confused with/GS (even in the MSDN documentation of the/Gs switch!).
Pretty much everything in XP SP2 was recompiled with the/GS switch on, which means that stack buffer overruns in system libraries is much less likely.
Make the phosphors only excite one cone type each, and you can generate all the colors the eye can see.
You are assuming that everybody's cones respond to the same wavelengths identically. That is most definitely not true. Different people's eyes respond to colors differently -- different people's cones have response curves centered at slightly different shades of red, green, and blue. In fact, some women have been found to have 4 different kinds of cones.
There are two ways to produce a perception of color. One way is to create a beam of light of the correct wavelength. A light with a wavelength between red and green would stimulate both the red and the green cones in my eye, creating the sensation of yellow. Another way is to mix multiple beams of other wavelengths. A mixture of red and green lights would also stimulate the red and green cones in my eye, creating the same sensation.
I could adjust two different beams of light (one pure yellow, one red + green) until they both appeared to me to be the same color. I would not be able to tell the difference between them. However, somebody else whose "red" cones centered on a slightly different wavelength of red would see the two beams of light to be slightly different colors.
Monitor manufacturers actually can't make everybody happy. They do their best to pick the shades of red, blue, and green that are most commonly the centers of the response curves for people's cones. If they hit the centers dead-on for you, your monitor would be able to create any color that you could see. But if your centers weren't quite dead-on, or if you were a woman with 4 different types of cones, there would be a significant range of colors that the monitor could never produce properly for you.
Re:SP2 - as secure as any linux distro...
on
XP2 Spotted In The Wild
·
· Score: 3, Interesting
The problem is that Microsoft can't make Windows secure, and it isn't Microsoft's fault. If Microsoft added a full-featured firewall and virus scanner to XP, they'd be in a heap-o-trouble. If they get sued half a billion bucks for bundling Media Player, think how fast they'd be in trouble for new features. And if they made it even remotely difficult for any ole' program to claim to be a virus scanner or a firewall, the same thing would happen.
Essentially, Microsoft has done the best they can in their position. And it is a very good step forward. Yes, any ActiveX control can mess with the firewall settings, but heck, any ActiveX control can do whatever it wants, including damage far beyond messing with your firewall settings. Once any attack has succeeded on your system, you are 0wn3d, whether or not the attack can mess with your security panel.
As far as IIS goes -- please examine the exploit records. Both Apache and IIS have had exploits against them. The IIS exploits get more press because there is a finger to point, but Apache, PHP, etc. certainly don't have a clean record either. IIS versions prior to 6 have had several notable problems, but IIS 6 has an excellent track record for the time it has been available, even better than Apache in the same time period. Go with what will get your project done best in the least amount of time, then stay up to date on the patches.
I set up the firewall on my brother's computer last night, and it automatically did the Right Thing. NetBIOS was enabled, which surprised me for a moment, but then I noticed that it was enabled only on the Ethernet card, not on the modem. In my brother's case, that was the right setting.
The overall settings appear to have them opened, but there are per-connection settings as well. NetBIOS connections (read: file and printer sharing) are important on most LANs, so they are enabled for LAN connections but disabled over WAN connections (PPP, PPPoE, etc.).
While there may be a few instances where the firewall misjudges whether or not a particular connection is WAN or LAN, for 99% of the people in the world, the default settings are going to be fine.
Well, yeah, it works on a block. I don't think the previous poster meant to have the comment taken literally. To sum it up, if you only change a small portion of a huge file, rsync and other similar algorithms are definitely going to save a lot of bandwidth over even the best compression schemes in all but the most contrived cases.
You're taking it out of context, or maybe misunderstanding the feature. Some backup systems require OS support, so you have to install something setuid, set up a service, or hack the kernel to even get it to work. The idea is that this runs as a user (as do other programs like rsync or scp) and not as a kernel component (like a filesystem driver).
Your interpretation: This program magically allows any user to read any file on the system without admin privileges.
Correct interpretation: This program does not require admin privileges to install or run, and can run as any user. (Of course, the files that the program can access are limited by the user it runs as.)
That requires a lot of empty disk space, and wastes a whole lotta network bandwidth. Remote nightly backups of a 100 GB drive this way is a surefire way to go bankrupt when you get the network bill...
If you are copying 400 GB, you'll use 400 GB of bandwidth (less with compression, perhaps 200GB) each time you back up, whether or not anything has actually changed. That's very bad.
The advantage of stuff like rsync is that it only sends the deltas over the network. I have a daily backup of my 400 GB over the net. If nothing changes, it only uses 100k of bandwidth.
Cygwin is not secure for daemons -- if user A is running a Cygwin program, you should assume that any user on the system can execute code as user A. This is due to the global shared memory that Cygwin uses to keep track of things -- it is accessible to all users and is assumed to be safe.
If you're going to use rsync, use Interix/SFU. That's what I currently use, though I might switch to Unison. Works great, though sometimes the permissions are a pain (the Posix permissions don't always translate nicely to Windows ACLs)...
I work at Microsoft. They asked us to upgrade our SP1 machines to the latest build of SP2. I started with a test box (for which I have Ghost images), and that went quite well. I moved on to two other boxes that I use for parallel builds (no Ghost images, but nothing lost if they die), and they came back up just great. At that point I was confident enough to upgrade my main system. Again, no trouble. All of my updates were done via the "Windows Update" web site.
While the first 3 machines were VERY clean machines (essentially XP + patches + antivirus, no other software installed and no major configuration changes), the 4th machine was my work machine -- I've probably installed or uninstalled something from my box every day for the past year (but I'm still on the original install of Windows). While I know how to keep the machine operating well, it definitely isn't a clean box.
As with any upgrade or patch, there are risks. But I had absolutely no trouble with the upgrade on any of the 4 machines. The only difference is that the firewall pops up a message box every once in a while asking if I want to allow a connection. Oh, the "Settings and Preferences" link from the Antitrust settlement was "restored" (how many times do I have to delete that thing?).
Nothing is ever perfect, especially with software. But Microsoft has tried very hard to make sure this will work well for everybody. And as far as I can tell, they've done a good job. Yes, there will be some bugs. Yes, you'll want to be careful about applying this to production machines (make backups!). But I think the majority of people will upgrade and have no trouble.
So, it was all Microsoft's fault that the BWM software sucked, eh?
Go look at all of the problems people ran into with the BMW. Then show me one problem that was due to an OS flaw. BMW wrote some lousy software for a computer that ran Windows CE. It certainly makes Microsoft look bad, but I don't really see why it is Microsoft's fault if BMW decides to come out with a really screwed-up car control system.
I can give you a bunch of examples of poorly designed products based on Linux. Does that mean Linux sucks?
Look, I've read Stroustrup's book, Special Edition, cover to cover. It's good stuff. And I program in C++ every day, and have done so for over a decade. I bet you $5 I know C++ MUCH better than you do. I've also graduated from college and been in the industry for a few years. I've learned a lot that goes beyond whatever sound bites Bjarne gave you (a lot more than I can put down in a slashdot posting).
I wasn't comparing Bubble Sort and QuickSort. I was giving an example of how you can do something that is less efficient from one point of view (QuickSort has a much larger code and data requirement than Bubble Sort) but is more efficient from another point of view (QuickSort is O(n log n) and Bubble Sort is O(n^2)).
I'm not bashing C++ as a language (though I've got plenty of ammo for that if you want it - C++ has some serious defects). I'm saying that Java and/or other VM-based architectures can and do outperform C++ and other "bare-metal" architectures. You can do an end run around my argument by saying that C++ could be run in a VM as well, but that defeats your initial argument that Java isn't efficient.
As far as a C++ VM, it exists. The Visual C++ compiler versions 7 (aka 13) and higher can compile C++ for a virtual machine (the Microsoft CLR). The resulting bytecode can be managed (i.e. use garbage collection, stay type-safe) or unmanaged (use pointers directly, be binary compatible with the equivalent native code). So it isn't just theory, it is real. As a test, some guys ported Quake to managed C++ and found that it actually performed fairly well.
But the issue isn't between C++ and Java. Both languages are appropriate for their applications. C++ was designed for bare metal, and does quite well for that. Java, C#, and other languages were designed for a VM architecture and they do quite well for that. C++ doesn't really work well in a VM, and there are problems trying to get Java and C# to run well outside of a VM.
The issue is whether VM bytecode can outperform fully compiled code. And this isn't just theory. You can already go to benchmarking sites and see that in some applications, a VM can outperform native code. It all depends on the situation. I gave a list of some of the factors that can help VM code be faster, and there are more waiting to be discovered.
In any case, you missed my point. Garbage collection using external libraries in C++ has serious issues because C++ simply wasn't designed with garbage collection in mind. Yes, it can work in some cases, but there are problems (nondeterministic destruction, leaks due to false pointers, etc.). To use C++ well in a VM, you have to change the way you write C++. The issue of low level/high level languages doesn't hold any water, since different languages apply to different problems, and I'm not concerned about languages here, just VM versus native.
As far as Java and C++ being on the same level -- they simply aren't. You can set up frameworks and template libraries to try to boost C++ up to the level of abstraction enjoyed by Java and C# programmers (such as the boost libraries and the STL), but even with these libraries C++ still doesn't match Java and C# in many areas. You have to properly USE those C++ libraries, and they are often fairly complicated to use correctly.
However, the case of resource initialization = allocation IS something that fits into this discussion. I use this idea as much as possible in the C++ code that I write. However, it doesn't tell the whole story by itself. What about deallocation? Not everything can go on the stack and be automatically deallocated on function exit. And even if it could, sometimes that isn't even as efficient as it could be.
First of all, yes, you can hide all of the memory management stuff in proper classes. That's better than C. But even better than hiding your memory managment stuff is not having any memory management stuff. The runtime can do it all! Instead of having to write memory management r
Most of what you said is very true. But things went downhill in the last two paragraphs.
Efficiency matters, but sometimes it doesn't come in the obvious ways. To set the tone, here are a few examples.
The Bubble sort takes only a few lines of code and has no significant memory requirements. A QuickSort takes 50 to 100 lines of code and uses a recursive algorithm requiring a stack of some sort. Yet for some reason many applications choose the QuickSort.
Virtual memory imposes a huge performance penalty on the system. Every memory access has to be translated into the physical address. Page tables take up a significant percentage of RAM. They complicate systems programming significantly. And somehow we would never dream of designing a serious system without virtual memory. And even after adding a FOURTH level of page tables, somehow the AMD64 is able to outperform the two and three level 32 bit chips.
Running software at different privilege levels introduces a huge penalty of context switching. An OS call, which cost only 4 to 10 cycles under DOS, now costs 1000 to 3000 cycles under a "modern" OS. Why would we actually prefer such gross inefficiencies?
Instead of setting up a direct cable link for data transmission across the US, which would create a direct link of only 3000 miles, many industries find it more efficient to sent the data 52,000 miles into space to have it bounced back by satellite.
The fastest way to get a missile from here to Russia is also via a trip into space.
What I'm trying to get at is that there are a lot of cases where the best solution looks wasteful until you get the big picture. You and I understand how a 4 level system of page table lookup can end up outperforming even a direct memory access scheme for some tasks, how kernel/user mode is a significant and necessary part of modern programming, even at the huge cost it adds to system calls, and how going the "long way" can be faster than the more direct route. So don't be afraid to consider alternatives that don't appeal to you at first glance.
So you don't like Java and other inefficient VM-based systems, and you don't believe that it can be faster? Yes, there are many systems for analyzing runtime behavior and using that data to perform static optimizations. But there's no reason Java can't apply those same optimizations. On the other hand, there are optimizations that Java can do that you CAN'T do with static code. For example, Java can inline a function across a shared-library boundary (this is a HUGE win). Java can remove expensive security access checks for an application that is already running at full trust level. Java can optimize the generated code for the current processor - Pentium 1 through 10? SIMD? Super-SIMD? MMX or no? Floating point? All of these cases can be handled really well by Java, and it can pick the instruction mix that matches your system perfectly. The static code generator has to make some compromises. You can load a different DLL for each processor, but honestly you can only distribute so many flavors of your library... and they'll be obsolete the next time Intel decides to change its optimization strategy. Running on a single proc system? You can seriously simplify your synchronization primitives, saving a LOT of cycles on multithreaded code. Lots of memory? Java can trade space for speed. Tight on memory? Java can trade speed for space. And it can change its mind from day to day, depending on what other apps you have running. The list goes on and on. Not all of the above optimizations have been implemented in production JVMs yet, but they have all been researched, and they aren't theoretical -- there are real performance tests that show they can make a difference. They just need a few more years to be built into the next generation of VMs.
A few other areas that people often don't think about: Bytecode is usually significantly more compact than the resulting machine code, especially on RISC chips. Throw in
First, it sounds like you have two different partitions on the same hard drive. That's a no-no for benchmarks. The first partition (the one at the outer edge of the disk) will always have much better performance than the second partition (the one closer to the middle). The disk spins at a constant RPM, but the outer cylinders have more tracks on them, so you get more data per revolution.
Second, the 1k default "segment" size for NTFS (cluster, methinks) only kicks in for fairly small disks. It is an explicit tradeoff between throughput and space efficiency. By using 1k clusters, you get a lower proportion of wasted space, but you have to spend more effort tracking down all of the additional clusters. With 16k clusters, you get a higher transfer rate at the cost of more space wasted per file. With a sufficiently larget disk, NTFS defaults to 4k clusters, which is a good default for most people. NTFS performance doesn't increase much after 4k for the average workload, and due to "resident" data streams, this doesn't waste much disk space either.
In any case, my experience has been that the performance difference between NTFS and FAT (which has never seemed to be very much) is way less significant than the reliability and extra features offered.
I don't think it is available now, but I think it would be a very useful thing to have this option available, even as a horrible hack.
On the side, I've been trying to round up information on what it takes to do this, but it sure has been a pain.
I'm not really sure why Microsoft it so tight-lipped about the IfsKit and the DDK, but my best guess is that they don't want the kind of support issues that would come with too many different kinds of file systems. I suppose they're thinking that if they make the barrier to entry sufficiently high, the only takers will be professional enough to provide a decent level of support so Microsoft doesn't have to.
For the vast majority of their customers, that is probably the right decision. But for the geeks (like me) who want to do crazy things with their computers, it sure is frustrating.
I actually work for Microsoft, so the good news is that I have access to the info. The bad news is that I probably can't open-source anything that I make with it, and that even if I could, it wouldn't be of any value (you'd have to have the IfsKit to build it...). But I'm looking into my options. My ideal would be to produce a usable interface for pluggable user-mode file systems. Performance wouldn't be great, but I think it would still be very useful. I'm pretty sure that I could release a free version (binary-only) of something would make at least a few geeks happy.
The plan is as follows: a driver provides a \\.\UMFS kernel namespace object that redirects IO requests to a user-mode service. The service has a set of registered plugins. A request for "\\.\UMFS\ReiserFS\Vol1\Hello.txt" would load the "ReiserFS" plugin and request "/Vol1/Hello.txt".
Once that is done, the rest is pretty easy. "Junctions" would allow you to make mount points into any desired branch of the UMFS tree, and the user-mode plugin interface would hopefully be reasonably simple. There could potentially be kernel-mode plugins as well, but that would be pretty far down the list of priorities.
The coolest part wouldn't be mounting ReiserFS, though. I think it would be much more interesting to implement filesystem access to other system resources -- WMI, Registry, Process/Thread table, etc.
Lot'sa other issues to worry about -- security, caching, etc. Not quite trivial. But it should be possible. Anyway, we'll see if I ever get time to implement it...
Slashdot Mirror
First, 3 drives in RAID-5 is not very useful. You get a lot of the disadvantages with few of the benefits. Having more drives really helps throughput. So go for more smaller drives over fewer faster drives for RAID-5.
Second, RAID-5 is great for read speeds, but less great for write speeds. A good caching controller will help hide this, but a small write operation requires a read from each disk in the set before the write can be completed (in order to recompute parity for the stripe). If this is mostly reading, or if most writes are large (not small and random), RAID-5 will work fine (data storage, data mining, etc). If writes are frequent (transactions), RAID-5 is painful. RAID-10 might be better.
Problem was that it was WordPerfect 6.0 for Windows competing against Word 95, and WordPerfect 6.0 for Windows was one screwed-up piece of work. Crashed a lot. Trouble with installation. Strange glitches with printing. I used it for a month of college, then switched to Word in desperation so I could get my paper in on time. And I'm a real geek. My aunt, who isn't a real geek, was calling me weekly with some glitch in her copy.
6.1 was better, but still barely usable. I never tried 6.2 or beyond. Sure, WordPerfect had great features, but Word did what I needed to do without crashing too often and without screwing up my whole system at install time.
Novell got behind at a critical point in the Word Processor Wars, and it cost them the industry. Too bad, so sad. They had a monopoly and they lost it, not vice-versa.
Same with Netware, if you ask me. Novell didn't go from 70% market share to (whatever it is now) by being the best. They were the best, but they got too far behind on Windows integration. Can't even start to tell you how many hours I wasted because the computer lab's login and file servers (Netware-based) were on the fritz. Again, by the time Novell got that fixed (I assume they got that fixed), they had lost a LOT of business. Sorry, dudes, you missed the boat.
Now, it looks like Novell is doing a lot of things right again. And maybe they can turn around. But they shouldn't be blaming Microsoft for their woes (er, I guess maybe they should, if it is an easy way to pick up a cool $500,000,000). They had a good thing going, but then they released crappy products (translation: worse than Microsoft's) for too many years in a row. Tough beans.
The same way we decide about a recount in any other situation. Whether electronic voting machines are involved has nothing to do with it. If (we need a recount) { do a recount; } The type of vote tabulation system doesn't enter into the equation, unless the system doesn't allow for recounts, which is a Bad Thing(TM).
There are laws about how to determine the value of (we need a recount). Generally, if one of those laws applies, a party can sue for a recount, and if the judge agrees that the law applies, a recount is ordered.
Current methods of determining (we need a recount) include:
-- Was the vote sufficiently close that the margin of error in the vote tabulation system might have been enough to swing the vote? (Most systems have a reasonably well known margin of error. A few tenths of a percent of bubbles don't get read correctly by the bubble-sheet scanners, a few percent of holes don't get read correctly on punch cards, etc.)
-- Were the results of the vote significantly different from exit polls or opinion polls?
-- Was there evidence of fraud?
Strangely enought, it isn't.
ntoskrnl.exe is.
Kernel32.dll is the user-mode public interface to the basic kernel functionality.
For any of these benchmarks, does somebody have comparable statistics for a C/C++ implementation?
Obviously some of the benchmarks would be apples-and-oranges, but there should be a few of them that would allow a direct comparison...
Where does it say that this was due to the Win95/Win98 bug? (If I missed something, please let me know.) Just because it happens to be the same amount of time as the Win95 bug doesn't mean it is the same bug. The bug was never present in Windows 2000, AFAIK. And in any case, there's a reason why 49.7 is a "magic number" for uptime (hint: how many milliseconds are there in 49.7 days?), just as there was a reason why "2000" was a magic number for date problems and why 2037 will be another magic number for date problems.
Just because it runs on (OS) and just because it crashes doesn't mean it is (OS vendor)'s fault. In this case, you certainly can't blame Microsoft: there was a problem in the radio software, the software developers knew about it, the maintenance staff knew about it, it didn't get fixed, and it caused a problem. Where does Microsoft fit into that?
Did some research. The security cookie is used on a function if the following conditions hold true: The function must have a string array (char or wchar, int doesn't count) and the array must be "large enough" (larger than 4 or 8 bytes or so).
I suspect you're doing something wrong. The buffer overflow code works quite well, but I've seen two things that can go wrong with using it.
/GS flag, not the /Gs flag. The capital S makes all the difference, but is often confused.
First, make sure you're using the
Second, the check only happens before the return from the function, and the error is raised only if the buffer overflowed to the return address. If the buffer overflow doesn't overwrite a return address, or if the function whose address was overwritten doesn't return, the buffer overflow detection will never trigger.
That said, the compiler uses some heuristics to determine whether a function has a dangerous buffer or not, and I've seen a couple of cases where it decides that the function must be safe even when it isn't. There is definitely some room for improvement.
Here is a bit more info:
/GS switch in newer Visual C++ compilers. (Not to be confused with the /Gs switch, which almost nobody should really ever be messing with anymore.) I suspect the grandparent poster is using /Gs, which is often confused with /GS (even in the MSDN documentation of the /Gs switch!).
/GS switch on, which means that stack buffer overruns in system libraries is much less likely.
On systems without hardware support for NX pages, DEP means that programs compiled with "Safe-SEH" enabled will have an check performed to verify that all exception handlers are valid (pre-registered).
On systems with hardware support for NX pages, DEP means that a page must be marked as executable before any code in that page can be executed.
Neither of these are the same as the
Pretty much everything in XP SP2 was recompiled with the
Make the phosphors only excite one cone type each, and you can generate all the colors the eye can see.
You are assuming that everybody's cones respond to the same wavelengths identically. That is most definitely not true. Different people's eyes respond to colors differently -- different people's cones have response curves centered at slightly different shades of red, green, and blue. In fact, some women have been found to have 4 different kinds of cones.
There are two ways to produce a perception of color. One way is to create a beam of light of the correct wavelength. A light with a wavelength between red and green would stimulate both the red and the green cones in my eye, creating the sensation of yellow. Another way is to mix multiple beams of other wavelengths. A mixture of red and green lights would also stimulate the red and green cones in my eye, creating the same sensation.
I could adjust two different beams of light (one pure yellow, one red + green) until they both appeared to me to be the same color. I would not be able to tell the difference between them. However, somebody else whose "red" cones centered on a slightly different wavelength of red would see the two beams of light to be slightly different colors.
Monitor manufacturers actually can't make everybody happy. They do their best to pick the shades of red, blue, and green that are most commonly the centers of the response curves for people's cones. If they hit the centers dead-on for you, your monitor would be able to create any color that you could see. But if your centers weren't quite dead-on, or if you were a woman with 4 different types of cones, there would be a significant range of colors that the monitor could never produce properly for you.
The problem is that Microsoft can't make Windows secure, and it isn't Microsoft's fault. If Microsoft added a full-featured firewall and virus scanner to XP, they'd be in a heap-o-trouble. If they get sued half a billion bucks for bundling Media Player, think how fast they'd be in trouble for new features. And if they made it even remotely difficult for any ole' program to claim to be a virus scanner or a firewall, the same thing would happen.
Essentially, Microsoft has done the best they can in their position. And it is a very good step forward. Yes, any ActiveX control can mess with the firewall settings, but heck, any ActiveX control can do whatever it wants, including damage far beyond messing with your firewall settings. Once any attack has succeeded on your system, you are 0wn3d, whether or not the attack can mess with your security panel.
As far as IIS goes -- please examine the exploit records. Both Apache and IIS have had exploits against them. The IIS exploits get more press because there is a finger to point, but Apache, PHP, etc. certainly don't have a clean record either. IIS versions prior to 6 have had several notable problems, but IIS 6 has an excellent track record for the time it has been available, even better than Apache in the same time period. Go with what will get your project done best in the least amount of time, then stay up to date on the patches.
I set up the firewall on my brother's computer last night, and it automatically did the Right Thing. NetBIOS was enabled, which surprised me for a moment, but then I noticed that it was enabled only on the Ethernet card, not on the modem. In my brother's case, that was the right setting.
The overall settings appear to have them opened, but there are per-connection settings as well. NetBIOS connections (read: file and printer sharing) are important on most LANs, so they are enabled for LAN connections but disabled over WAN connections (PPP, PPPoE, etc.).
While there may be a few instances where the firewall misjudges whether or not a particular connection is WAN or LAN, for 99% of the people in the world, the default settings are going to be fine.
Well, yeah, it works on a block. I don't think the previous poster meant to have the comment taken literally. To sum it up, if you only change a small portion of a huge file, rsync and other similar algorithms are definitely going to save a lot of bandwidth over even the best compression schemes in all but the most contrived cases.
You're taking it out of context, or maybe misunderstanding the feature. Some backup systems require OS support, so you have to install something setuid, set up a service, or hack the kernel to even get it to work. The idea is that this runs as a user (as do other programs like rsync or scp) and not as a kernel component (like a filesystem driver).
Your interpretation: This program magically allows any user to read any file on the system without admin privileges.
Correct interpretation: This program does not require admin privileges to install or run, and can run as any user. (Of course, the files that the program can access are limited by the user it runs as.)
That requires a lot of empty disk space, and wastes a whole lotta network bandwidth. Remote nightly backups of a 100 GB drive this way is a surefire way to go bankrupt when you get the network bill...
If you are copying 400 GB, you'll use 400 GB of bandwidth (less with compression, perhaps 200GB) each time you back up, whether or not anything has actually changed. That's very bad.
The advantage of stuff like rsync is that it only sends the deltas over the network. I have a daily backup of my 400 GB over the net. If nothing changes, it only uses 100k of bandwidth.
Don't do this. You lose all the benefits of rsync this way. In fact, it will use 2X the network.
Source -1- rsync1 -2- rsync2 -3- Destination
RSync works assuming that paths #1 and #3 are fast (local) and that #2 is slow (network). So it does extra reads over #1 and #3 to minimize #2.
Your suggestion puts #2 and #3 local and #1 on the network.
When you create shared memory, you can put whatever permissions you want on it.
You wouldn't say that Linux is broken because you can make a file world-writable, would you?
Cygwin is not secure for daemons -- if user A is running a Cygwin program, you should assume that any user on the system can execute code as user A. This is due to the global shared memory that Cygwin uses to keep track of things -- it is accessible to all users and is assumed to be safe.
If you're going to use rsync, use Interix/SFU. That's what I currently use, though I might switch to Unison. Works great, though sometimes the permissions are a pain (the Posix permissions don't always translate nicely to Windows ACLs)...
I work at Microsoft. They asked us to upgrade our SP1 machines to the latest build of SP2. I started with a test box (for which I have Ghost images), and that went quite well. I moved on to two other boxes that I use for parallel builds (no Ghost images, but nothing lost if they die), and they came back up just great. At that point I was confident enough to upgrade my main system. Again, no trouble. All of my updates were done via the "Windows Update" web site.
While the first 3 machines were VERY clean machines (essentially XP + patches + antivirus, no other software installed and no major configuration changes), the 4th machine was my work machine -- I've probably installed or uninstalled something from my box every day for the past year (but I'm still on the original install of Windows). While I know how to keep the machine operating well, it definitely isn't a clean box.
As with any upgrade or patch, there are risks. But I had absolutely no trouble with the upgrade on any of the 4 machines. The only difference is that the firewall pops up a message box every once in a while asking if I want to allow a connection. Oh, the "Settings and Preferences" link from the Antitrust settlement was "restored" (how many times do I have to delete that thing?).
Nothing is ever perfect, especially with software. But Microsoft has tried very hard to make sure this will work well for everybody. And as far as I can tell, they've done a good job. Yes, there will be some bugs. Yes, you'll want to be careful about applying this to production machines (make backups!). But I think the majority of people will upgrade and have no trouble.
So, it was all Microsoft's fault that the BWM software sucked, eh?
Go look at all of the problems people ran into with the BMW. Then show me one problem that was due to an OS flaw. BMW wrote some lousy software for a computer that ran Windows CE. It certainly makes Microsoft look bad, but I don't really see why it is Microsoft's fault if BMW decides to come out with a really screwed-up car control system.
I can give you a bunch of examples of poorly designed products based on Linux. Does that mean Linux sucks?
Look, I've read Stroustrup's book, Special Edition, cover to cover. It's good stuff. And I program in C++ every day, and have done so for over a decade. I bet you $5 I know C++ MUCH better than you do. I've also graduated from college and been in the industry for a few years. I've learned a lot that goes beyond whatever sound bites Bjarne gave you (a lot more than I can put down in a slashdot posting).
I wasn't comparing Bubble Sort and QuickSort. I was giving an example of how you can do something that is less efficient from one point of view (QuickSort has a much larger code and data requirement than Bubble Sort) but is more efficient from another point of view (QuickSort is O(n log n) and Bubble Sort is O(n^2)).
I'm not bashing C++ as a language (though I've got plenty of ammo for that if you want it - C++ has some serious defects). I'm saying that Java and/or other VM-based architectures can and do outperform C++ and other "bare-metal" architectures. You can do an end run around my argument by saying that C++ could be run in a VM as well, but that defeats your initial argument that Java isn't efficient.
As far as a C++ VM, it exists. The Visual C++ compiler versions 7 (aka 13) and higher can compile C++ for a virtual machine (the Microsoft CLR). The resulting bytecode can be managed (i.e. use garbage collection, stay type-safe) or unmanaged (use pointers directly, be binary compatible with the equivalent native code). So it isn't just theory, it is real. As a test, some guys ported Quake to managed C++ and found that it actually performed fairly well.
But the issue isn't between C++ and Java. Both languages are appropriate for their applications. C++ was designed for bare metal, and does quite well for that. Java, C#, and other languages were designed for a VM architecture and they do quite well for that. C++ doesn't really work well in a VM, and there are problems trying to get Java and C# to run well outside of a VM.
The issue is whether VM bytecode can outperform fully compiled code. And this isn't just theory. You can already go to benchmarking sites and see that in some applications, a VM can outperform native code. It all depends on the situation. I gave a list of some of the factors that can help VM code be faster, and there are more waiting to be discovered.
In any case, you missed my point. Garbage collection using external libraries in C++ has serious issues because C++ simply wasn't designed with garbage collection in mind. Yes, it can work in some cases, but there are problems (nondeterministic destruction, leaks due to false pointers, etc.). To use C++ well in a VM, you have to change the way you write C++. The issue of low level/high level languages doesn't hold any water, since different languages apply to different problems, and I'm not concerned about languages here, just VM versus native.
As far as Java and C++ being on the same level -- they simply aren't. You can set up frameworks and template libraries to try to boost C++ up to the level of abstraction enjoyed by Java and C# programmers (such as the boost libraries and the STL), but even with these libraries C++ still doesn't match Java and C# in many areas. You have to properly USE those C++ libraries, and they are often fairly complicated to use correctly.
However, the case of resource initialization = allocation IS something that fits into this discussion. I use this idea as much as possible in the C++ code that I write. However, it doesn't tell the whole story by itself. What about deallocation? Not everything can go on the stack and be automatically deallocated on function exit. And even if it could, sometimes that isn't even as efficient as it could be.
First of all, yes, you can hide all of the memory management stuff in proper classes. That's better than C. But even better than hiding your memory managment stuff is not having any memory management stuff. The runtime can do it all! Instead of having to write memory management r
Most of what you said is very true. But things went downhill in the last two paragraphs.
Efficiency matters, but sometimes it doesn't come in the obvious ways. To set the tone, here are a few examples.
The Bubble sort takes only a few lines of code and has no significant memory requirements. A QuickSort takes 50 to 100 lines of code and uses a recursive algorithm requiring a stack of some sort. Yet for some reason many applications choose the QuickSort.
Virtual memory imposes a huge performance penalty on the system. Every memory access has to be translated into the physical address. Page tables take up a significant percentage of RAM. They complicate systems programming significantly. And somehow we would never dream of designing a serious system without virtual memory. And even after adding a FOURTH level of page tables, somehow the AMD64 is able to outperform the two and three level 32 bit chips.
Running software at different privilege levels introduces a huge penalty of context switching. An OS call, which cost only 4 to 10 cycles under DOS, now costs 1000 to 3000 cycles under a "modern" OS. Why would we actually prefer such gross inefficiencies?
Instead of setting up a direct cable link for data transmission across the US, which would create a direct link of only 3000 miles, many industries find it more efficient to sent the data 52,000 miles into space to have it bounced back by satellite.
The fastest way to get a missile from here to Russia is also via a trip into space.
What I'm trying to get at is that there are a lot of cases where the best solution looks wasteful until you get the big picture. You and I understand how a 4 level system of page table lookup can end up outperforming even a direct memory access scheme for some tasks, how kernel/user mode is a significant and necessary part of modern programming, even at the huge cost it adds to system calls, and how going the "long way" can be faster than the more direct route. So don't be afraid to consider alternatives that don't appeal to you at first glance.
So you don't like Java and other inefficient VM-based systems, and you don't believe that it can be faster? Yes, there are many systems for analyzing runtime behavior and using that data to perform static optimizations. But there's no reason Java can't apply those same optimizations. On the other hand, there are optimizations that Java can do that you CAN'T do with static code. For example, Java can inline a function across a shared-library boundary (this is a HUGE win). Java can remove expensive security access checks for an application that is already running at full trust level. Java can optimize the generated code for the current processor - Pentium 1 through 10? SIMD? Super-SIMD? MMX or no? Floating point? All of these cases can be handled really well by Java, and it can pick the instruction mix that matches your system perfectly. The static code generator has to make some compromises. You can load a different DLL for each processor, but honestly you can only distribute so many flavors of your library... and they'll be obsolete the next time Intel decides to change its optimization strategy. Running on a single proc system? You can seriously simplify your synchronization primitives, saving a LOT of cycles on multithreaded code. Lots of memory? Java can trade space for speed. Tight on memory? Java can trade speed for space. And it can change its mind from day to day, depending on what other apps you have running. The list goes on and on. Not all of the above optimizations have been implemented in production JVMs yet, but they have all been researched, and they aren't theoretical -- there are real performance tests that show they can make a difference. They just need a few more years to be built into the next generation of VMs.
A few other areas that people often don't think about: Bytecode is usually significantly more compact than the resulting machine code, especially on RISC chips. Throw in
Couple of things to check.
First, it sounds like you have two different partitions on the same hard drive. That's a no-no for benchmarks. The first partition (the one at the outer edge of the disk) will always have much better performance than the second partition (the one closer to the middle). The disk spins at a constant RPM, but the outer cylinders have more tracks on them, so you get more data per revolution.
Second, the 1k default "segment" size for NTFS (cluster, methinks) only kicks in for fairly small disks. It is an explicit tradeoff between throughput and space efficiency. By using 1k clusters, you get a lower proportion of wasted space, but you have to spend more effort tracking down all of the additional clusters. With 16k clusters, you get a higher transfer rate at the cost of more space wasted per file. With a sufficiently larget disk, NTFS defaults to 4k clusters, which is a good default for most people. NTFS performance doesn't increase much after 4k for the average workload, and due to "resident" data streams, this doesn't waste much disk space either.
In any case, my experience has been that the performance difference between NTFS and FAT (which has never seemed to be very much) is way less significant than the reliability and extra features offered.
I don't think it is available now, but I think it would be a very useful thing to have this option available, even as a horrible hack.
On the side, I've been trying to round up information on what it takes to do this, but it sure has been a pain.
I'm not really sure why Microsoft it so tight-lipped about the IfsKit and the DDK, but my best guess is that they don't want the kind of support issues that would come with too many different kinds of file systems. I suppose they're thinking that if they make the barrier to entry sufficiently high, the only takers will be professional enough to provide a decent level of support so Microsoft doesn't have to.
For the vast majority of their customers, that is probably the right decision. But for the geeks (like me) who want to do crazy things with their computers, it sure is frustrating.
I actually work for Microsoft, so the good news is that I have access to the info. The bad news is that I probably can't open-source anything that I make with it, and that even if I could, it wouldn't be of any value (you'd have to have the IfsKit to build it...). But I'm looking into my options. My ideal would be to produce a usable interface for pluggable user-mode file systems. Performance wouldn't be great, but I think it would still be very useful. I'm pretty sure that I could release a free version (binary-only) of something would make at least a few geeks happy.
The plan is as follows: a driver provides a \\.\UMFS kernel namespace object that redirects IO requests to a user-mode service. The service has a set of registered plugins. A request for "\\.\UMFS\ReiserFS\Vol1\Hello.txt" would load the "ReiserFS" plugin and request "/Vol1/Hello.txt".
Once that is done, the rest is pretty easy. "Junctions" would allow you to make mount points into any desired branch of the UMFS tree, and the user-mode plugin interface would hopefully be reasonably simple. There could potentially be kernel-mode plugins as well, but that would be pretty far down the list of priorities.
The coolest part wouldn't be mounting ReiserFS, though. I think it would be much more interesting to implement filesystem access to other system resources -- WMI, Registry, Process/Thread table, etc.
Lot'sa other issues to worry about -- security, caching, etc. Not quite trivial. But it should be possible. Anyway, we'll see if I ever get time to implement it...