Yes, but he speaks more authoritively than any of his replies thus-far, so I have no good reason to disbelieve him. Additionally, the assertions that you made in your post do not contradict his post, which is why I was requesting more information.
If government agencies began to be allowed to sell those rights (which they'd need to be via law), it would be completely legal (since the law changed) for the people who bought those rights to sue you for infringement.
It sickens me to think that any material I publish in the future might have to have a specific notice to automatically allow it to pass into the public domain.
He didn't claim password lookups were O(n), he was claiming it of other systems.
I'd like to see a piece-by-piece breakdown of his "inaccuracies", rather than a blind assertion that he is wrong. Until then, I see no reason to disbelieve him.
Open formats, however, guarantee at least as much compatibility as the competitor's brand, so restricting such a clause to Microsoft would be unfair, was what I was trying to say.
Now, if the State was REALLY smart, they'd include a clause that any Word documents which couldn't be read via the current Word technology 5-10 years in the future would require Microsoft to pay a fine of, say, $100 per document. To cover the States' cost in converting it so that it could be read again.
To be fair, the new versions of Office use open XML formats. Too long coming, yes, but this clause would probably just be too late.
I'm not the observations of Evolution is wrong, I'm just saying it's highly likely that any philosophy or world-view a particular science-technique appears to imply at this point in time (with Evolution, a philosophy of No God, No Plan) is HIGHLY likely to be.... Dead wrong.
Nobody's trying to use Evolution to prove that God doesn't exist. Creationists are trying to use holy texts to prove that evolution is wrong. This is neither a productive nor sensible line to go down. Evolution implies that people are derived from apes, and most science implies that the world is a great deal older than incredibly literal religious followers (which are a small subset of religious people, largely localised in the United States for whatever reason) would like to believe.
Thanks for the elaborate response:). I have to say that I don't tend to use such advanced features as you mention (even with large volumes of mail, I don't find them necessary). I enjoy the "labels" metaphor as opposed to "folders", I find it more logical.
These things are very much a matter of opinion though, I suppose. Also a lot of things you mention are mailing list niceties, which I don't use in any great depth.
They're both at least a little more consistent. Most Windows apps use the standard Windows widgets, and follow its HIG fairly closely, simply by convention. With Linux-based systems, there's just a little inconsistency since there's more than one environment that systems can run on. This would be a lot less of a problem if there was only one, or only one being targetted, by a system which managed it without dropping to the other. It's possible -- Ubuntu in particular, of the distributions I've been playing with recently, are attempting this approach with more success than most in the past -- but it's not easy.
But apps in Windows tend to be more consistent since they are all drawn, and designed to be drawn, by the normal Windows widgets. It's a shame, but it's not insurmountable.
Have you even considered the notion that GUI is more a matter of taste than anything else?
If only that were as simple as that. Yes, for us techies, it's just a matter of opinion. I agree fully. For the inexperience end user, however, a huge list of options for frontends and so on just lead to the system being inconsistent. Programs designed to run on GNOME don't behave or look like programs designed to run on KDE, and vice versa, and so on for other environments, even though they "work fine" under the other environment. That means that either you need to have a specific version of each app for each environment, or have a splintered, inconsistent, difficult-to-learn, and ugly mess.
As good a thing as choice is, it needs to be balanced with usability if "Desktop Linux" is ever to be a real competitor. Choice works great with experienced users, those who need or want to customise things. People who want to simply use a system are likely to be confused and put off, anquite rightfully so.
I agree that "pushing a door" is a simple analogy, but our abstraction is getting better all the time. One should not need to know how a computer works in order to undertake a task which does not directly involve "making the computer work". You shouldn't need to have to understand paths to save a file. I don't want the file with the name "letter to Bob" and last week's timestamp in the work subdirectory of the text docs folder with the correct file type. I want the letter I wrote to Bob last week. To a technical user like you or I these may be the same thing, but they're far, far from it. Another benefit that I desire is multiple membership of areas ("all the text documents" and "all the documents for work" are mutually exclusive goals of organisation with a traditional path structure, but their coexistence is both useful and not conceptually difficult).
People will have to get it into their heads that computers are complicated things and you need some basic understanding of how they work before being able to use them.
...and some technical users will have to get it into their heads that people don't think in terms of paths, and that computers can be easier to use, and fit in better with the view that people take of their data
That attitude (of the most people you are talking about) to me is just like, for instance: ``I don't want to learn about strings and notes, I just want to play the guitar!''
It strikes me as more like "why should this guitar have 200 strings and be specially made so that I can't look at it while I play it? Wouldn't it be easier to have just like, 6 strings, and mount it around the front?"
The actual location of files is incredibly useless to the end-user. If they can find their files faster and more easily with another method than knowing the file's path, that method is better. Metadata allows people to find files based on attributes about them, rather than some arbitrary hierarchical structure. Not that a proper metadata system would disallow that if you liked it.
The mistake is to assume that paths are an intuitive abstraction of a set of files.
Errr, you can click the little "pin" thing? I guess that's not ideal, since they become part of the window and shift stuff around at that point, though (that's annoyed me, but I eventually decided there wasn't a good reason, the way I develop, to have any of them up while focussing somewhere else).
True, but it stopped me from being able to type the same thing in a more verbose manner without sounding repetitive. But still, "Offtopic" in particular seemed harsh.
Yeah, it's pretty harsh. This doesn't mean it's a limitation of.NET as much as people refusing to do it right, though. It's just easier to integrate with potentially-unsafe code in.NET.
I believe that 1 and 2 (certainly 2) aren't really "security" in the same sense as the article is talking about. It's more of a "secure platform" analysis (which I believe 3 falls into the category of) rather than an analysis of the types of encrypted etc. transfers they support.
The auto-hiding tabs are a nightmare. Every time I want to go back to working, I have to move my mouse off and wait five seconds for it to decide to auto-hide, and then another second for the animation to finish. Is there any way to MANUALLY hide them without getting rid of them entirely?
The autohiding tabs hide immediately if you click somewhere other than on them – just click on your code editing view and they'll disappear.:)
Net can have lots of security features as long as you can pump a string directly into win32 in half of the classes, which triggers a buffer overflow everything is null and void in this article.
You can't do that unless you're P/Invoking worse code, or running in the unsafe mode, both of which are similar to running a JNI interface with which you could do the same thing
The CLI system is sandboxed, the underlying API is hidden and — in general, unless there's a problem with the implementation of the system — its shortcomings are essentially hidden.
Now, I'll grant it's easier (since you don't have to!), but in systems where reliability is a requirement the lack of checked exceptions can be a bit of a hassle, too easy to overlook and requiring good documentation (which, on the other hand, is a good thing).
Transparency with the whole string class/primitive issue.
Java does have autoboxing as of 5.0, but I know that's not really what you're on about. Being able to switch on strings and so on is handy though. Their special handling of strings seems a little "non-OO", but it eases development and is mighty handy.
Really easy to create and catch events.
Yes. Yes. Yes. Delegates are a fantastic construct.
Slashdot Mirror
Yes, but he speaks more authoritively than any of his replies thus-far, so I have no good reason to disbelieve him. Additionally, the assertions that you made in your post do not contradict his post, which is why I was requesting more information.
If government agencies began to be allowed to sell those rights (which they'd need to be via law), it would be completely legal (since the law changed) for the people who bought those rights to sue you for infringement.
It sickens me to think that any material I publish in the future might have to have a specific notice to automatically allow it to pass into the public domain.
He didn't claim password lookups were O(n), he was claiming it of other systems.
I'd like to see a piece-by-piece breakdown of his "inaccuracies", rather than a blind assertion that he is wrong. Until then, I see no reason to disbelieve him.
Open formats, however, guarantee at least as much compatibility as the competitor's brand, so restricting such a clause to Microsoft would be unfair, was what I was trying to say.
To be fair, the new versions of Office use open XML formats. Too long coming, yes, but this clause would probably just be too late.
Well, you made that point a lot better than I did!
Nobody's trying to use Evolution to prove that God doesn't exist. Creationists are trying to use holy texts to prove that evolution is wrong. This is neither a productive nor sensible line to go down. Evolution implies that people are derived from apes, and most science implies that the world is a great deal older than incredibly literal religious followers (which are a small subset of religious people, largely localised in the United States for whatever reason) would like to believe.
Thanks for the elaborate response :). I have to say that I don't tend to use such advanced features as you mention (even with large volumes of mail, I don't find them necessary). I enjoy the "labels" metaphor as opposed to "folders", I find it more logical.
These things are very much a matter of opinion though, I suppose. Also a lot of things you mention are mailing list niceties, which I don't use in any great depth.
They're both at least a little more consistent. Most Windows apps use the standard Windows widgets, and follow its HIG fairly closely, simply by convention. With Linux-based systems, there's just a little inconsistency since there's more than one environment that systems can run on. This would be a lot less of a problem if there was only one, or only one being targetted, by a system which managed it without dropping to the other. It's possible -- Ubuntu in particular, of the distributions I've been playing with recently, are attempting this approach with more success than most in the past -- but it's not easy.
But apps in Windows tend to be more consistent since they are all drawn, and designed to be drawn, by the normal Windows widgets. It's a shame, but it's not insurmountable.
If only that were as simple as that. Yes, for us techies, it's just a matter of opinion. I agree fully. For the inexperience end user, however, a huge list of options for frontends and so on just lead to the system being inconsistent. Programs designed to run on GNOME don't behave or look like programs designed to run on KDE, and vice versa, and so on for other environments, even though they "work fine" under the other environment. That means that either you need to have a specific version of each app for each environment, or have a splintered, inconsistent, difficult-to-learn, and ugly mess.
As good a thing as choice is, it needs to be balanced with usability if "Desktop Linux" is ever to be a real competitor. Choice works great with experienced users, those who need or want to customise things. People who want to simply use a system are likely to be confused and put off, anquite rightfully so.
Do you find there's a conceptual difficulty with GMail, or are you simply unwilling to learn its system?
Not intended as a troll.
I agree that "pushing a door" is a simple analogy, but our abstraction is getting better all the time. One should not need to know how a computer works in order to undertake a task which does not directly involve "making the computer work". You shouldn't need to have to understand paths to save a file. I don't want the file with the name "letter to Bob" and last week's timestamp in the work subdirectory of the text docs folder with the correct file type. I want the letter I wrote to Bob last week. To a technical user like you or I these may be the same thing, but they're far, far from it. Another benefit that I desire is multiple membership of areas ("all the text documents" and "all the documents for work" are mutually exclusive goals of organisation with a traditional path structure, but their coexistence is both useful and not conceptually difficult).
...and some technical users will have to get it into their heads that people don't think in terms of paths, and that computers can be easier to use, and fit in better with the view that people take of their data
It strikes me as more like "why should this guitar have 200 strings and be specially made so that I can't look at it while I play it? Wouldn't it be easier to have just like, 6 strings, and mount it around the front?"
The actual location of files is incredibly useless to the end-user. If they can find their files faster and more easily with another method than knowing the file's path, that method is better. Metadata allows people to find files based on attributes about them, rather than some arbitrary hierarchical structure. Not that a proper metadata system would disallow that if you liked it.
The mistake is to assume that paths are an intuitive abstraction of a set of files.
Errr, you can click the little "pin" thing? I guess that's not ideal, since they become part of the window and shift stuff around at that point, though (that's annoyed me, but I eventually decided there wasn't a good reason, the way I develop, to have any of them up while focussing somewhere else).
"lol"
True, but it stopped me from being able to type the same thing in a more verbose manner without sounding repetitive. But still, "Offtopic" in particular seemed harsh.
Yeah, it's pretty harsh. This doesn't mean it's a limitation of .NET as much as people refusing to do it right, though. It's just easier to integrate with potentially-unsafe code in .NET.
I believe that 1 and 2 (certainly 2) aren't really "security" in the same sense as the article is talking about. It's more of a "secure platform" analysis (which I believe 3 falls into the category of) rather than an analysis of the types of encrypted etc. transfers they support.
For the record, I think it's an injustice that you were modded down there.
I'm sorry for that. :(
Well, he was referring to the security model, it is implemented in Rotor, and teh source is likely to be very similar since it's from the same shop.
The autohiding tabs hide immediately if you click somewhere other than on them – just click on your code editing view and they'll disappear. :)
You can't do that unless you're P/Invoking worse code, or running in the unsafe mode, both of which are similar to running a JNI interface with which you could do the same thing
The CLI system is sandboxed, the underlying API is hidden and — in general, unless there's a problem with the implementation of the system — its shortcomings are essentially hidden.
Now, I'll grant it's easier (since you don't have to!), but in systems where reliability is a requirement the lack of checked exceptions can be a bit of a hassle, too easy to overlook and requiring good documentation (which, on the other hand, is a good thing).
Java does have autoboxing as of 5.0, but I know that's not really what you're on about. Being able to switch on strings and so on is handy though. Their special handling of strings seems a little "non-OO", but it eases development and is mighty handy.
Yes. Yes. Yes. Delegates are a fantastic construct.