Server Help

[Mine GO BOOM]

[Cyan~Fire]

OK, fine, I won't talk about implementation because it seems that I am unqualified. (I'm not convinced, though, Java definitely seems slow to me.)

And I won't even mention Windows.

Here's something about the Java language itself which ticks the heck out of me. Why are there no normal unsigned datatypes?
_________________
This help is informational only. No representation is made or warranty given as to its content. User assumes all risk of use. Cyan~Fire assumes no responsibility for any loss or delay resulting from such use.
Wise men STILL seek Him.

[Dr Brain]

[SuSE]

[myke]

i'm not anti java or anything, sure java is slow for me, but this made me laugh quite some time ago

http://bash.org/?338364

[Cyan~Fire]

No real use for them? What if you're reading from a compactly-designed file and have to index an array from a value in that file?

If a language already exists that supports unsigned datatypes, why switch?

Another point: Why no global functions? Why can't I just have a stupid SwapBytes() function that isn't in a class? And if you say it's because Java is "pure-OO", please tell me why "pure-OO" is better than the choice C++ gives its users.

[Dr Brain]

Um, just store the value in a larger storage location. Although, of course, one cannot create arrays that large.

So you're saying because Java supports classes, that no one should ever switch to C? I think your reasoning is flawed there.

Globals were felt to be a bad thing. I think they are too. Making a Util class and then calling Util.SwapBytes() isn't hard. And generally, there is a place to put it that makes more sense (such as the calling class).

Pure-OO encourages better design from the programmers. Coding is only 10% of programming. Design is the other 90%, so I don't think that engouraging a good design is a bad thing.

[SuSE]

limitation is...limiting

[Solo Ace]

What an interesting discussion.

Btw, Brain, don't you have to kill somebody?

[Mr Ekted]

[Cyan~Fire]

[Dr Brain]

[Cyan~Fire]

[Dr Brain]

[Cyan~Fire]

Uhhhh, ok.

[Mine GO BOOM]

[Dr Brain]

Please refrain from making comments without first reading what I said. I said "notice you've never heard of one?" I knew that some had to exist, but thank you for proving my point by showing that there are so few. I only noted two Java VIRUSES. There were plenty of trojans--which I explicitly stated could be written in Java.

Yes, JVM bugs can allow viruses. Note, however, the the JVMs are not witten in Java.

My point in mentioning sandboxes was not to make the point that viruses cannot be written in Java, but rather to make the point that Java programs are far less likely to fall victim to buffer overflows from malformed data (the most common way worms spread). I'm not saying it's not possible to have a worm spread through Java, but I AM saying that Java is orders of magnitude better at eliminating the problem than either C or C++ are.

[Cyan~Fire]

[Bak]

I think he's trying to agure about Java more abstractly, Cyan. The idea that array accesses should check to see if they are out of the declared array's boundries yields to a language less prone to viruses, but of course if your range checking has a bug in it, people can still abuse this weakness.

An ideal VM would translate java bytecode to native instructions flawlessly, but if the VM is poorly written, you shouldn't blame Java for that, as the bytecode is fine (even though Sun might also be providing the buggy VM).

The arguement is basicly is it better to slightly slow everything down and limit programmers by not allowing pointers and checking ranges on arrays, or is it better to put the burden of security on the programmer's shoulders and take advantage of the speed increase by trusting that programs are not made with vulnerabilities that may allow something like a buffer overflow. Programmers make programs with bugs and mistakes, so it would look like Java's sandbox model is superior, but an educated programmer should realize when his or her code is prone to attack, so there may be no need for the overhead and slowdown of the sandbox model.

I suggest an alternative: the operating system should limit what different processes can do. For example, unless the user specifies that a process can spawn new processes, or delete/overwrite files outside of it's own directory, or access the net, it should not be allowed to use the system calls that make these operations possible. That way if someone finds a way to insert remote code and make your process run it, it won't be able to cause any damage unless you've granted your process unlimited capabilities. After all, why would Calculator need to access the net, or write to my Windows directory? Why should PrecisionTime be able to access your browser's history, or create a pop up? Most programs do not need all the privilages they have, and limiting their privilages would limit how many and how much impact viruses have.

[Dr Brain]

Yes, an OS with a sandboxing model would be ideal. You could take the idea and really go far with it.

At some point, programs won't be written in low level languages like C/C++. Just like programs are no longer written in Assembly. Portions are, but no one would ever dream of writing an entire application in assembly. We're moving toward faster and faster compuers, and the easier it is for a programmer to write code that fits the specs, the better. No one cares how fast the program runs as long as it's acceptable.

C is written on the idea that speed is the number one need for a program. Twenty years ago, this may have been the case, but certainly, today it is not so. Reliabilty is now the number one need. I'd rather have a program run a little slower and check for errors than have a program run at lightspeed and blow up in my face.

I DO have issues with Java, but they aren't the same issues as you guys have been talking about.

DISCLAIMER: I am talking about applications. None of what I've said applies at ALL to operating systems or low level code such as hardware drivers.

[Cyan~Fire]

[myke]

speed matters to me, i'm impatient

[Dr Brain]

[Mr Ekted]

If you wish to continue with your blatant lies, start a new thread please.

[Cyan~Fire]

Windows XP is definitely slow, you can't deny that. However, Windows 2000 (which I'm running) is speedy quick: I almost never have to wait for any purely Windows task.

Since it seems our discussion of Java is ended (?), I'll say that although I don't think MS is purposefully making their OSes slow, they're definitely not putting as much effort into them as they used to. (Must be programming in Java or something. )