Interesting. I've never run across an example of using exceptions that can't be done more cleanly, quickly, and efficiently by simply using (and checking) result codes.
The problem with result codes is that you can't propagate the problem up to the level of scope that should be dealing with it. For example, imagine you have a GUI program. At some point, it needs to open "foo.txt", but fails. Since you're a good software engineer, you've well-separated your GUI code from logic code. The GUI needs to display an error message, but if you only check error calls, the only part that knows about the eror that has happened is way down in the logic code, which has no idea how to tell the user. And propagating 'undef's all the way up through the code is uncool. Especially since return values should not be used to indidate errors; they should be used for return values.
With an exceptions model, you can let the logic code just propagate the error up to the GUI, who can then display a message to the user. It's a very clean, elegant system.
try
do_something
except
on e.excpetion do
exit;
end;
end;
(Sorry for the lack of prettiness; Slashdot's input mechanism doesn't allow <pre> tags.)
This is not how you would handle it using exceptions; you would merely say "do_something". Period. If "do_something" threw an exception, and it wasn't caught, it propagates up and the program dies automatically.
Exceptions are mandatory for good programming, period. If the language you are using doesn't support exceptions (C, Perl, etc), you are going to have problems. Exceptions make sure that if an error occurs, and you aren't aware of it, your program dies, and doesn't go on its merry way, causing a security hole/unstable software.
Perl's hack at exceptions using 'die' doesn't cut it; one important thing about implementing exceptions is that your base operations (e.g., opening files, and other system functions) need to raise exceptions when problems occur. If this doesn't happen, you're only going to struggle in vain to implement good, correct code.
Exceptions are a primary reason I've moved from Perl to Python. Python's exceptions model is standard and clean. Base operations throw exceptions when they occur problems. And my hashes no longer auto-vivify on access, thank goodness. Auto-vivification on hash access are probably one of the principle causes of bad Perl code.
As ludicrous as it might sound, if MS knows they are not conforming to the standard but everyone else is, then they truly are doing something they can't expect everyone else to do.
Ah, but both Mozilla and Opera are capable of not conforming to standard (e.g., not dying on non-wellformed XML), as well as abiding by it strictly. Again also, rembmer MS is targetting Mozilla and Opera. According to your argument, they should be blocking all other browsers, but they are not.
I'm starting to use this to serve up different JavaScript based on the user-agent, because this reduces the bandwidth consumption by the client (it's not downloading code it won't use).
You are changing behaviour based on what the client can do. This is best resolved by having Javascript able to ask "can I do this function?", and then download the extra code if it can do you enhanced functions or not.
And in extreme cases, I can actually see a need to use this. Let's say you find a version of SSH which is critically flawed, such that it will compromise the encryption process and make your session essentially plaintext. The server recognizes your version and refuses to allow you to connect, telling you you must upgrade. That might actually be a good thing.
First of all, its no threat to the server if the user is compromised. The server must trust the users judgement; anything the user has access to, the user can disseminate. Forcing the user to secure the connection more is something the user should be able to override (though maybe with some effort); in the end, the user can, if he/she desires, destroy any attempts at security, because they are at the receiving end.
Second, the key thing here is that you are not blocking a client, but rather a protocol version. The two are different; one indicates what something is, while the other, what something can do. Blocking something based on what it is is not a good thing for the communal workings.
They aren't MS's browser and MS is using IE-specific features.
You haven't been paying attention. This is false. They are blocking specific clients, not just non-IE ones (specically Mozilla and Opera). There is nothing IE-specific in what they are presenting.
Having client identifiers is a Good Idea for the same reason that having protocol identifiers is a Good Idea: different clients handle things differently.
Your comparsion is flawed. Protocols identifiers describe publicly-known capabilities. These capabilities are standarized in the protocol. On the otherhand, what Microsoft is doing is asking Mozilla what it can do, but simply saying "Your badge says Mozilla; go away." Mozilla can handle MSN with ease. It is not a protocol or capability issue that Microsoft is blocking because of.
Since this means that things can be presented differently on one client and platform than on another (whether it's a bug or not), it can be important to be able to tell the difference between one client and another to provide a consistent presentation and to handle any known bugs.
The W3 standards are not designed so that each user gets the exact same experience. They are designed so that an agent can be customized for a user's experience. It should not the servers' problem that there are buggy clients. As you state, there will be more of them, and catering to them is asking for more broken software.
I develop web applications and there are times when a client asks for something that simply isn't feasible (or perhaps possible) in Netscape 4.x, so we inform the client of that and, effectively, prohibit them from using Netscape 4.x to access the application. I don't see much of a difference here.
The problem in both situation is that you and Microsoft are actively preventing the browser from even trying to render the page correctly. Maybe the page won't look as well in Netscape 4, but at least it is accessible.
Furthermore, while blocking Netscape 4 is done under the pretences that Netscape 4 is broken, the blocking Microsoft is doing is the exact opposite: Opera and Gecko are two of the most correct renderers out there! Microsoft surely isn't blocking them because they are broken to some extent, but rather they are afraid of them!
I've been thinking about this for a while, and prompted by this scenario, I've come to the conclusion that protocols that let client-identifying strings go through is just asking for discrimination and phony statistics.
Many protocols use client identifers, such as HTTP, SSH, and OpenPGP. However, I'm not seeing any true purpose for having these identifiers stuck into the messages used in these protocols. Perhaps at one time they were used so that workarounds for buggy clients could be made, but the problem there is with the buggy client. Nowdays, however, checking client identifiers, be it via user-agent or Javascript tests, it is used to discriminate against certain clients.
Futhermore, many clients probably lie about what what they are, in order to get a server to listen to them. This is sad, because it creates false statistics about what the client percentage breakdown really is. In addition to this problem, the statistics themselves create a snowballing effect, suggesting to server-admins to only 'support' certain clients, and suggesting to end-users that 'everyone' is using a certain client and they should too.
Just as justice is supposed to be blind, I feel the same should be said about servers; they should have no knowledge of what client it is that is accessing them.
As more and more services become network-enabled, we should be wary of any protocol that implements a client-identifier. Or else we will see more of the same discrimination.
How do you think the Israeli's came by this knowledge? By HAVING PLANES HIJACKED. Was the world created yesterday? Or is it just your youth showing?
It's my understanding a certain Israeli airline has never been hijacked, yet they have solid security procedures. Furthermore, would it be too much to learn from the Israeli about how to prevent hijackings, instead of just ignoring one of most terrorist-targetted nations in the world?
Do some research before you put your foot in your mouth.
And can we really blame the architects of the WTC for not making the building plane-proof? No, I think they performed "reasonably" well.
No, but we can blame the architects of the airline security for allowing terrorists to take over the plane, like providing heavily shielded doors, such as those found in Israeli airlines, who know a thing or two about security.
Basically your whole argument goes down the drain since you rely entirely on the statement I just trashed.
Xemacs is very nice. I was typing "M-x complete", and the next thing it told me was that "complete" is also bound it "C-return". So, just hit Ctrl-return, and Xemacs magically completes any word for you!
Emacs has what you want. I'm not familiar with the exact command
It seems like Xemac's version of the command is simply "complete" (access via "M-x complete"). You should probably bind this to an easier to access command (something else I have to look up how to do).
It's amazing what you can find with the "apropos" command.
...a program that watches what I type and when it sees me repeating a word or phrase several times, suggests a short cut without interrupting me, e.g. displaying it in the info bar at the bottom of the window. For example, if I keep typing "String", it might suggest [S][T][space] as the shortcut.
Emacs has what you want. I'm not familiar with the exact command (an Emacs guru showed me how it works, though). Basically, you type away at whatever you are doing, and if you want it to auto-complete a word, any word, you give a short command (maybe a C-x thingy), and it looks at the surrounding context and typing history, figuring out what word to complete it as.
FYI, I don't know if Xemacs has a similar command.
Yes, it appears to be the CFS I'm talking about. The nice thing about CFS is that since it relies on NFS for its infrastructure, it is very portable, and resides entirely in user-land (with a root-running daemon).
TCFS is generally used to encrypt entire home directories, and but is generally Linux specific (kernel tie-ins). It is more advanced than CFS, though.
Here's the problem with what you're doing: you can't do authentication forwarding
Yes, I realize that is a limitation of what I'm doing. When I do need authentication forwarding I do use ssh-agent; it is definitely a useful tool. I just wish it wasn't so session-limited. Kerberos is able to handle being across session (although using a very weak mechanism, I admit).
Personally, I like to use CFS, the Cryptographic File System, to store my filesystem-stored secrets. CFS works as an NFS loopback server, encrypting directories using a symmetric cipher.
When you 'cattach' (unlock) a CFS directory by entering the passphrase needed to decrypt the directory, you can then access the directory as normally as any other directory. The encryption/decryption is done on a need-to basis; sorta like PGPDisk for Windows, I imagine.
The reason I like to use CFS over thing such as ssh-agent is that has several features and advantages over ssh-agent:
One can set attached directories to detach after a set idletime or a fixed time. I find this very convienent, and an almost mandatory security measure. For example, I have my ssh keys set to detach after 20 minutes of non-use.
It is much easier and plain to use decrypted secrets in multiple concurrent sessions than ssh-agent. For example, a certain environment need not be mirrored across several xterms that are all accessing the secrets (e.g., I ssh from different xterm's).
With ssh-agent, it can be cumbersome to keep this in-sync across multiple windows.
Of course, it can help to start ssh-agent with the X session, but this is not always available; for example, I could have multiple console terminals open, all accessing my ssh keys. Or I could login multiple times to a box which has ssh keys on it remotely several times (open up several ssh connections); I want to be able to unlock the secrets in one session and have it apply to the others.
Personally, I think CFS's approach to having secrets available across multiple concurrent sessions is a 'better' approach than some hacks that have been suggested.
CFS can much more easily be used to store other secrets, such as my GnuPG keys. It is a good general-purpose secret-storer.
Unfortunately, I can't find a good URL for CFS, so you'll have to do some searching on your own. It's in the FreeBSD ports collection, though.
You know, you could've just said "It's all trees, really", and made it a lot simpler. Speaking of which, XML may simply be a notation for hierarchial and mixed data, but it happens to be a fairly simple one that extends well into multiple namespaces, is unambiguous with regards to parsing, and in general is human readable.
While I agree XML may not be the best at at accomplishing specific tasks, its general nature makes it a pretty good fit for general, all-around use. Uniformly using XML for a lot of things helps out us humans more than anything else.
People aren't stupid, contrary to popular belief. Sell them two harddrives at the same price, specify that one will allow you to store mp3's and the other won't, guess which one they're going to buy?
And just who is this ever-present tech-savvy being that follows all the non-tech people around when they buy a new hard-drive, and magically "specifies" to them them the difference? They will simply go to Best Buy, see a Microsoft-media-enhanced hard-drive that sells for $25 less, and buy it.
You have way too much faith in the common consumer to be discriminating about decisions that require technological know-how.
The fact that HTML is a semantic markup language has nothing to do with the fact that it's used as a presentational language, thereby effectively nullifying your argument.
On the other hand, your entire argument is nullified since the client in no way shape or form needs to support the deprecated presentational aspects of HTML.
Could you possibly be more ignorant of what HTML is? You fail to realize that HTML is a semantic markup language, not some presentational language, which you obviously think it is, judging from your webpage, which uses a plethora of deprecated presentational HTML elements. I've written about the topic of HTML email at length; it comes down to the fact that HTML provides a greater means of communication since it is a semantic markup language, and since it is such, gives the ability of presentation to the reader, not the author, as which is done with flat text. Having the author decide presentation is one of the worst evils we are plagued with concerning email.
Personally, I despise any kind of marked up e-mail format.
Why in the world would you do such a ignorant thing such as to despise a semantic markup language such as HTML. It would be utterly idiotic to put down a semantic markup language, which has the purpose of providing a better description of the message's meaning to the reader. I've written about this at length on my website, so I'm not going to try to re-iterate this old, tired argument. In the end, HTML email providea meaning and structure, and gives the power of presentation to the reader, not the author.
Amaya, from what I can tell, does not support as much CSS2 as Gecko. Amaya is much more pedantic in it's rendering of documents, though; you can't give it garbage markup and expect it to do anything with it.
Easy. He says Netscape is an inferior browser; Netscape (and Mozilla) are the most standards-compliant browsers out there. He must've been talking about Netscape4.x. He's obviuosly not keeping up with technology.
There are also plenty of other highy standards-compliant browsers out there, including Konqueror and Opera. Anyone who thinks the battle is only between IE and Netscape should really wake up.
Slashdot Mirror
The problem with result codes is that you can't propagate the problem up to the level of scope that should be dealing with it. For example, imagine you have a GUI program. At some point, it needs to open "foo.txt", but fails. Since you're a good software engineer, you've well-separated your GUI code from logic code. The GUI needs to display an error message, but if you only check error calls, the only part that knows about the eror that has happened is way down in the logic code, which has no idea how to tell the user. And propagating 'undef's all the way up through the code is uncool. Especially since return values should not be used to indidate errors; they should be used for return values.
With an exceptions model, you can let the logic code just propagate the error up to the GUI, who can then display a message to the user. It's a very clean, elegant system.
(Sorry for the lack of prettiness; Slashdot's input mechanism doesn't allow <pre> tags.)
This is not how you would handle it using exceptions; you would merely say "do_something". Period. If "do_something" threw an exception, and it wasn't caught, it propagates up and the program dies automatically.
Exceptions are mandatory for good programming, period. If the language you are using doesn't support exceptions (C, Perl, etc), you are going to have problems. Exceptions make sure that if an error occurs, and you aren't aware of it, your program dies, and doesn't go on its merry way, causing a security hole/unstable software.
Perl's hack at exceptions using 'die' doesn't cut it; one important thing about implementing exceptions is that your base operations (e.g., opening files, and other system functions) need to raise exceptions when problems occur. If this doesn't happen, you're only going to struggle in vain to implement good, correct code.
Exceptions are a primary reason I've moved from Perl to Python. Python's exceptions model is standard and clean. Base operations throw exceptions when they occur problems. And my hashes no longer auto-vivify on access, thank goodness. Auto-vivification on hash access are probably one of the principle causes of bad Perl code.
Ah, but both Mozilla and Opera are capable of not conforming to standard (e.g., not dying on non-wellformed XML), as well as abiding by it strictly. Again also, rembmer MS is targetting Mozilla and Opera. According to your argument, they should be blocking all other browsers, but they are not.
You are changing behaviour based on what the client can do. This is best resolved by having Javascript able to ask "can I do this function?", and then download the extra code if it can do you enhanced functions or not.
First of all, its no threat to the server if the user is compromised. The server must trust the users judgement; anything the user has access to, the user can disseminate. Forcing the user to secure the connection more is something the user should be able to override (though maybe with some effort); in the end, the user can, if he/she desires, destroy any attempts at security, because they are at the receiving end.
Second, the key thing here is that you are not blocking a client, but rather a protocol version. The two are different; one indicates what something is, while the other, what something can do. Blocking something based on what it is is not a good thing for the communal workings.
You haven't been paying attention. This is false. They are blocking specific clients, not just non-IE ones (specically Mozilla and Opera). There is nothing IE-specific in what they are presenting.
Your comparsion is flawed. Protocols identifiers describe publicly-known capabilities. These capabilities are standarized in the protocol. On the otherhand, what Microsoft is doing is asking Mozilla what it can do, but simply saying "Your badge says Mozilla; go away." Mozilla can handle MSN with ease. It is not a protocol or capability issue that Microsoft is blocking because of.
The W3 standards are not designed so that each user gets the exact same experience. They are designed so that an agent can be customized for a user's experience. It should not the servers' problem that there are buggy clients. As you state, there will be more of them, and catering to them is asking for more broken software.
The problem in both situation is that you and Microsoft are actively preventing the browser from even trying to render the page correctly. Maybe the page won't look as well in Netscape 4, but at least it is accessible.
Furthermore, while blocking Netscape 4 is done under the pretences that Netscape 4 is broken, the blocking Microsoft is doing is the exact opposite: Opera and Gecko are two of the most correct renderers out there! Microsoft surely isn't blocking them because they are broken to some extent, but rather they are afraid of them!
I've been thinking about this for a while, and prompted by this scenario, I've come to the conclusion that protocols that let client-identifying strings go through is just asking for discrimination and phony statistics.
Many protocols use client identifers, such as HTTP, SSH, and OpenPGP. However, I'm not seeing any true purpose for having these identifiers stuck into the messages used in these protocols. Perhaps at one time they were used so that workarounds for buggy clients could be made, but the problem there is with the buggy client. Nowdays, however, checking client identifiers, be it via user-agent or Javascript tests, it is used to discriminate against certain clients.
Futhermore, many clients probably lie about what what they are, in order to get a server to listen to them. This is sad, because it creates false statistics about what the client percentage breakdown really is. In addition to this problem, the statistics themselves create a snowballing effect, suggesting to server-admins to only 'support' certain clients, and suggesting to end-users that 'everyone' is using a certain client and they should too.
Just as justice is supposed to be blind, I feel the same should be said about servers; they should have no knowledge of what client it is that is accessing them.
As more and more services become network-enabled, we should be wary of any protocol that implements a client-identifier. Or else we will see more of the same discrimination.
It's my understanding a certain Israeli airline has never been hijacked, yet they have solid security procedures. Furthermore, would it be too much to learn from the Israeli about how to prevent hijackings, instead of just ignoring one of most terrorist-targetted nations in the world?
Do some research before you put your foot in your mouth.
No, but we can blame the architects of the airline security for allowing terrorists to take over the plane, like providing heavily shielded doors, such as those found in Israeli airlines, who know a thing or two about security.
Basically your whole argument goes down the drain since you rely entirely on the statement I just trashed.
Xemacs is very nice. I was typing "M-x complete", and the next thing it told me was that "complete" is also bound it "C-return". So, just hit Ctrl-return, and Xemacs magically completes any word for you!
It seems like Xemac's version of the command is simply "complete" (access via "M-x complete"). You should probably bind this to an easier to access command (something else I have to look up how to do).
It's amazing what you can find with the "apropos" command.
Emacs has what you want. I'm not familiar with the exact command (an Emacs guru showed me how it works, though). Basically, you type away at whatever you are doing, and if you want it to auto-complete a word, any word, you give a short command (maybe a C-x thingy), and it looks at the surrounding context and typing history, figuring out what word to complete it as.
FYI, I don't know if Xemacs has a similar command.
Yes, it appears to be the CFS I'm talking about. The nice thing about CFS is that since it relies on NFS for its infrastructure, it is very portable, and resides entirely in user-land (with a root-running daemon).
TCFS is generally used to encrypt entire home directories, and but is generally Linux specific (kernel tie-ins). It is more advanced than CFS, though.
Yes, I realize that is a limitation of what I'm doing. When I do need authentication forwarding I do use ssh-agent; it is definitely a useful tool. I just wish it wasn't so session-limited. Kerberos is able to handle being across session (although using a very weak mechanism, I admit).
Personally, I like to use CFS, the Cryptographic File System, to store my filesystem-stored secrets. CFS works as an NFS loopback server, encrypting directories using a symmetric cipher.
When you 'cattach' (unlock) a CFS directory by entering the passphrase needed to decrypt the directory, you can then access the directory as normally as any other directory. The encryption/decryption is done on a need-to basis; sorta like PGPDisk for Windows, I imagine.
The reason I like to use CFS over thing such as ssh-agent is that has several features and advantages over ssh-agent:
One can set attached directories to detach after a set idletime or a fixed time. I find this very convienent, and an almost mandatory security measure. For example, I have my ssh keys set to detach after 20 minutes of non-use.
It is much easier and plain to use decrypted secrets in multiple concurrent sessions than ssh-agent. For example, a certain environment need not be mirrored across several xterms that are all accessing the secrets (e.g., I ssh from different xterm's).
With ssh-agent, it can be cumbersome to keep this in-sync across multiple windows.Of course, it can help to start ssh-agent with the X session, but this is not always available; for example, I could have multiple console terminals open, all accessing my ssh keys. Or I could login multiple times to a box which has ssh keys on it remotely several times (open up several ssh connections); I want to be able to unlock the secrets in one session and have it apply to the others.
Personally, I think CFS's approach to having secrets available across multiple concurrent sessions is a 'better' approach than some hacks that have been suggested.
Unfortunately, I can't find a good URL for CFS, so you'll have to do some searching on your own. It's in the FreeBSD ports collection, though.
You know, you could've just said "It's all trees, really", and made it a lot simpler. Speaking of which, XML may simply be a notation for hierarchial and mixed data, but it happens to be a fairly simple one that extends well into multiple namespaces, is unambiguous with regards to parsing, and in general is human readable.
While I agree XML may not be the best at at accomplishing specific tasks, its general nature makes it a pretty good fit for general, all-around use. Uniformly using XML for a lot of things helps out us humans more than anything else.
The GPL certainly does not have a hidden agenda. The agenda is clearly and openly spelled out.
Ah, so he did. So, rephrase my argument, but make the harddrives of equal price. People will still choose the "MS-enhanced" version.
And just who is this ever-present tech-savvy being that follows all the non-tech people around when they buy a new hard-drive, and magically "specifies" to them them the difference? They will simply go to Best Buy, see a Microsoft-media-enhanced hard-drive that sells for $25 less, and buy it.
You have way too much faith in the common consumer to be discriminating about decisions that require technological know-how.
On the other hand, your entire argument is nullified since the client in no way shape or form needs to support the deprecated presentational aspects of HTML.
Could you possibly be more ignorant of what HTML is? You fail to realize that HTML is a semantic markup language, not some presentational language, which you obviously think it is, judging from your webpage, which uses a plethora of deprecated presentational HTML elements. I've written about the topic of HTML email at length; it comes down to the fact that HTML provides a greater means of communication since it is a semantic markup language, and since it is such, gives the ability of presentation to the reader, not the author, as which is done with flat text. Having the author decide presentation is one of the worst evils we are plagued with concerning email.
Why in the world would you do such a ignorant thing such as to despise a semantic markup language such as HTML. It would be utterly idiotic to put down a semantic markup language, which has the purpose of providing a better description of the message's meaning to the reader. I've written about this at length on my website, so I'm not going to try to re-iterate this old, tired argument. In the end, HTML email providea meaning and structure, and gives the power of presentation to the reader, not the author.
Amaya, from what I can tell, does not support as much CSS2 as Gecko. Amaya is much more pedantic in it's rendering of documents, though; you can't give it garbage markup and expect it to do anything with it.
Easy. He says Netscape is an inferior browser; Netscape (and Mozilla) are the most standards-compliant browsers out there. He must've been talking about Netscape4.x. He's obviuosly not keeping up with technology.
There are also plenty of other highy standards-compliant browsers out there, including Konqueror and Opera. Anyone who thinks the battle is only between IE and Netscape should really wake up.