I think it's worth noting that in the 'tyrant' comment Norman did not refer to 'UI design' but 'software design'. I don't mean to get too heavily into word parsing, but I think that's really what he might have meant; at least it's where I think a problem with open source might be. In other words, it was a software architecture comment, not a GUI comment.
Whether we like it or not, GUIs follow internal code organization. And we should like it. It makes sense. The problem is that if everyone has a hand in architecture / design, you end up with a morass. If someome imposes an architecture / design, it at least makes some kind of sense, and the GUI will in most cases follow.
Lord knows, there is plently of poorly written commerical software. But in a sense, at least it has a chance to be 'great', since some great architect might have designed it. Open source has the problem that it tends to degenerate into a collection of the 'good enough'.
Re:One thing I've NEVER seen here....
on
Fair IP Laws?
·
· Score: 1
You raise two issues, which are in fact interconnected, but I initially I will deal with them according to the distinction that you draw.
Your first assumption is in my opinion true. There are few (if any) decent examiners. This will not change until the PTO is prepared to pay examiners the going rate for talented programmers. In other words, until an examiner can make > 100K, then the system simply won't work. This is not simply a problem with software, by the way, but that's largely another topic.
The second issue is in fact the the bigger concern. The problem is not that there are so many talented programmers who could duplicate patented code. The problem is that any moron programmer could not only duplicate much patented code, but could come up with it in the first place. This may mistate your issue, and may in fact degrade into your first issue. However, the problem is that patent law is not, in any reasonable sense, being applied in the software field. (Although my impression is that this is not only a software problem). Patents are not granted only for 'inventions' that are 'novel' and 'original'. They are frequently -if not usually - granted for 'inventions' (loosely speaking) that are 'old' and 'obvious'.
The implication of your post is that this is simply a problem with the quality of the examiners. As I implied earlier, maybe. But only if the quality of the examiners goes through the roof compared to what it is now.
Think about it from the salary perspective. (This is true not only from the software perspective; it's true for any disipline where the PTO cannot or will not pay for technical skills at the going rate.) If the PTO will pay much less than private industry, that means the PTO will get people who can't get hired into private industry. In other words, people who can't put two goddam thoughts together in a row, and then get to decide if something is fucking obvious or not.
So, perhaps, I agree that the first problem is really the major problem. And I don't think it's going away. In other words, I think the solution is to kill off software patents (and many other categories: I'm pretty hard core on this.) Mainly this is because the PTO will never pay some techie $120K a year. And that's what's it's going to take to get reasonable patent examiners. Otherwise what you get, and will get, is inovation-quashing stupidity.
In re-reading this, it sounds like I might be a disgruntled patent examiner who perceives himself to be underpaid. This is not the case. I'm simply making an economic point. If you hire the dregs, you get shoddy work. If the work is really shoddy (as it is) you might be better to do away with the whole system than try to fix it.
Although I expect to get flamed for saying this, the whole SQL named password thing is a bit of a SQLServer anachronism. The 'prefered' way to install SQL is to use domain security only. If you want to use named logins (which is convenient sometimes, but mostly only for legacy reasons) you can set it up that way. You have to go out of your way to do so though.
It's lots more convenient to use domain pass-through authentication for almost all purposes. Now, if these systems were upgrades from SQL 6.0+ then that's a problem. However, if these were clean SQL 2000 installs, the people who set them up not only explicitly chose a blank password, but also explitcity chose to use named logins at all.
Slashdot Mirror
I think it's worth noting that in the 'tyrant' comment Norman did not refer to 'UI design' but 'software design'. I don't mean to get too heavily into word parsing, but I think that's really what he might have meant; at least it's where I think a problem with open source might be. In other words, it was a software architecture comment, not a GUI comment.
Whether we like it or not, GUIs follow internal code organization. And we should like it. It makes sense. The problem is that if everyone has a hand in architecture / design, you end up with a morass. If someome imposes an architecture / design, it at least makes some kind of sense, and the GUI will in most cases follow.
Lord knows, there is plently of poorly written commerical software. But in a sense, at least it has a chance to be 'great', since some great architect might have designed it. Open source has the problem that it tends to degenerate into a collection of the 'good enough'.
You raise two issues, which are in fact interconnected, but I initially I will deal with them according to the distinction that you draw.
.
Your first assumption is in my opinion true. There are few (if any) decent examiners. This will not change until the PTO is prepared to pay examiners the going rate for talented programmers. In other words, until an examiner can make > 100K, then the system simply won't work. This is not simply a problem with software, by the way, but that's largely another topic.
The second issue is in fact the the bigger concern. The problem is not that there are so many talented programmers who could duplicate patented code. The problem is that any moron programmer could not only duplicate much patented code, but could come up with it in the first place. This may mistate your issue, and may in fact degrade into your first issue. However, the problem is that patent law is not, in any reasonable sense, being applied in the software field. (Although my impression is that this is not only a software problem). Patents are not granted only for 'inventions' that are 'novel' and 'original'. They are frequently -if not usually - granted for 'inventions' (loosely speaking) that are 'old' and 'obvious'.
The implication of your post is that this is simply a problem with the quality of the examiners. As I implied earlier, maybe. But only if the quality of the examiners goes through the roof compared to what it is now.
Think about it from the salary perspective. (This is true not only from the software perspective; it's true for any disipline where the PTO cannot or will not pay for technical skills at the going rate.) If the PTO will pay much less than private industry, that means the PTO will get people who can't get hired into private industry. In other words, people who can't put two goddam thoughts together in a row, and then get to decide if something is fucking obvious or not
So, perhaps, I agree that the first problem is really the major problem. And I don't think it's going away. In other words, I think the solution is to kill off software patents (and many other categories: I'm pretty hard core on this.) Mainly this is because the PTO will never pay some techie $120K a year. And that's what's it's going to take to get reasonable patent examiners. Otherwise what you get, and will get, is inovation-quashing stupidity.
In re-reading this, it sounds like I might be a disgruntled patent examiner who perceives himself to be underpaid. This is not the case. I'm simply making an economic point. If you hire the dregs, you get shoddy work. If the work is really shoddy (as it is) you might be better to do away with the whole system than try to fix it.
Although I expect to get flamed for saying this, the whole SQL named password thing is a bit of a SQLServer anachronism. The 'prefered' way to install SQL is to use domain security only. If you want to use named logins (which is convenient sometimes, but mostly only for legacy reasons) you can set it up that way. You have to go out of your way to do so though.
It's lots more convenient to use domain pass-through authentication for almost all purposes. Now, if these systems were upgrades from SQL 6.0+ then that's a problem. However, if these were clean SQL 2000 installs, the people who set them up not only explicitly chose a blank password, but also explitcity chose to use named logins at all.
You get what you get.