Well, it really doesn't make any difference what "idle" usage is, because you don't want your power supply to go wacky any time you "max" out your system. You also don't want to run your power supply at peak usage for any extended period of time. Having a higher-rated power supply will actually give you more efficiency than a cheaper one, which translates to a lower electric bill in reality.
Personally speaking, I have a 400W Antec power supply, but I also use it to power a dual Athlon XP system. Not cheap, but not excessive either.
Re:development speed is critical
on
OpenGL 1.5
·
· Score: 3, Informative
Actually, Sun is already sporting a new OpenGL binding for Java, JOGL, which has been available for several weeks now.
One of its key features is that the Java bindings are automatically generated from the C OpenGL bindings, so it's pretty trivial to keep it up to date with the very latest changes Compare this to gl4Java which has really started falling out of date.
One thing I haven't seen anybody mention is that onboard sound tends to be very crappy for recording. My experience has been that anything that goes through the mic input ends up coming through very quietly and sounding like crap. That's probably why there's a separate "mic boost" option in the Windows mixer. Even using that though, it's still too quiet for most sound sources (for example, my acoustic guitar) and even when loud enough, still sounds like crap.
On the other hand, the separate sound cards (the ones I have tried run around $70 and up) all record mic input very well regardless of what they were labelled for (i.e. gaming, playing mp3s, or actual recording). I can get extremely crisp recordings from my guitar, mic ($70 - not a cheapie computer mic), and analog from my synthesizer.
Oh, and off topic, but I'd just like to say that Audacity rocks.
Strange. I would say that I "believe in the Bible", because archaeological and historical evidence bear it out - from fulfilled prophecies, to supernatural events, to plain old facts. Its remarkable insight into human nature could also be considered contributory evidence of its divine nature.
It's naive to believe that people simply decide to throw out all logic and reason when examining the Bible. I believe that you'll find that Christian apologists are usually much more adept in pointing out circular reasoning in their rivals' logic compared to the simple display you've made here.
I was going to say that this is the equivalent to saying, "unless you run as root", but it's even worse than that. In practice, many people do run as root, while nobody ever turns the verifier off on their virtual machine. There is just no advantage.
1. If you can name a single attack that works against the classloader I'd like to see it. Spoofing is a very old suggested research attack, that was immediately fixed by Sun changing the classloader model so that classes are distinguished by the classloader in which they were loaded.
2. Yes, native methods have nothing to do with JVM security related to invalid bytecode.
3. Your point was that somehow crafting bytecode could break the VM security. My point was that that's impossible as the bytecode is verified before it is executed.
4. I honestly don't remember how I came across BCEL - I knew of it, though, back when it was called JavaClass.
If I had mod points, I would mod this down -1 Misinformed.
When the JVM loads a class, it performs a process called verification which ensures that the class file is structurally sound. You can't, for example, push an integer onto the stack, then try to pull it off as an object reference. http://java.sun.com/docs/books/vmspec/2nd-edition/ html/ConstantPool.doc.html#71817
Sure, it's possible to generate a class file with invalid, 'dangerous' byte code by using a Java assembler, but it won't pass the mandatory verification stage of the virtual machine. As an example, I've written a program which dynamically modifies the bytecode of existing Java classes using BCEL (http://jakarta.apache.org/bcel/index.html). When I made mistakes that generated subtlely invalid bytecode, the classes would fail the VM's verification stage and not load. BCEL includes its own verifier (Justice), to help you ensure your generating valid bytecode during development.
This isn't true at all. You can have several different sets of classes all running with different sets of privileges. Java has had this level of flexibility for a long time now.
Lol. I've written both my fair share of Java and C++ on the Microsoft platform (including ActiveX and ADO). And that, my friend, is why I know better - and you apparently don't.
No, I'm sorry, you're the one who is confused. ADO isn't object-oriented in any sense of the word. It is also not vendor-neutral. It also does not make the same level of guarantees that JDO makes. Perhaps if you actually wrote some code using JDO you might begin to understand the differences?
No - about the only thing that JDO and ADO have in commonality is the fact that they are both used to access data in a persistent store.
ADO is Microsoft's implementation of a thin veneer for querying a relational database (for example, in the same space as ODBC).
JDO is an object-oriented, vendor-neutral specification for transparent data persistence. It guarantees important levels of support for transaction management, identity management, and caching.
JDO is particularly interesting, because it achieves optimal dirty-detection and lazy loading as a transparent service - i.e. you don't have to muck with your object model to support it.
Want to know more? Download the free specification or any number of free books on JDO.
If you go to http://www.javagaming.org you can get information about Java game development.
I've been having fun beta-testing AlienFlux - http://www.puppygames.net/ It's a pretty good example of what can be done in Java in a fairly short period of time.
opening a database connection for every visitor on every page is suicide
Rather, just about every serious web application requires database access, and yet they don't commit suicide. It's called connection pooling, and it is a standard feature on pretty much any application server nowadays.
I imagine most Slashdotted sites die from network starvation long before their machines come to a grinding halt.
I think what you are missing is that human beings find categorization intuituve - not the hierarchy especially. A hierarchy is simply just one form of categorization. This becomes immediately obvious once you try to categorize things by multiple attributes. For example, I'd like to categorize my mp3s by author, album, genre, and year. That is a perfectly natural and intuitive desire, but it can't be achieved with a simple hierarchical file system.
Do I need to remind you about the original topic of this thread? Think about your argument in that context.
You clearly just don't get it, or you can't be bothered to discuss this seriously. Let me know if that changes. Until then, you get the Slashdot equivalent of *plonk*
Default Java command-line application policy allows me to read and write files anywhere on your hard drive.
That's like saying that, if I run a program as root on my Linux box, it can destroy all the files on my hard drive. True - yet stupid.
But then, I can just assert my program won't work under those policies.
Again, that's like your program refusing to run unless I run it as root. It's written poorly and I refuse to run it.
As for applets, I can sign them, and if you click "Accept", boom goes the default applet sandbox.
Uhh Huh. I can walk into a bank, and I could sign a contract that says, "All your $ are belong to us". True - yet stupid. Detecting a motif, yet? [Insert cliche concerning idiot-proof devices]
... it doesn't mean that there won't be a backdoor in a distributed program for, say, auto-updating.
Even in the case where a program was written poorly (doesn't use a secure connection to auto-update itself), it still can't do anything more than what I granted it in the first place. Now a new arbitrary piece of code can contact the Folding@Home servers, but not read/write to my disk. No security hole.
I can inject arbitrary bytecode.
I think you're totally missing the point. Injecting arbitrary bytecode is meaningless. I set a limit for the program. It doesn't make any difference whether that code is malicious or not. It still can't circumvent the sandbox. The code can never do anything other than what I allow it to do.
The proof is in the pudding. I can guarantee that you can't read/write to my disk (or just in places that I allow) or that you can't read/write to the network (or just in places that I allow), etc... I'll run any program that you write that you believe can circumvent that security. Willing to bet some money on it?
I don't think you can even begin to draw a comparison between C/C++ and Java in regards to security. The designers of C/C++ never had that aspect in mind, while Java has had fine-grained security for many years.
I know this sounds zealous, but I encourage you to come up with a scenario where I can't secure the execution of a Java program. It's simply inherent in the nature of the language. I'll even go as far as to state that I will run any Java program that you write. You don't have to give me the source code.
Really, it's very cool that I can run anybody's program and not be worried about it wreaking havoc on my system. It makes the Internet a much friendlier place. I wonder when these sort of features will make it into mainstream OSs or other mainstream languages.
Would you change your mind if the program was written in a secure language like Java?
You're guaranteed that the program can't perform any illegal memory operations, and you can set up a security policy for the application that prevents it from doing anything you don't like (i.e. reading/writing to the filesystem, connecting to other machines on your network, etc...)
I developed and maintain a cross-platform C++ project (http://jace.reyelts.com/jace) which has roughly 10,000 lines of code and supports Windows, Linux, Solaris, HP-UX, AIX, and MacOSX.
My experience is that writing any sort of complex C++ code (especially that which involves templates) is nightmarish due to different levels of standards conformance, support, and interpretation - not to mention plain old bugs. For example, Jace has to jump through hoops to get around bugs with virtual inheritance in some compilers, and differences with respect to template specializations and the ODR. Every time I make a change to Jace, I immediately have to rebuild on several platforms, for fear that the compiler I was using was lax and let non-standard code compile or for fear that one of the many other compilers won't correctly compile the code.
I think that if you were to take the time to profile your application, you'd find that the old 90-10 axiom applies. I would suggest that you write that 90% of your application in a highly cross-platform language like Java, and the other 10% in C++. With Java, it's virtually impossible to write code that is rejected/accepted differently on different compilers, and you have access to an excellent cross-platform build tool - http://jakarta.apache.org/ant/index.html (Not that you would need to build on more than one platform). You'll also find that the Java compilers are essentially bug free. A task that is much easier to achieve with Java, considering the language is so much simpler than C++.
No. This is like a homeless person walking up to Burger King and asking for a meal. Burger King responds, 'We'll give you a coupon for 50 cents off when you buy our five dollar combo meal.'
I have to disagree with you there. There are many nuances to the C++ standard library that make using it correctly much tougher than naively expected.
Take a read through Scott Meyer's Effective STL to get a taste of the reasons why even experts have had a hard time using the standard library correctly.
Look at the Boost++ library as an example of using C++ to get levels of numerical performance near to Fortran--which was almost impossible with plain C.
Either you're confused or had a temporary brain-fart. Boost is a library of classes, algorithms, and other features that, in a general consensus, developers feel should be added to the standard C++ library. Blitz++ is a numerical computing library based heavily on C++ template expressions and specialization.
I haven't had a long history with ECS motherboards, but I have to say that I have had very good luck with the two K7VZA's I bought a while back. I run Win2K for weeks on end without crashes.
The review from Tom's Hardware is gushing:
K7VZA came first in almost all the benchmark categories... The design of the ECS board can therefore be described as a clear success.
Of course, what does my personal experience or Tom's benchmarks count for? Surely they're no where near as objective as the article's author.
Slashdot Mirror
Well, it really doesn't make any difference what "idle" usage is, because you don't want your power supply to go wacky any time you "max" out your system. You also don't want to run your power supply at peak usage for any extended period of time. Having a higher-rated power supply will actually give you more efficiency than a cheaper one, which translates to a lower electric bill in reality.
Personally speaking, I have a 400W Antec power supply, but I also use it to power a dual Athlon XP system. Not cheap, but not excessive either.
One of its key features is that the Java bindings are automatically generated from the C OpenGL bindings, so it's pretty trivial to keep it up to date with the very latest changes Compare this to gl4Java which has really started falling out of date.
One thing I haven't seen anybody mention is that onboard sound tends to be very crappy for recording. My experience has been that anything that goes through the mic input ends up coming through very quietly and sounding like crap. That's probably why there's a separate "mic boost" option in the Windows mixer. Even using that though, it's still too quiet for most sound sources (for example, my acoustic guitar) and even when loud enough, still sounds like crap.
On the other hand, the separate sound cards (the ones I have tried run around $70 and up) all record mic input very well regardless of what they were labelled for (i.e. gaming, playing mp3s, or actual recording). I can get extremely crisp recordings from my guitar, mic ($70 - not a cheapie computer mic), and analog from my synthesizer.
Oh, and off topic, but I'd just like to say that Audacity rocks.
Strange. I would say that I "believe in the Bible", because archaeological and historical evidence bear it out - from fulfilled prophecies, to supernatural events, to plain old facts. Its remarkable insight into human nature could also be considered contributory evidence of its divine nature.
It's naive to believe that people simply decide to throw out all logic and reason when examining the Bible. I believe that you'll find that Christian apologists are usually much more adept in pointing out circular reasoning in their rivals' logic compared to the simple display you've made here.
I was going to say that this is the equivalent to saying, "unless you run as root", but it's even worse than that. In practice, many people do run as root, while nobody ever turns the verifier off on their virtual machine. There is just no advantage.
1. If you can name a single attack that works against the classloader I'd like to see it. Spoofing is a very old suggested research attack, that was immediately fixed by Sun changing the classloader model so that classes are distinguished by the classloader in which they were loaded.
2. Yes, native methods have nothing to do with JVM security related to invalid bytecode.
3. Your point was that somehow crafting bytecode could break the VM security. My point was that that's impossible as the bytecode is verified before it is executed.
4. I honestly don't remember how I came across BCEL - I knew of it, though, back when it was called JavaClass.
If I had mod points, I would mod this down -1 Misinformed.
/ html/ConstantPool.doc.html#71817
When the JVM loads a class, it performs a process called verification which ensures that the class file is structurally sound. You can't, for example, push an integer onto the stack, then try to pull it off as an object reference. http://java.sun.com/docs/books/vmspec/2nd-edition
Sure, it's possible to generate a class file with invalid, 'dangerous' byte code by using a Java assembler, but it won't pass the mandatory verification stage of the virtual machine. As an example, I've written a program which dynamically modifies the bytecode of existing Java classes using BCEL (http://jakarta.apache.org/bcel/index.html). When I made mistakes that generated subtlely invalid bytecode, the classes would fail the VM's verification stage and not load. BCEL includes its own verifier (Justice), to help you ensure your generating valid bytecode during development.
This isn't true at all. You can have several different sets of classes all running with different sets of privileges. Java has had this level of flexibility for a long time now.
Lol. I've written both my fair share of Java and C++ on the Microsoft platform (including ActiveX and ADO). And that, my friend, is why I know better - and you apparently don't.
No, I'm sorry, you're the one who is confused. ADO isn't object-oriented in any sense of the word. It is also not vendor-neutral. It also does not make the same level of guarantees that JDO makes. Perhaps if you actually wrote some code using JDO you might begin to understand the differences?
No - about the only thing that JDO and ADO have in commonality is the fact that they are both used to access data in a persistent store.
ADO is Microsoft's implementation of a thin veneer for querying a relational database (for example, in the same space as ODBC).
JDO is an object-oriented, vendor-neutral specification for transparent data persistence. It guarantees important levels of support for transaction management, identity management, and caching.
JDO is particularly interesting, because it achieves optimal dirty-detection and lazy loading as a transparent service - i.e. you don't have to muck with your object model to support it.
Want to know more? Download the free specification or any number of free books on JDO.
If you go to http://www.javagaming.org you can get information about Java game development. I've been having fun beta-testing AlienFlux - http://www.puppygames.net/ It's a pretty good example of what can be done in Java in a fairly short period of time.
I imagine most Slashdotted sites die from network starvation long before their machines come to a grinding halt.
I think what you are missing is that human beings find categorization intuituve - not the hierarchy especially. A hierarchy is simply just one form of categorization. This becomes immediately obvious once you try to categorize things by multiple attributes. For example, I'd like to categorize my mp3s by author, album, genre, and year. That is a perfectly natural and intuitive desire, but it can't be achieved with a simple hierarchical file system.
Do I need to remind you about the original topic of this thread? Think about your argument in that context.
You clearly just don't get it, or you can't be bothered to discuss this seriously. Let me know if that changes. Until then, you get the Slashdot equivalent of *plonk*
Huh? I think you're the one who's kidding.
Default Java command-line application policy allows me to read and write files anywhere on your hard drive.That's like saying that, if I run a program as root on my Linux box, it can destroy all the files on my hard drive. True - yet stupid.
But then, I can just assert my program won't work under those policies.Again, that's like your program refusing to run unless I run it as root. It's written poorly and I refuse to run it.
As for applets, I can sign them, and if you click "Accept", boom goes the default applet sandbox.Uhh Huh. I can walk into a bank, and I could sign a contract that says, "All your $ are belong to us". True - yet stupid. Detecting a motif, yet? [Insert cliche concerning idiot-proof devices]
Even in the case where a program was written poorly (doesn't use a secure connection to auto-update itself), it still can't do anything more than what I granted it in the first place. Now a new arbitrary piece of code can contact the Folding@Home servers, but not read/write to my disk. No security hole.
I can inject arbitrary bytecode.I think you're totally missing the point. Injecting arbitrary bytecode is meaningless. I set a limit for the program. It doesn't make any difference whether that code is malicious or not. It still can't circumvent the sandbox. The code can never do anything other than what I allow it to do.
The proof is in the pudding. I can guarantee that you can't read/write to my disk (or just in places that I allow) or that you can't read/write to the network (or just in places that I allow), etc... I'll run any program that you write that you believe can circumvent that security. Willing to bet some money on it?
I don't think you can even begin to draw a comparison between C/C++ and Java in regards to security. The designers of C/C++ never had that aspect in mind, while Java has had fine-grained security for many years.
I know this sounds zealous, but I encourage you to come up with a scenario where I can't secure the execution of a Java program. It's simply inherent in the nature of the language. I'll even go as far as to state that I will run any Java program that you write. You don't have to give me the source code.
Really, it's very cool that I can run anybody's program and not be worried about it wreaking havoc on my system. It makes the Internet a much friendlier place. I wonder when these sort of features will make it into mainstream OSs or other mainstream languages.
Would you change your mind if the program was written in a secure language like Java?
You're guaranteed that the program can't perform any illegal memory operations, and you can set up a security policy for the application that prevents it from doing anything you don't like (i.e. reading/writing to the filesystem, connecting to other machines on your network, etc...)
I developed and maintain a cross-platform C++ project (http://jace.reyelts.com/jace) which has roughly 10,000 lines of code and supports Windows, Linux, Solaris, HP-UX, AIX, and MacOSX.
My experience is that writing any sort of complex C++ code (especially that which involves templates) is nightmarish due to different levels of standards conformance, support, and interpretation - not to mention plain old bugs. For example, Jace has to jump through hoops to get around bugs with virtual inheritance in some compilers, and differences with respect to template specializations and the ODR. Every time I make a change to Jace, I immediately have to rebuild on several platforms, for fear that the compiler I was using was lax and let non-standard code compile or for fear that one of the many other compilers won't correctly compile the code.
I think that if you were to take the time to profile your application, you'd find that the old 90-10 axiom applies. I would suggest that you write that 90% of your application in a highly cross-platform language like Java, and the other 10% in C++. With Java, it's virtually impossible to write code that is rejected/accepted differently on different compilers, and you have access to an excellent cross-platform build tool - http://jakarta.apache.org/ant/index.html (Not that you would need to build on more than one platform). You'll also find that the Java compilers are essentially bug free. A task that is much easier to achieve with Java, considering the language is so much simpler than C++.
No. This is like a homeless person walking up to Burger King and asking for a meal. Burger King responds, 'We'll give you a coupon for 50 cents off when you buy our five dollar combo meal.'
Its not as tho these products mentioned (anything by nintendo, Levi, Microsoft etc) have anything to do with practical and normal living needs?!?!
Yep. All I need is my birthday suit for my normal living needs.Didn't they teach this in grade school?
Your proof is wrong because you're dividing by zero - disguised as (a - a).
I have to disagree with you there. There are many nuances to the C++ standard library that make using it correctly much tougher than naively expected. Take a read through Scott Meyer's Effective STL to get a taste of the reasons why even experts have had a hard time using the standard library correctly.
Look at the Boost++ library as an example of using C++ to get levels of numerical performance near to Fortran--which was almost impossible with plain C.
Either you're confused or had a temporary brain-fart. Boost is a library of classes, algorithms, and other features that, in a general consensus, developers feel should be added to the standard C++ library. Blitz++ is a numerical computing library based heavily on C++ template expressions and specialization.
I haven't had a long history with ECS motherboards, but I have to say that I have had very good luck with the two K7VZA's I bought a while back. I run Win2K for weeks on end without crashes.
The review from Tom's Hardware is gushing:
K7VZA came first in almost all the benchmark categories... The design of the ECS board can therefore be described as a clear success.
Of course, what does my personal experience or Tom's benchmarks count for? Surely they're no where near as objective as the article's author.
God bless,
-Toby Reyelts