Because the most of USB joypad and the generic driver emits an event when any button is pressed, there is no way to know which channel is set when the application is launched.
It should be fixable. Otherwise, the main reason for using a knob, a visible way of seeing which option is chosen, dissapears.
Mozilla won't follow GNOME guideliness, because then it won't be right on Windows or OS X
It certainly doesn't look good on OS X either. If it did, I'd be running it instead of Safari.
For example, Microsoft makes excellent Macintosh software
Well, that is certainly true for Office, which most people (Windows users included) is better on Mac than Windows. But The horrible abomination called MSN Messenger for Mac is not a good OS X application. For example, it doesn't support any scripting.
I don't believe you... Assuming the 300 baus speed of the C64 floppy drive (when in doubt about what hardwar someone is usaing, always assume C64) and the typical amount of data that neads to be read during the Linux boot (when in doubt about the OS, always assume Linux) it would take about 16 days to boot your system.
I know some cities Internet connections are subsidised, but Bredbandsbolaget is one of the biggest (if not the biggest) ISP in sweden and are a privately-held company.
Do you really want one under your desk? Looking at the specs gives the sound level at "5.0 bels", which is 50 decibel. Not a pleasant work environment.
In the end, why put this thing under your desk? Just leave it in the server room and enjoy the quiet.
Who modded this informative? WHoever did obviously doesn't know much about UNIX.
The TERM environment variable is used to tell the applications which emulation your terminal is using so they can send the correct escapte sequences. Changing it will make the apps send different codes which will mess up program you start.
Re:PRECISELY MOD UP+
on
The Power of X
·
· Score: 3, Informative
"Internationalisation" is spelled exactly like so... In all english-speaking countries except the US.
I heard about this new technique before. Apparently it works trmendously well.
The idea is that the mail server keeps a whitelist of "allowed" addresses which are always accepted. If a mail comes from an address which is not known, the mail server will reply with a "server unavailable, try later" error message. All real mail servers will try to send the message a little later (I don't know the exact time, but it's probably less than an hour. Someone else might know better).
The second time the remote mail server tries to connect, the server accepts the mail and adds the address to the whitelist.
However, mass mailers for spam don't do this but simply go on to the next address in the list if this happens. This way the spam message is filtered out.
Note that this method doesn't require any analysis of the actual content of the messgae, nor does it involve any manual actions from neither the sender nor the receiever. Currently it's porbably the best spam blocking method that exists.
We use Hsql, and it is indeed turly a good database. The greatest trength lies it its speed. It's incredibly fast as long as the database is small enough (so that it holds everything in ram).
The biggest problem we have had with it is that the only transaction level it supports in READ_UNCOMITTED, and that it doesn't support multiple parallel queries.
I don't think I'm the person with a poor grasp of the english language.
I say one thing, and you answer with somehting completely different.
All I will do now is to clarify a few things. Then go back with a blank mind and read what I said.
Checked exceptions are (should be) used when there is no way you can programatically about the exceptional situation from occurring. Wether you can fake yourself out of having to catch it is irrelevant. The exeption still occurs.
And for the umptenth time: I have never said it's a good thing to continue in an untested state! Read what I said again. I never ever even hinted this.
Sigh... Let me try to show you a code example:
BufferedReader in =...; String name = in.readLine();// can throw IOException in.close();
return name;
In a language such as C#, which doesn't have checked exceptions this code would compile and run quite happily, right? However, if the file happens to be missing, or you don' thave permission to it the exception will ripple up right to the top level Thread.run(). What Thread.run() does if it throws an exception is to kill the thread!. This is not good, and it might be a very long time until the error condition occurs.
Now... The Java compiler will not compile this. So you need to do something about it. Doing so will mean you make an active choice at what to do. Either you do something like this:
try { // the same code as above } catch(IOException e) { return "(name not found)"; }
Then you have make an active choice that in case of an IOException you return the string "(name not found)". This may be very good. Depends on the situation, and only the programmer knows this.
Another possible candidate is this:
try { // again, the same code } catch(IOException e) { logger.log(Level.SEVERE, "File missing, can't do anything. Terminating application.", e); System.exit(1); }
In this case, the developer made the active choice to terminate the application. Might also be a very good idea, depending on situation.
Note how in no case am I continuing to run untested code like you say. This only happens if the developer is a stupid moron who uses empty catch blocks, but I have said on repeated occations that those programmers should be doing any programming anyway.
This is the last I have to say on this, because if you still don't understand I can't explain it to you.
Re:v6 could help solve some net problems
on
IPv6 is Here
·
· Score: 1
No. There are different protocols for that. (I donät know the lames of them off hand, but it's certainly not DHCP nor BOOTP. that much I remember from the training course:-) )
Re:v6 could help solve some net problems
on
IPv6 is Here
·
· Score: 1
There is no need for such things as BOOTP or DHCP when using IPv6. The MAC address is embedded in the IP-address.
I'm terribly sorry to have to say this (I have been trying to keep this discussion civilised). But you can't possibly have written much Java code if you believe that you are supposed to have a "generic" way to handle the checked exceptions. The point of checked exceptions is exactly the opposite. The idea is that every time you make a call which may throw an exception even though you've done everything else right (that's the difference between a checked exception and an unchecked exception (i.e. RuntimeException)) you must sit down , take a deep breah, and consider what you should do in case this happens. SHould the system crash? Fine, crash the system. Should it try again? Fine, try again. Should it kill the currently logged in user? Again, fine, do that. Never ever should to defer execution to some generic exception handler and then keep running. Anyone even considering that should be fired.
My point is not about unexpected exceptions. Those are declared as RuntimeException in Java anyway and you don't have to explicitly catch them.
The exceptions you do have to catch, however, are the ones that can occur even in a perfectly working program. There is no way you can program your way around the fact that you can get an IOException, that's why it's declared as a checked exception.
If IOException was not checked, then the simple case of a missing file, or a broken network connection would be considered "unexpected" and cause the entire app to crash (of you're lucky). Such a problem will probably not be discovered until much later, and probably by a customer. The fact that Java forces you to make an active choice on what to do is good.
Remember, no one forces you to actually deal with the exception. In some cases it's not even desirable. No one prevents you from wrapping the exception, or declaring it in the throws clause of your method. The point here is that the exceptions are part of the API not just somehting that happens. This is a very good thing.
Oh, and another thing (I already mentioned this in an earlier post of mine). There are cases where certain methods are declared to throw checked exceptions even if they shouldn't, simply because it implements an interface which declares that exception. A good example is StringWriter.write(). We know this method will never throw an exception so you can safely ignore it. A good way is to write it is to wrap it in a
Still, I feel that the advantages outweigh the occasional annoyance. Like I said earlier: Just because it's boring to deal with exceptions is no reason to to let them propagate.
Where did you get impression I was talking about runtime behaviour here? Maybe you are unaware that an unchecked exception in Java is called a runtime exception?
The real advantage lies in that the developer is forced to deal with his exception instead of just letting them ripple up. You do know what happens in java if a runtime exception (i.e. an unchecked exception) is allowed to ripple all the way up to Thread.run()? Exactly, it terminates the thread. A thread suddenly dying in a complex multi-threaded server is not a good thing.
Besides, I think we both agree that people who creates an empty catch should be fired right there and then. But a language can never completely protect itself from idiot programmers. At least when he creates that empty catch, he makes the cocious descision to be an idiot. In these cases he probably should just let a higher level method call deal with it.
No. You're wrong. You're wrong to the point I wonder if you ever wrote good Java code in your life.
With no checked exceptions: The thread will die and it is not entrely unlikely that the entire server will die.
With checked exceptions: the developer will be forced to deal with th eprogram when he writes the code. In this case, he can choose himself what do when the file isn't found (accept or deny the login request). He can, of course, also kill the server in this case.
But if they are not caught, then the stupid developer (note: almost all developers are stupid, we all know this) will not catch it. He will ignore a FileNotFoundException for example, the exception will propagate up, get printed on stdout (which the users never see) and the whole damn thread will die.
This may be good for your average VB-type desktop app, but for a multi threaded backend server this is a disaster. Such things simply should never be allowed to occur.
The special thing about the checked exceptions are that they can be thrown even from perfectly bug-free apps. No amount of coding can protect you from the odd IOException when your TCP connection is broken for example. Java does a tremendous job of helping the developer deal with this. It does this, just like a previous poster said, in a way that is similar to static types.
Static types are good, right? Helps us find bugs at the cost of a bit more code and more redundancy. The similarities to checked exceptions are quite obvious.
While I can agree that I have seen Java developers doing C# lately, I have also see the reverse happening. I don' thave any numbers but "extremely fast pace"?
Du you thing the average mom cares about the fact that her windows machine has "Pentium inside"?
It's called brand awareness. The point here is to make sure that people (and in the case of mobile phones, young people) equate "Java" with "cool games" and an "i need it" attitude. In the end this will (hopefully) mean that in order to be able to sell a phone, you need to support Java. In turn, this means that MS will have a that much harder time trying to get everyone to use the mobile version of.NET.
In fact, here in europe we see this happening already. Every new phone that comes out has J2ME support, and when a phone doesn't have it is reviewed, it's always mentioned as a big minus point.
I suppose (hope) we'll see the same thing happen in the US.
By the way, didn't the latest MS "smartphones" have J2ME support these days?
Since the US has started with even more weird travel restrictions, and a bazillion weird questions that has to be answered when entering their country, why doesn't other countries do the same?
I propse a new quiz to be taken by all US citizens entering another country:
Say the word "Hello" in our language
Say the word "thank you" in our language
Show us the proper to greet somebody
Seriously. Even withou this quiz, learning these takes a few minutes, and it opens up a complete new world.
I cannot stress this enough: Learn these things. Just imagine what would happen if someone came to you, gave you a headbutt and yelled "Hey! Bitch!" to you. Seriously, what is considered a friendly greeting in one country, might not be in a different one.
Disclaimer: I'm not suggesting any country or culture uses the expression "Hey! Bitch!" as a greeting.
Compare this to other platforms, like OS/2 and SCO
on
Unix To Beef Up Longhorn
·
· Score: 2, Interesting
I see this as a good thing. It is my firm belief that OS/2 started to die the day they started to announce that they could run Windows software. SCO also announced they could run Linux software and then they weren't interesting anymore.
Why? Well, First of all, IBM's move meant that customers were taking Windows more seriously. But, why run OS/2 if you can run Windows? I think the same this is about to happen here. This move my Microsoft is going to cause customers to really take Linux seriously, I mean, why else would you want a Linux emulation layer if Linux isn't a serious OS?
Once that happens, the customers are going to wonder why they even bother running Windows in the first place. Hell, with Linux I can run the application native, AND it's cheaper!
This is just one of the indications we're getting that Microsoft is getting desperate. This will get interesting.
Slashdot Mirror
I literally spent several minutes trying to decode it before deciding you just pressed random keys on the keyboard. :-)
How? Considering the fact that the C64 only had 64 kB of RAM.
I don't believe you... Assuming the 300 baus speed of the C64 floppy drive (when in doubt about what hardwar someone is usaing, always assume C64) and the typical amount of data that neads to be read during the Linux boot (when in doubt about the OS, always assume Linux) it would take about 16 days to boot your system.
I know some cities Internet connections are subsidised, but Bredbandsbolaget is one of the biggest (if not the biggest) ISP in sweden and are a privately-held company.
In the end, why put this thing under your desk? Just leave it in the server room and enjoy the quiet.
The TERM environment variable is used to tell the applications which emulation your terminal is using so they can send the correct escapte sequences. Changing it will make the apps send different codes which will mess up program you start.
"Internationalisation" is spelled exactly like so... In all english-speaking countries except the US.
The idea is that the mail server keeps a whitelist of "allowed" addresses which are always accepted. If a mail comes from an address which is not known, the mail server will reply with a "server unavailable, try later" error message. All real mail servers will try to send the message a little later (I don't know the exact time, but it's probably less than an hour. Someone else might know better).
The second time the remote mail server tries to connect, the server accepts the mail and adds the address to the whitelist.
However, mass mailers for spam don't do this but simply go on to the next address in the list if this happens. This way the spam message is filtered out.
Note that this method doesn't require any analysis of the actual content of the messgae, nor does it involve any manual actions from neither the sender nor the receiever. Currently it's porbably the best spam blocking method that exists.
The biggest problem we have had with it is that the only transaction level it supports in READ_UNCOMITTED, and that it doesn't support multiple parallel queries.
I say one thing, and you answer with somehting completely different.
All I will do now is to clarify a few things. Then go back with a blank mind and read what I said.
Checked exceptions are (should be) used when there is no way you can programatically about the exceptional situation from occurring. Wether you can fake yourself out of having to catch it is irrelevant. The exeption still occurs.
And for the umptenth time: I have never said it's a good thing to continue in an untested state! Read what I said again. I never ever even hinted this.
Sigh... Let me try to show you a code example:
In a language such as C#, which doesn't have checked exceptions this code would compile and run quite happily, right? However, if the file happens to be missing, or you don' thave permission to it the exception will ripple up right to the top level Thread.run(). What Thread.run() does if it throws an exception is to kill the thread!. This is not good, and it might be a very long time until the error condition occurs.Now... The Java compiler will not compile this. So you need to do something about it. Doing so will mean you make an active choice at what to do. Either you do something like this:
Then you have make an active choice that in case of an IOException you return the string "(name not found)". This may be very good. Depends on the situation, and only the programmer knows this.Another possible candidate is this:
In this case, the developer made the active choice to terminate the application. Might also be a very good idea, depending on situation.Note how in no case am I continuing to run untested code like you say. This only happens if the developer is a stupid moron who uses empty catch blocks, but I have said on repeated occations that those programmers should be doing any programming anyway.
This is the last I have to say on this, because if you still don't understand I can't explain it to you.
No. There are different protocols for that. (I donät know the lames of them off hand, but it's certainly not DHCP nor BOOTP. that much I remember from the training course :-) )
There is no need for such things as BOOTP or DHCP when using IPv6. The MAC address is embedded in the IP-address.
My point is not about unexpected exceptions. Those are declared as RuntimeException in Java anyway and you don't have to explicitly catch them.
The exceptions you do have to catch, however, are the ones that can occur even in a perfectly working program. There is no way you can program your way around the fact that you can get an IOException, that's why it's declared as a checked exception.
If IOException was not checked, then the simple case of a missing file, or a broken network connection would be considered "unexpected" and cause the entire app to crash (of you're lucky). Such a problem will probably not be discovered until much later, and probably by a customer. The fact that Java forces you to make an active choice on what to do is good.
Remember, no one forces you to actually deal with the exception. In some cases it's not even desirable. No one prevents you from wrapping the exception, or declaring it in the throws clause of your method. The point here is that the exceptions are part of the API not just somehting that happens. This is a very good thing.
Oh, and another thing (I already mentioned this in an earlier post of mine). There are cases where certain methods are declared to throw checked exceptions even if they shouldn't, simply because it implements an interface which declares that exception. A good example is StringWriter.write(). We know this method will never throw an exception so you can safely ignore it. A good way is to write it is to wrap it in a
Still, I feel that the advantages outweigh the occasional annoyance. Like I said earlier: Just because it's boring to deal with exceptions is no reason to to let them propagate.The real advantage lies in that the developer is forced to deal with his exception instead of just letting them ripple up. You do know what happens in java if a runtime exception (i.e. an unchecked exception) is allowed to ripple all the way up to Thread.run()? Exactly, it terminates the thread. A thread suddenly dying in a complex multi-threaded server is not a good thing.
Besides, I think we both agree that people who creates an empty catch should be fired right there and then. But a language can never completely protect itself from idiot programmers. At least when he creates that empty catch, he makes the cocious descision to be an idiot. In these cases he probably should just let a higher level method call deal with it.
With no checked exceptions: The thread will die and it is not entrely unlikely that the entire server will die.
With checked exceptions: the developer will be forced to deal with th eprogram when he writes the code. In this case, he can choose himself what do when the file isn't found (accept or deny the login request). He can, of course, also kill the server in this case.
This may be good for your average VB-type desktop app, but for a multi threaded backend server this is a disaster. Such things simply should never be allowed to occur.
The special thing about the checked exceptions are that they can be thrown even from perfectly bug-free apps. No amount of coding can protect you from the odd IOException when your TCP connection is broken for example. Java does a tremendous job of helping the developer deal with this. It does this, just like a previous poster said, in a way that is similar to static types.
Static types are good, right? Helps us find bugs at the cost of a bit more code and more redundancy. The similarities to checked exceptions are quite obvious.
While I can agree that I have seen Java developers doing C# lately, I have also see the reverse happening. I don' thave any numbers but "extremely fast pace"?
It's called brand awareness. The point here is to make sure that people (and in the case of mobile phones, young people) equate "Java" with "cool games" and an "i need it" attitude. In the end this will (hopefully) mean that in order to be able to sell a phone, you need to support Java. In turn, this means that MS will have a that much harder time trying to get everyone to use the mobile version of .NET.
In fact, here in europe we see this happening already. Every new phone that comes out has J2ME support, and when a phone doesn't have it is reviewed, it's always mentioned as a big minus point.
I suppose (hope) we'll see the same thing happen in the US.
By the way, didn't the latest MS "smartphones" have J2ME support these days?
I propse a new quiz to be taken by all US citizens entering another country:
- Say the word "Hello" in our language
- Say the word "thank you" in our language
- Show us the proper to greet somebody
Seriously. Even withou this quiz, learning these takes a few minutes, and it opens up a complete new world.I cannot stress this enough: Learn these things. Just imagine what would happen if someone came to you, gave you a headbutt and yelled "Hey! Bitch!" to you. Seriously, what is considered a friendly greeting in one country, might not be in a different one.
Disclaimer: I'm not suggesting any country or culture uses the expression "Hey! Bitch!" as a greeting.
Why? Well, First of all, IBM's move meant that customers were taking Windows more seriously. But, why run OS/2 if you can run Windows? I think the same this is about to happen here. This move my Microsoft is going to cause customers to really take Linux seriously, I mean, why else would you want a Linux emulation layer if Linux isn't a serious OS?
Once that happens, the customers are going to wonder why they even bother running Windows in the first place. Hell, with Linux I can run the application native, AND it's cheaper!
This is just one of the indications we're getting that Microsoft is getting desperate. This will get interesting.
Right, but check how many of the apps are actually compiled in an LP64 environment. I think you'll be surprised.