Microsoft has clearly put its own and other company's interests ahead in Vista by adding features that do nothing for me as a consumer. I doubt those will be removed in Windows 7, and even suspect they will be worse. That's reason enough for me to not even consider Windows 7.
That's great, I sure hope that all that extra disk access for caching these things doesn't get in the way when I'm accessing the disk for my own reasons. Luckily disks can handle multiple programs accessing it simultaneously without any noticeable slowdown at all (now where's my sarcasm mark?).
I'm no fan of vista, but 32-bit and a "3 GB limit" have nothing to do with each other.
The 3 GB limit you see is usually because your motherboard does not support more than 4 GB of RAM (of which RAM included on graphics cards and used by other PCI devices gets substracted). Since I never ran Vista, I can only assume it is capable of using more than 4 GB of RAM even in 32-bit mode, just like it's predecessor XP and Windows 2003 can (running Windows 2003 here, in 32-bit, with 6 GB of RAM that it can use without problem).
what happens when you try something complicated? something that users ACTUALLY spend a fair bit of processor time on? like say, compression/decompression?
You mean writing something that already exists? I guess you already missed a big point of why Java is being used then. For such things we just use the existing libraries (which donot necessarily have to be Java based), or more likely, the built-in zip style compression, which may or may not be optimized for your platform depending on where you actually run the code.
I don't define myself as "hesitant" to use manage code, I define myself as "where's my pointer?"
You are right there are no pointers in Java. The closest thing are Object references. The big difference between pointers and Object references though are that Object references are a completely separate type that does not derive from a basic type like int or long depending on your platform. This means that certain operations, especially calculations, are simply not allowed as they make no sense (pointers in Java make no sense as there's no address space, which also happens to make Java virtually immune to some security issues like buffer overflow exploits).
Still, object references can be thought of as pointers, but more abstract. You can still do the important stuff with them, like putting them in lists, dereferencing them, double indirect lists, etc.. with the big advantage that everything you can do can be closely and accurately scrutinized by the compiler.
One of the biggest design goals for Java was to eliminate large sources of potential (programming) problems by making it possible for a compiler to make sense out of your code. Java, and perhaps C#, are currently probably the most strict programming languages there are, providing more compile time checks then ever before. It also makes Java very refactorable and is the reason why Java IDE's can provide so much automated refactorings and fixes, with quite a high degree of confidence that these will not affect the intent of the code.
Eclipse is usually quoted as being a big "resource hog", but few people realize really why it is using all those resources. You, like many, probably think it is "wasting" all that memory and is just being an inefficient dog. However, in reality, most of the memory eclipse uses is to make it work faster, and being able to provide you with fast code completion, error analysis as you type, fast searching and compilation. Eclipse will use more memory generally when you have more source files to work with, causing it to have to index more data for almost instant use (code completion especially needs to be fast to be useful). It will also do a lot caching of files for performance reasons.
For smaller projects, containing say 200-300 source files, Eclipse happily runs with 40 MB of RAM, and won't exceed that unless really needed. If you feel it is wasting too much resources, then turn off some of the useful features... you may find that wasting resources for very handy features is not that bad a trade-off.
I don't see any problem at all. Everything that worked on a single core will also work on a multi core system. The language is largely irrelevant, because 99% of the code written is actually not worth optimizing at all. The 1% that might be worth optimizing (something which depends on how much data that needs to be processed) can easily be written multithreaded even in the most mundane of languages... if someone didn't do it for you yet in some kind of library.
Just because functional programming is supposed to work better with multi-cores, doesn't mean you have to write every mundane piece of trash code (ie, code that does nothing worth optimizing) in it. Who cares if some event handler (responding to some user action) could have been written multi-threaded if the total runtime is on the order of microseconds? The bottleneck is often the user, there's no sense in optimizing any of that code and thus no sense in writing it in a specific language either.
Unfortunately, there's no paging algorithm that is smart enough to do this. It would need to be able to predict when I intend to do something before I know I wanted to do it (yes I know Vista is trying to do that.. emphasis on "trying"). It would need to predict that I got home at 3 am on a thursday night, and instead of going straight to bed would realize I wanted to check my mail first (and swap it back in before I click it). It would need to predict that after leaving the machine untouched for a week, I suddenly VNC to it from my holiday to check on my torrents progress. In short, it would need to be able to predict the future.
Until this is possible, the next best thing is to stick enough RAM in and disable swap completely, it is far more optimal than the current algorithm.
It looks like a solid argument, but it really only applies to certain environments.
From a user's perspective, there's only one time when performance matters: When they're at the keyboard.
I don't care if my system runs 0.0001% better when I'm NOT at the keyboard... I don't give a damn what the reasons are that my programs don't work snappy anymore when I get back to the system, when I get back to the system I expect my programs to work as they did before I left it. These days, that is EASILY possible, so why doesn't Windows care about the user experience?
You need to determine if the physical media was a bottleneck or not. When playing media files, the disk is never a bottleneck, and the data is thus not really worth caching in the long term. So, if a program requests data at a pace that is slower than disk I/O, then it should not be long term cached. There's lots of ways you can measure this. You can see if the program actually needs to wait for I/O, you can see if it the smart read-ahead is producing a 100% hit rate, or you can impose some hard coded limit (ie, requests below X MB/sec are not worth caching long term).
This would work pretty well for media playback, but wouldn't do much for copying large directories, or for virus scanners. Virus scanners however could implement a friendly scanning mode, that will keep scan speed below a certain maximum, thus signaling the caching system that only short term caching is really needed.
You won't really notice (*). The disk/file cache still does it's job without swap being active, it just cannot sacrifice program data for file/disk cache anymore -- exactly the way I want it. So, in a 4 GB system, and 2 GB is taken up by programs, there's still 2 GB of space for caching file data. That's likely enough to cache the entire directory structure of everything you have twice over.
(*) assuming you are not pushing close to an out of memory already (I recommend sticking in twice as much RAM as you'd really need to run all of your often used programs at once).
When I'm at the computer, I expect good performance. I dislike waiting. When I open a program, and leave it open, I did so because I intend to use it, now, or at some unpredictable time in the future.
When I'm NOT at the computer, and thus not directly using any of my programs, I also don't give a damn about PERFORMANCE.
Yet, when I'm not at the computer, Windows thinks it would be a good idea to swap out programs to make more room for caching files (without a limit I might add, it will happily waste all of my 6 GB of physical memory on this) to increase performance, something that is irrelevant since I'm not there anyway. For this completely useless benefit, it sacrifices everything...
The actual result is that when I get BACK to my computer, I get shitty performance -- right at the moment performance starts to really matter again.
The "fix" for this problem is trivially easy, but unfortunately, not possible in modern versions of Windows: Put a limit on the file/disk cache to prevent it from pushing things to swap (in my 6 GB system, I could tell it to never use more than 2 GB of that space for caching -- and all would be great..). Since that is not an option, I used the next best thing, I turned off swap. File/disk caching still works perfectly, except now it is forced to play within the confines of that 6 GB of memory (and usually there's still like 4+ GB to play with:))
It can potentially speed up your machine, because, like all caching algorithms, the decision to cache or not cache something is just a best guess.
Also, caching only brings benefits when data is used more than once. This is especially important. So.. for example, copying a large file once will not benefit from caching. Copying an entire disk multiple times (assuming the disk size is greater than your physical memory), will never benefit from caching (ignoring stuff like read-ahead). Scanning your entire disk for virii won't benefit from caching either...
Yet all of those things will contend with your active programs for that precious physical memory. If you ever wondered why stuff is slower than normal and doesn't work instantly when you come back to your PC (after leaving it running for a night for example), the reason is that Windows thought it would be a good idea to waste physical memory to improve performance WHEN YOU WEREN'T EVEN THERE! Only to annoy you with sluggish performance when you DO want to do something... Me, I don't care about performance when I'm not at the keyboard... but when I'm back, I expect everything to work the way I left it.
Try the option "No page file". You can set it to 0 as well (or to some other low number), just make sure you set the same value in the min and the max field. I always run Windows with no page file or only a tiny one (16 MB orso) to soothe badly written software (ie, Adobe's trash).
Oh please, since a single process is limited to LESS memory than you can actually stick into a 32-bit system this claim of yours is utter bullshit. Put enough RAM in, kill swap, and there will be no more hitching (once everything is loaded of course).
Slashdot Mirror
Microsoft has clearly put its own and other company's interests ahead in Vista by adding features that do nothing for me as a consumer. I doubt those will be removed in Windows 7, and even suspect they will be worse. That's reason enough for me to not even consider Windows 7.
So, you just need to forge a receipt which are not specifically protected against forgery...
Just swap the tires then, or would I have to show ID when buying new ones?
That's great, I sure hope that all that extra disk access for caching these things doesn't get in the way when I'm accessing the disk for my own reasons. Luckily disks can handle multiple programs accessing it simultaneously without any noticeable slowdown at all (now where's my sarcasm mark?).
On Windows XP:
1) Press Windows+R to bring up run box
2) Type N, O, down, enter
3) Notepad launches
One more key-stroke I'll admit, but who gives a damn, you could hotkey it on XP (go to shortcut, fill in the hotkey with something like CTRL+SHIFT+N)
Your 2nd example, works with the Windows+R too. Again, you can hotkey it.
All of what you describe can also easily be added to XP with 3rd party apps, or by just knowing what XP is capable of already.
I'm no fan of vista, but 32-bit and a "3 GB limit" have nothing to do with each other.
The 3 GB limit you see is usually because your motherboard does not support more than 4 GB of RAM (of which RAM included on graphics cards and used by other PCI devices gets substracted). Since I never ran Vista, I can only assume it is capable of using more than 4 GB of RAM even in 32-bit mode, just like it's predecessor XP and Windows 2003 can (running Windows 2003 here, in 32-bit, with 6 GB of RAM that it can use without problem).
So is the image.
Seriously, just block those proxies. If that means the UK has no access to wikipedia, perhaps that may spark some reforms.
So.. what was the cause of those crashes then? Cause I don't even remember the last time I had a crash with a Java program or JVM.
You mean writing something that already exists? I guess you already missed a big point of why Java is being used then. For such things we just use the existing libraries (which donot necessarily have to be Java based), or more likely, the built-in zip style compression, which may or may not be optimized for your platform depending on where you actually run the code.
You are right there are no pointers in Java. The closest thing are Object references. The big difference between pointers and Object references though are that Object references are a completely separate type that does not derive from a basic type like int or long depending on your platform. This means that certain operations, especially calculations, are simply not allowed as they make no sense (pointers in Java make no sense as there's no address space, which also happens to make Java virtually immune to some security issues like buffer overflow exploits).
Still, object references can be thought of as pointers, but more abstract. You can still do the important stuff with them, like putting them in lists, dereferencing them, double indirect lists, etc.. with the big advantage that everything you can do can be closely and accurately scrutinized by the compiler.
One of the biggest design goals for Java was to eliminate large sources of potential (programming) problems by making it possible for a compiler to make sense out of your code. Java, and perhaps C#, are currently probably the most strict programming languages there are, providing more compile time checks then ever before. It also makes Java very refactorable and is the reason why Java IDE's can provide so much automated refactorings and fixes, with quite a high degree of confidence that these will not affect the intent of the code.
Eclipse is usually quoted as being a big "resource hog", but few people realize really why it is using all those resources. You, like many, probably think it is "wasting" all that memory and is just being an inefficient dog. However, in reality, most of the memory eclipse uses is to make it work faster, and being able to provide you with fast code completion, error analysis as you type, fast searching and compilation. Eclipse will use more memory generally when you have more source files to work with, causing it to have to index more data for almost instant use (code completion especially needs to be fast to be useful). It will also do a lot caching of files for performance reasons.
For smaller projects, containing say 200-300 source files, Eclipse happily runs with 40 MB of RAM, and won't exceed that unless really needed. If you feel it is wasting too much resources, then turn off some of the useful features... you may find that wasting resources for very handy features is not that bad a trade-off.
I don't see any problem at all. Everything that worked on a single core will also work on a multi core system. The language is largely irrelevant, because 99% of the code written is actually not worth optimizing at all. The 1% that might be worth optimizing (something which depends on how much data that needs to be processed) can easily be written multithreaded even in the most mundane of languages... if someone didn't do it for you yet in some kind of library.
Just because functional programming is supposed to work better with multi-cores, doesn't mean you have to write every mundane piece of trash code (ie, code that does nothing worth optimizing) in it. Who cares if some event handler (responding to some user action) could have been written multi-threaded if the total runtime is on the order of microseconds? The bottleneck is often the user, there's no sense in optimizing any of that code and thus no sense in writing it in a specific language either.
Unfortunately, there's no paging algorithm that is smart enough to do this. It would need to be able to predict when I intend to do something before I know I wanted to do it (yes I know Vista is trying to do that.. emphasis on "trying"). It would need to predict that I got home at 3 am on a thursday night, and instead of going straight to bed would realize I wanted to check my mail first (and swap it back in before I click it). It would need to predict that after leaving the machine untouched for a week, I suddenly VNC to it from my holiday to check on my torrents progress. In short, it would need to be able to predict the future.
Until this is possible, the next best thing is to stick enough RAM in and disable swap completely, it is far more optimal than the current algorithm.
It looks like a solid argument, but it really only applies to certain environments.
From a user's perspective, there's only one time when performance matters: When they're at the keyboard.
I don't care if my system runs 0.0001% better when I'm NOT at the keyboard... I don't give a damn what the reasons are that my programs don't work snappy anymore when I get back to the system, when I get back to the system I expect my programs to work as they did before I left it. These days, that is EASILY possible, so why doesn't Windows care about the user experience?
You need to determine if the physical media was a bottleneck or not. When playing media files, the disk is never a bottleneck, and the data is thus not really worth caching in the long term. So, if a program requests data at a pace that is slower than disk I/O, then it should not be long term cached. There's lots of ways you can measure this. You can see if the program actually needs to wait for I/O, you can see if it the smart read-ahead is producing a 100% hit rate, or you can impose some hard coded limit (ie, requests below X MB/sec are not worth caching long term).
This would work pretty well for media playback, but wouldn't do much for copying large directories, or for virus scanners. Virus scanners however could implement a friendly scanning mode, that will keep scan speed below a certain maximum, thus signaling the caching system that only short term caching is really needed.
You won't really notice (*). The disk/file cache still does it's job without swap being active, it just cannot sacrifice program data for file/disk cache anymore -- exactly the way I want it. So, in a 4 GB system, and 2 GB is taken up by programs, there's still 2 GB of space for caching file data. That's likely enough to cache the entire directory structure of everything you have twice over.
(*) assuming you are not pushing close to an out of memory already (I recommend sticking in twice as much RAM as you'd really need to run all of your often used programs at once).
The assumption is pretty bogus though.
When I'm at the computer, I expect good performance. I dislike waiting. When I open a program, and leave it open, I did so because I intend to use it, now, or at some unpredictable time in the future.
When I'm NOT at the computer, and thus not directly using any of my programs, I also don't give a damn about PERFORMANCE.
Yet, when I'm not at the computer, Windows thinks it would be a good idea to swap out programs to make more room for caching files (without a limit I might add, it will happily waste all of my 6 GB of physical memory on this) to increase performance, something that is irrelevant since I'm not there anyway. For this completely useless benefit, it sacrifices everything...
The actual result is that when I get BACK to my computer, I get shitty performance -- right at the moment performance starts to really matter again.
The "fix" for this problem is trivially easy, but unfortunately, not possible in modern versions of Windows: Put a limit on the file/disk cache to prevent it from pushing things to swap (in my 6 GB system, I could tell it to never use more than 2 GB of that space for caching -- and all would be great..). Since that is not an option, I used the next best thing, I turned off swap. File/disk caching still works perfectly, except now it is forced to play within the confines of that 6 GB of memory (and usually there's still like 4+ GB to play with :))
Actually... no.
It can potentially speed up your machine, because, like all caching algorithms, the decision to cache or not cache something is just a best guess.
Also, caching only brings benefits when data is used more than once. This is especially important. So.. for example, copying a large file once will not benefit from caching. Copying an entire disk multiple times (assuming the disk size is greater than your physical memory), will never benefit from caching (ignoring stuff like read-ahead). Scanning your entire disk for virii won't benefit from caching either...
Yet all of those things will contend with your active programs for that precious physical memory. If you ever wondered why stuff is slower than normal and doesn't work instantly when you come back to your PC (after leaving it running for a night for example), the reason is that Windows thought it would be a good idea to waste physical memory to improve performance WHEN YOU WEREN'T EVEN THERE! Only to annoy you with sluggish performance when you DO want to do something... Me, I don't care about performance when I'm not at the keyboard... but when I'm back, I expect everything to work the way I left it.
Try the option "No page file". You can set it to 0 as well (or to some other low number), just make sure you set the same value in the min and the max field. I always run Windows with no page file or only a tiny one (16 MB orso) to soothe badly written software (ie, Adobe's trash).
Oh please, since a single process is limited to LESS memory than you can actually stick into a 32-bit system this claim of yours is utter bullshit. Put enough RAM in, kill swap, and there will be no more hitching (once everything is loaded of course).
Yeah... such a great idea that is... no wonder half the programs crash that I run from a network share when it goes away.
Well, I'm in europe... I don't use my connection a whole lot at night. I offer a 1 MBit/sec VPN service for a modest fee. Any takers?
How about fallback to wifinet, with occasional encrypted bridges over the internet? :)
The camera work is very good? ROFL, it is the reason I stopped watching BSG, because they couldn't keep the bloody camera still.