I'm not against putting an analogic processor inside computers (better yet, a network of them). It has lots of usefull applications, but aren't the silver bullet your post implied.
To be fair, at volatile memory, unless you have multi-threading and want non-blocking semantics (as if anybody actualy did that), it makes no difference.
Well, I have some personal experience watching why Java (or C#) is the choosen language for corporate projects out there. They are choosen because they are at the media, but not only that, they are choosen because managers exchange experiences, and conclude that Java has a bigger success rate. I conjecture that this bigger success rate is due to its simplicity, since more complex* languages behave badly when you add incompetent programmers into the mix.
Now, nearly all corporate programs are a mess, Java or otherwise. You can't compare code written by well selected people to the one created inside big management hierarchies, where the low managers (that can see who is competent and who isn't) has little saying on who'll be working with them.
* By more complex, I mean, the languages that give you more different ilegible ways to implement a functionality. But that is hard to measure, so, as a proxy I use the number of different ways to implement the functionality, without caring about legibility.
That looks like an explicit win for freedom of initiative and progress. Looks like a win for open source too, but as a consequence of that freedom of initiative part.
From all the comments about Vista, it seems that either the prefetcher cache isn't volatile or MS has lied to a bunch of people, telling them that an overall problem of Vista was local to it.
Now, to answer you, Linux allocate all unused memory as file cache, even if not used. There is a compiling time switch that turns that off, but the default is to agressively cache (just like every other usable *nix out there).
Well, if it were documented, those wouldn't be undocumented APIs. Now, to anwer you, you should follow the EU anti-trust process against MS closer, they found quite a few undocumented APIs used by both Office and IE. By the way, try keeping another window at first plane while IE loads a page ans see what happens, there were no ducumented API for that behaviour until the EU found it.
"railing slashes may be redundent, but on Windows they ensure the filename is treated as a folder."
They have the same meaning on Linux, but most commands are able to see that it is a directory. After you solve that problem, try having some fun with 'mv', that is one command where you need to specify if you want to treat a dir like a dir or a regular file sometimes.
There is a difference between running code that some random computer said "that is an application, run it" and oppening your PDF viewer when some random computer says "that is a PDF, open it". IE does both, on Linux, browsers can't do the later. Also, oppening an image or a PDF is risky on Windows, but there is nothing IE can do about that.
Anyway, you are right that, if 'file' doesn't recognize your MIME type, you'll have to do some work. Windows is easier here.
Oh, that should work. You are doing something wrong (like writting a lowercase x).
1) Well, that makes little sense. Do you want the menu to be organized by app name? If so, you are alone. (Too bad you are using Gnome, KDE has an option for that - and for everything else). Anyway, if you just want to discover the name of a app, you can look at the menu editor.
2) Ubuntu comes with one such app installed. I guess it is called gsudo.
4) Put them at your.bashrc if you open the real terminal, or.bash_profile if you use the emulated one (both stay at your homedir, where you can go by typing 'cd $HOME'). Better yet, write a.bashrc and then, at your home type 'ln -s.bashrc.bash_profile'. That will make a link, so both files are the same. Also, don't forget the dots.
6) Good, that is important stuff. Also, read about hard links. 'man ln' may help more than a google search.
8) That delay is not because of identifying file types. It is for displaying miniatures. I don't know if Gnome will let you turn those off (KDE hs an option for that, of course), but most people start to like it after a while.
9) The GP wasn't saying that you don't understand the security system. He was saying that you don't understand the reason why those restrictions are turned on. On most desktop installs you'll probably want to turn some of them off, so you'll get a more usable system, but each install needs a different set, so you'll need to check the impact of each one of them. Also, if you want executables to write on the dir they are, you'll probably want to put them at your home.
"Do portable progs on your fav linux distro do the same?"
Yes. Portable apps are modified versions that write where the executable is located, the definition holds for every OS (but I never saw one for Linux).
"That is, they write their configuration files to/bin or/usr/bin or/usr/local/bin or whatever."
No, they try to write where the executable is, what is never/bin/usr/bin or/usr/local/bin. If you wanted your app to be on any of such places, you'd get the original version. Portable apps you use on your pen driver, or on computers where you can't install things.
Well, CAD software also benefits from paralelization, as do games, and scientific simulations, or economical ones (to the currently desperate). Drawing software doesn't benefit too much (or at least, I think it doesn't), but painting sotware does. Developpers should also benefit, but compiling is already fast enough, so more than 2 cores is overkill for most of them.
My point is, there is no "average" user. Some people need CPU, and most of those will benefit from massive paralelization. Other people don't need, and those won't benefit from neither paralelization nor faster cores. The latter will like cheap less power hungry chips, tough.
The problems with hyperthreading are that it was designed before its time, so Intel couldn't replicate some essential parts of the core, and that out-of-order execution can't solve all the problems.
I'm glad you can plug your SIP phone behind a NAT without messing with network configurations. Up to now, nobody else was able to do that. Maybe you should patent its workings and get some good money at the market.
First, the Java specification makes allocating objects on the heap mantatory, not optional. That isn't explicit, but comes from the specifications of variable scope and the == operator.
Now, Java programers that don't understand memory management are unable to understand several important details of the language. Eg. they can't comprehend the difference between equals() and ==, altought most learned to not ever use ==, they don't dare overloading equals() or putting custom classes at a hash. (But I disgress, people that don't understand memory management also don't understand where to use hashes.) Also, they can't understand the difference between = and clone(), and most of the time decides to use the latter by trial and error.
It is true, for any feature that you think of. Lisp is made in a way that makes it so. But of course, every programmer uses that feature by a different syntax.
If you tought C++ or Perl had too many paths to solve a problem, you won't be at bed with Lisp's infinite ways.
"Java basically amounts to a really clean API over C++"
Well, if you are used to writing assembly for RISCs, that is completely out of your experiency... But that is a severe understating. Java is a severely restricted subset of C++, with an (bad) API that makes a few things easier.
Java isn't successfull because of its API (if that was the case, Trolltech would have probably take over the world). When deciding what language to use on a big project, managers' main concern isn't what language does already implement those few functions that everybody uses, they ask what language historicaly leads to a bigger rate of success on that kind of project. Now, all the restritiveness of Java show its power here; since it is very hard to completely mess a Java project, it compensates for deficiencies on hiring and evaluating people, building well structured teams, and solving conflicts, leading to a bigger success rate than C++.
Of course, none of the above applies to hard core engineering tasks, since those management flaws are rarer and teams smaler.
While you can pretend something at the C/C++ stack, at Java or C# you'll be forced to use the heap. If you don't understand how the heap works, you'll never understand what your code is really doing.
And, yes, the heap will be completely hidden from you. But that only makes it harder to learn and understand it, not less important.
Slashdot Mirror
In my experience, all that windows witchery* one needs at Windows goes away when you get the options of keeping a window above or behind the others.
* Cascading them, displaying side by side, etc
I'm not against putting an analogic processor inside computers (better yet, a network of them). It has lots of usefull applications, but aren't the silver bullet your post implied.
Of course, the truth mus be somewhere on the middle :)
To be fair, at volatile memory, unless you have multi-threading and want non-blocking semantics (as if anybody actualy did that), it makes no difference.
Well, I have some personal experience watching why Java (or C#) is the choosen language for corporate projects out there. They are choosen because they are at the media, but not only that, they are choosen because managers exchange experiences, and conclude that Java has a bigger success rate. I conjecture that this bigger success rate is due to its simplicity, since more complex* languages behave badly when you add incompetent programmers into the mix.
Now, nearly all corporate programs are a mess, Java or otherwise. You can't compare code written by well selected people to the one created inside big management hierarchies, where the low managers (that can see who is competent and who isn't) has little saying on who'll be working with them.
* By more complex, I mean, the languages that give you more different ilegible ways to implement a functionality. But that is hard to measure, so, as a proxy I use the number of different ways to implement the functionality, without caring about legibility.
That looks like an explicit win for freedom of initiative and progress. Looks like a win for open source too, but as a consequence of that freedom of initiative part.
From all the comments about Vista, it seems that either the prefetcher cache isn't volatile or MS has lied to a bunch of people, telling them that an overall problem of Vista was local to it.
Now, to answer you, Linux allocate all unused memory as file cache, even if not used. There is a compiling time switch that turns that off, but the default is to agressively cache (just like every other usable *nix out there).
Well, if it were documented, those wouldn't be undocumented APIs. Now, to anwer you, you should follow the EU anti-trust process against MS closer, they found quite a few undocumented APIs used by both Office and IE. By the way, try keeping another window at first plane while IE loads a page ans see what happens, there were no ducumented API for that behaviour until the EU found it.
They have the same meaning on Linux, but most commands are able to see that it is a directory. After you solve that problem, try having some fun with 'mv', that is one command where you need to specify if you want to treat a dir like a dir or a regular file sometimes.
There is a difference between running code that some random computer said "that is an application, run it" and oppening your PDF viewer when some random computer says "that is a PDF, open it". IE does both, on Linux, browsers can't do the later. Also, oppening an image or a PDF is risky on Windows, but there is nothing IE can do about that.
Anyway, you are right that, if 'file' doesn't recognize your MIME type, you'll have to do some work. Windows is easier here.
The one consistent syntax across all functions lacks optimization for any specific task.
Oh, that should work. You are doing something wrong (like writting a lowercase x).
1) Well, that makes little sense. Do you want the menu to be organized by app name? If so, you are alone. (Too bad you are using Gnome, KDE has an option for that - and for everything else). Anyway, if you just want to discover the name of a app, you can look at the menu editor.
2) Ubuntu comes with one such app installed. I guess it is called gsudo.
4) Put them at your .bashrc if you open the real terminal, or .bash_profile if you use the emulated one (both stay at your homedir, where you can go by typing 'cd $HOME'). Better yet, write a .bashrc and then, at your home type 'ln -s .bashrc .bash_profile'. That will make a link, so both files are the same. Also, don't forget the dots.
6) Good, that is important stuff. Also, read about hard links. 'man ln' may help more than a google search.
8) That delay is not because of identifying file types. It is for displaying miniatures. I don't know if Gnome will let you turn those off (KDE hs an option for that, of course), but most people start to like it after a while.
9) The GP wasn't saying that you don't understand the security system. He was saying that you don't understand the reason why those restrictions are turned on. On most desktop installs you'll probably want to turn some of them off, so you'll get a more usable system, but each install needs a different set, so you'll need to check the impact of each one of them. Also, if you want executables to write on the dir they are, you'll probably want to put them at your home.
Yes. Portable apps are modified versions that write where the executable is located, the definition holds for every OS (but I never saw one for Linux).
No, they try to write where the executable is, what is never /bin /usr/bin or /usr/local/bin. If you wanted your app to be on any of such places, you'd get the original version. Portable apps you use on your pen driver, or on computers where you can't install things.
Well, CAD software also benefits from paralelization, as do games, and scientific simulations, or economical ones (to the currently desperate). Drawing software doesn't benefit too much (or at least, I think it doesn't), but painting sotware does. Developpers should also benefit, but compiling is already fast enough, so more than 2 cores is overkill for most of them.
My point is, there is no "average" user. Some people need CPU, and most of those will benefit from massive paralelization. Other people don't need, and those won't benefit from neither paralelization nor faster cores. The latter will like cheap less power hungry chips, tough.
The problems with hyperthreading are that it was designed before its time, so Intel couldn't replicate some essential parts of the core, and that out-of-order execution can't solve all the problems.
Well, exactly except for the noise inserted during operations, and in real time if the cutt-off frequencies of your cirtuit are big enough.
Exact results and fast calculations were the sellers of digital computers when analog ones were common.
We already have that, it is called scheduler. Try inserting a bug there.
I'm glad you can plug your SIP phone behind a NAT without messing with network configurations. Up to now, nobody else was able to do that. Maybe you should patent its workings and get some good money at the market.
First, the Java specification makes allocating objects on the heap mantatory, not optional. That isn't explicit, but comes from the specifications of variable scope and the == operator.
Now, Java programers that don't understand memory management are unable to understand several important details of the language. Eg. they can't comprehend the difference between equals() and ==, altought most learned to not ever use ==, they don't dare overloading equals() or putting custom classes at a hash. (But I disgress, people that don't understand memory management also don't understand where to use hashes.) Also, they can't understand the difference between = and clone(), and most of the time decides to use the latter by trial and error.
Well, not everybody. Just corporate developpers.
But I guess most CTOs have not heard about Ada.
That isn't entirely on topic... But you surely are missing the big picture here, and ignoring the reality of who is using who.
Just to be short, Microsoft and Apple have everything to gain here, while RIAA people are a bunch of fools.
It is true, for any feature that you think of. Lisp is made in a way that makes it so. But of course, every programmer uses that feature by a different syntax.
If you tought C++ or Perl had too many paths to solve a problem, you won't be at bed with Lisp's infinite ways.
That's maybe news for some people, but the law of big numbers only work for numbers that are big.
Well, if you are used to writing assembly for RISCs, that is completely out of your experiency... But that is a severe understating. Java is a severely restricted subset of C++, with an (bad) API that makes a few things easier.
Java isn't successfull because of its API (if that was the case, Trolltech would have probably take over the world). When deciding what language to use on a big project, managers' main concern isn't what language does already implement those few functions that everybody uses, they ask what language historicaly leads to a bigger rate of success on that kind of project. Now, all the restritiveness of Java show its power here; since it is very hard to completely mess a Java project, it compensates for deficiencies on hiring and evaluating people, building well structured teams, and solving conflicts, leading to a bigger success rate than C++.
Of course, none of the above applies to hard core engineering tasks, since those management flaws are rarer and teams smaler.
While you can pretend something at the C/C++ stack, at Java or C# you'll be forced to use the heap. If you don't understand how the heap works, you'll never understand what your code is really doing.
And, yes, the heap will be completely hidden from you. But that only makes it harder to learn and understand it, not less important.