There's nothing stopping you from lopping off the jack and doing a direct connect from the adapter wires to the battery terminals. Not convenient, and ugly by some standards, but easy as pie.
We've never seen a really clean text based UI. vi, lotus 1-2-3, xywrite and emacs, for all their qualities, are based on stone age UI standards. Imagine if Stallman had done usability testing - it would have been completely different.
Graphical != Usable. Graphical widgets can present so much distracting information that users can't find the important stuff. Toolbars, dialog boxes, non monospaced fonts - a lot of gingerbread is destructive to UI quality.
Where character based UIs fall down is in visual functionality - desktop publishing or image editing. But that's not such a big problem for all apps.
Wait! It's not that simple! Open source competes against secret source on a different time scale.
Open source uses accretion, and operates on geological time. Drip, drip, drip. Slow accumulation of itches scratched... Secret source uses huge amounts of manpower and operates on mtv time. Secret source will often have the edge in the short term. So when things are changing rapidly secret source will be able to compete. It's when a market settles down that open source is unstoppable.
Word processors are a mature technology; we have parity in open source word processors. HTML is a mature technology; we have HTML parity. There is a new RealPlayer twice a day; we do not have parity.
Consumers should be able to make their own choice according to their values. Tell 'em it's ol' faithful open source VS. sexy but undependable secret source. Let there be a choice.
(Don't flame me for suggesting that open source methods can't compete in a fast moving situation! They can at exceptional moments - like the present - when heavy hype has made large numbers of people available for work - but at less visible moments progress will become glacial again!)
Applix Anyware has a java powered thin client that is smart enought to run dialog boxes, redraw widgets, and do other trivial things without going back to the server. This is exactly what X, not to mention http/html, is missing. Sure would be useful for better freemail clients, among other things.
I suggest we move this discussion to Cosource.com. Let people who want a solution vote by submitting a request, committing a few bucks, or making a proposal.
I would submit a request myself, but also want to make a proposal.
Certificates/PKis etc. are just too heavy for people at this point, even technical people. Nobody gets it. Check out the level of technical sophistication in this conversation alone - it's unusually clueless for slashdot.
(I'm not a specialist, BTW, but I did have to do a basic crypto coding job recently so I had to figure out the basics).
It is common for implementors of internet enabled apps to need to pass messages back and forth. Since the only way past the corporate fireway is via the proxy, these apps have no choice but to overload http. Applix Anyware, among many, does this. SOAP is a standardization of this practice.
CORBA is too heavyweight for these applications. Worse, a corba-over-http bridge must be used to get out via the proxy.
Without SOAP implementors will keep writing custom implementations over and over again. Thus SOAP is a Good Thing because it lets us code this once and for all and move on.
html/jscript etc is a basically unusable dev environment for a lot of applications. the biggest problem is statelessness. the second biggest problem is javascript bugs - you absolutely must not depend on javascript. (part of the problem with jscript is that a user isn't required to be using it - any validation you do in javascript you have to duplicate on the server side). the third is bandwidth.
we'll need to move beyond the web before we get there. an internet app toolkit with the strengths of the web would be just fine.
FWIW I'm a senior web developer with plenty of apps behind me.
An insightful point, but the situation is still murky. What part of the code is the idea and what part is the embodiment? Specifically, are the algorithms covered under the copyright?
Yes, the goals of the patent system are good. But the implementation strikes me as industrial age, out of sync.
It is not clear how patent law should apply to current technology. 17 years may be too long in some cases and not long enough in others. And the boundary between invention and discovery is unclear now that literature and machines are both reduceable to source code. Should novels be patentable? Should machines be copyrighted?
If you spent 1960-1970 inventing the internet (assuming that it's inventable), no such thing existed, you did contribute substantial insights, and in general this was a legally defensible patent, would the patent be morally defensible?
If Gutenberg had patented the printing press, would that be legitimate? The right to publish your speech is fundamental in the developed countries. Would we really be willing to trade a free press for one limited to those who can afford to pay patent royalties?
The RSA algorithm is the standard, and because of that it is nearly impossible to build encryption software without paying the RSA corporation. But the price of RSA is unfuckinbelievable - around $25K if they'll let you use it at all. So a great deal of encryption software is never created. If you accept that the value of encryption to society is large, then society is paying a significant cost here.
My point is that the concept of intellectual property is fundamentally flawed. I would prefer to change the definition of what is patentable to things that are created as opposed to discovered. The distinction I would draw is whether it is plausible for someone else to create exactly the same thing.
The probability of getting Hamlet by random combinations of letters is so low that it basically doesn't exist. This is not true for the Pythagorean theorum, or RSA, or the Internet.
Slashdot Mirror
There's nothing stopping you from lopping off the jack and doing a direct connect from the adapter wires to the battery terminals. Not convenient, and ugly by some standards, but easy as pie.
We've never seen a really clean text based UI. vi, lotus 1-2-3, xywrite and emacs, for all their qualities, are based on stone age UI standards. Imagine if Stallman had done usability testing - it would have been completely different.
Graphical != Usable. Graphical widgets can present so much distracting information that users can't find the important stuff. Toolbars, dialog boxes, non monospaced fonts - a lot of gingerbread is destructive to UI quality.
Where character based UIs fall down is in visual functionality - desktop publishing or image editing. But that's not such a big problem for all apps.
Wait! It's not that simple! Open source competes against secret source on a different time scale.
Open source uses accretion, and operates on geological time. Drip, drip, drip. Slow accumulation of itches scratched... Secret source uses huge amounts of manpower and operates on mtv time. Secret source will often have the edge in the short term. So when things are changing rapidly secret source will be able to compete. It's when a market settles down that open source is unstoppable.
Word processors are a mature technology; we have parity in open source word processors. HTML is a mature technology; we have HTML parity. There is a new RealPlayer twice a day; we do not have parity.
Consumers should be able to make their own choice according to their values. Tell 'em it's ol' faithful open source VS. sexy but undependable secret source. Let there be a choice.
(Don't flame me for suggesting that open source methods can't compete in a fast moving situation! They can at exceptional moments - like the present - when heavy hype has made large numbers of people available for work - but at less visible moments progress will become glacial again!)
Applix Anyware has a java powered thin client that is smart enought to run dialog boxes, redraw widgets, and do other trivial things without going back to the server. This is exactly what X, not to mention http/html, is missing. Sure would be useful for better freemail clients, among other things.
I suggest we move this discussion to Cosource.com. Let people who want a solution vote by submitting a request, committing a few bucks, or making a proposal.
I would submit a request myself, but also want to make a proposal.
Certificates/PKis etc. are just too heavy for people at this point, even technical people. Nobody gets it. Check out the level of technical sophistication in this conversation alone - it's unusually clueless for slashdot.
(I'm not a specialist, BTW, but I did have to do a basic crypto coding job recently so I had to figure out the basics).
It is common for implementors of internet enabled apps to need to pass messages back and forth. Since the only way past the corporate fireway is via the proxy, these apps have no choice but to overload http. Applix Anyware, among many, does this. SOAP is a standardization of this practice.
CORBA is too heavyweight for these applications. Worse, a corba-over-http bridge must be used to get out via the proxy.
Without SOAP implementors will keep writing custom implementations over and over again. Thus SOAP is a Good Thing because it lets us code this once and for all and move on.
Equifax certs don't support DSA. It's RSA or squat.
(at least according to the guy at Equifax who generated my cert.)
and Thawte does indeed have the greatest test facility. I found them very coder-friendly, intelligent, useful.
html/jscript etc is a basically unusable dev environment for a lot of applications. the biggest problem is statelessness. the second biggest problem is javascript bugs - you absolutely must not depend on javascript. (part of the problem with jscript is that a user isn't required to be using it - any validation you do in javascript you have to duplicate on the server side). the third is bandwidth.
we'll need to move beyond the web before we get there. an internet app toolkit with the strengths of the web would be just fine.
FWIW I'm a senior web developer with plenty of apps behind me.
An insightful point, but the situation is still murky. What part of the code is the idea and what part is the embodiment? Specifically, are the algorithms covered under the copyright?
Yes, the goals of the patent system are good. But the implementation strikes me as industrial age, out of sync.
It is not clear how patent law should apply to current technology. 17 years may be too long in some cases and not long enough in others. And the boundary between invention and discovery is unclear now that literature and machines are both reduceable to source code. Should novels be patentable? Should machines be copyrighted?
The concept of patentability needs work.
If you spent 1960-1970 inventing the internet (assuming that it's inventable), no such thing existed, you did contribute substantial insights, and in general this was a legally defensible patent, would the patent be morally defensible?
If Gutenberg had patented the printing press, would that be legitimate? The right to publish your speech is fundamental in the developed countries. Would we really be willing to trade a free press for one limited to those who can afford to pay patent royalties?
The RSA algorithm is the standard, and because of that it is nearly impossible to build encryption software without paying the RSA corporation. But the price of RSA is unfuckinbelievable - around $25K if they'll let you use it at all. So a great deal of encryption software is never created. If you accept that the value of encryption to society is large, then society is paying a significant cost here.
My point is that the concept of intellectual property is fundamentally flawed. I would prefer to change the definition of what is patentable to things that are created as opposed to discovered. The distinction I would draw is whether it is plausible for someone else to create exactly the same thing.
The probability of getting Hamlet by random combinations of letters is so low that it basically doesn't exist. This is not true for the Pythagorean theorum, or RSA, or the Internet.