You're missing the fact that each of these services, while they are all peer-to-peer, are not synonymous or intended for the same purposes. That's like saying "file-transfer's been done in FTP, why should we be able to do it over e-mail or ICQ or rcp, etc."
Napster is the mother of all ftp-lists, a giant database of MP3s on various hosts. This comes at the price of anonymity and stability (i.e. distribution).
Gnutella maked up for some weaknesses of Napster, namely its central server. This comes at the price of scalability.
Freenet makes up for similar (centralization) weaknesses in file sharing technologies like FTP and HTTP, mainly by decentralizing ALL control of content, ensuring anonymity, and ensuring that in-demand content is always available. This comes at the price of searchability.
Mojo Nation overcomes the freeloader weakness of Napster, by forcing users to pay for content they consume and compensate those who contribute the most resources. This is at the price of simplicity.
I certainly wouldn't want to be restricted to one service that combined all of these ideas; it would be slow, complicated, hard to search, and so on. Diversity is good! Open-source is evolution in the computer world, and inbreeding has costs.
I think the point of most moderation schemes can be summarized as so:
Make sure the consistently intelligent posters can be seen.
Make sure the consistently stupid posters can't be seen.
Make sure that someone with a single flash of brilliance has a chance at being seen.
The fact is, nobody's willing to do the work to make sure that the best comments get seen by everyone, every time. It's an impossible task. So instead, moderation makes sure the best people get seen and hope they keep the level of discussion up. It's not the ideal, but it's a compromise, and it usually works.
(Think of the Street Performer Protocol: you're not paying for the product, you're paying for the producer, and the products are a byproduct. Same with moderation; good comments are a byproduct of smart people.)
Don't be silly; the proper analogy would be buying a new-fangled rubik lock which nobody has ever heard of and therefore nobody knows how to break. But the little-known fact is that this rubik lock is actually trivial to break (with a hammer), and once someone figures this out you're out of luck. Totally making this up, of course.
The point being, he means security through obscurity of algorithm, and you're talking about security through obscurity of data. Different things.
Mozilla is way more than a browser people, yet you continue to treat it like it's one.
Well, how else are we supposed to treat it? As a mail client / news reader / chat client / whatever-the-hell-else it's not competitive with other products in those domains. As a web browser it's not so hot either, come to think of it, although at least it has Gecko.
As a cross-platform toolkit, it's a horribly misguided mistake. The premise behind Mozilla is that developers should be able to write an application/interface once and have it run on anything, looking exactly as they intended it. That's a bad idea to begin with; different OSes have different interface conventions, and those MUST be followed to create a usable product. Who cares if it looks the same in X and Windows? How many people do you know that regularly switch between the two for whom interface consistency is a big concern?
And the worst part is you get the lowest common denominator and can't take advantage of a system's built-in functions; Mozilla has to basically re-impliment the clipboard on every system and it sucks. Not to mention it fails to conform to any interface standards, and native users hate it (see comments about Mac versions, for example).
Skinnability and cross-platform UIs are fine and good for simple applications like web sites and media players, but have no place in such a crucial application as a web browser or e-mail client.
Here's what I believe he's saying, although I'm not sure I agree:
A patent is a quid-pro-quo agreement between the government and the corporation. The government agrees to protect an idea for a limited time in exchange for that idea being released to the public (i.e. patent office). Under normal circumstances, if you have an idea and want to make money off of it, you want to keep the implementation secret so nobody else uses it to compete with you. This is bad for the public because you could theoretically keep your idea secret forever. It's bad for you because if someone manages to figure out or steal your idea, then you're out of luck.
A patent tries to solve both problems. Your idea is legally protected for a time so you don't have to worry about anyone stealing it. AND, your idea is opened to the public, so people can get the benefits of extending the idea.
Makes sense to me. Technically, I'm not in any more danger than usual. If I get upset and sue you, it's like a parent suing the newspaper for causing distress by reporting the latest stuff found in their child's cafeteria food.
But that's not the intent. I don't go looking at people and start staring at them to rate the clothing that they have and then make a choice on what to wear based on the fact that there is some logo or something on the clothing. That's really bad reasoning.
You may not (although I wouldn't be so sure if I were you) but everyone else does. Do you really think all the "cool" people are wearing Hilfiger because it's aesthetically pleasing or well-made? Excuse me while I laugh my ass off. They wear it because they see other "cool" people wearing it. That's the beauty of name brands.
A lot of people misunderstand the author, take the word "privelege" out of context, and overreact.
Ever heard of HAM radio? To get an operating license you have to understand the technology well, know morse code, agree to quite a few regulations, and generally "earn the privelege" to use it. The reason is that radio frequencies are a limited resource and nobody can afford to have it used irresponsibly. That's why HAM hasn't gone the way of the internet.
With a car, if you fail to maintain it or "appreciate" it, the only person suffering a loss is yourself. With broadband, if you are irresponsible about making your box secure, you could contribute to DoS attacks, virus transmission, etc. It is, to a lesser degree, like buying a semi-automatic and then putting it on the sidewalk for some kid to find and shoot themselves with.
The author's point was that people who don't understand the responsibilities that come with the technology shouldn't be permitted to use it. If necessary, they can educate themselves and earn the privelege. Seems reasonable to me.
"The only truly intuitive interface is the nipple." I think Tog said this. The point is, almost nothing you do hasn't been learned with a lot of effort and brainpower.
The point of interface design is not, as you imply, to make them easy to use for people who have never seen one before, but to make them easy to use for people who have learned how to use them.
Yes, but in this case it's more like someone conned the president of the bank into giving out access to everyone's accounts. I'd sure as hell sue any bank president that stupid.
Gnome doesn't need The App That Does Everything (neither does KDE, for that matter). All that does is lead to bloat, redundant apps on a system, and confusion for new users.
I just want to point out that one of the best things about Nautilus is the way it uses Bonobo. Because it's componentized, bloat and redundancy are not problems, and confusion is actually reduced by allowing you to do basic interaction with data in a standardized interface and environment.
They're not creating an app that does everything; you won't be editing documents or writing HTML in Nautilus, or really doing anything at all other than basic file management. But the point is to extend "basic file management" to include more intelligent handling of attributes. Right now file managers only know byte size, and date created, and filename, but this is not how information works in your mind; you don't organize your ideas by "ideaname." The file manager should know things about the file, like what it looks like if it's an image, or how long it is if it's a sound, or what the content is if it's a text file.
You're right about information being the key to control in any conflict. But somehow the image of some grassroots movement of "common men" trading "dangerous" information like MP3s over the internet and using it to take down the US military just makes me roll on the floor laughing.
I'm sorry, but the "common man" hasn't got balls or a clue, and those that do don't hang out in the same internet you or I do. To your average citizen, the Internet's just another source of media force-feeding.
I'm tired of hearing Perl programmers whine about how "Perl doesn't write unreadable programs, programmers do." Stereotypes may be stereotypes, but they don't come from nowhere. This defense makes me wonder why it is Perl seems to draw so many bad programmers.
Not to knock Perl; I compare it to English. A mishmash of syntax, but very effective and capable of expressing complexity succinctly and cleverly. What makes Perl bad is the power it grants to use inconsistent/confusing syntax and programming style. There's More Than One Way To Do It means that you did it differently from me and I'm going to waste time figuring out why if I ever look at your code. Sure, you can write clean, tidy Perl code, but if you're going to all that trouble you're not taking full advantage of the flexibility of the language, so why the heck are you writing in Perl anyways? Better off using Python, which not only allows you to write nice code but does a much better job of enforcing it.
- Don't you hate it when people use reverse psychology to get moderated up? I'll just tell ya': moderate me up all you want!
*sigh* I always hear usability people whining about stuff like this. You sound bitter. I understand. Having worked on both sides of the fence, as a usability engineer and a developer, I agree that most developers' understanding of user experience is abysmal.
BUT, that doesn't change the fact that usability is a feature (or set of features). It is an interface. A layer. No more. It's a very big feature, and a very important one, and one which permeates many aspects of design, but the fact is how the user interacts with the program and how the program operates can be completely orthogonal, hence usability can be added on like anything else.
You bring up several points:
Usability permeates architecture. This is no more true of usability than aesthetics, or practicality, or efficiency, or any number of goals towards which features can be aimed. A usability feature request by end-users is no different from any other feature request, and no more difficult to implement simply by virtue of it being for usability.
""I don't want my thermostat turning my lights on and off, even if it does contain a convenient timing circuit." Yes, but someone else may. Where usability comes in is in dictating how you wire your circuits together, and how you tell your lights to turn on and off, and things like that. If the thermostat and lights share a timer for flexibility reasons, the end user need never know about it, and it's usability engineers' job to hide/simplify flexibility when necessary. That doesn't mean that flexibility is bad.
"Developers are not valid users for this purpose [of usability testing]." Why not? We're humans like everyone else. And we're end-users. Granted, we're a demographic slice of end-users whose goals and needs are not always those of the majority, but I'm tired of this bullshit that usability means designing for the lowest common denominator. It means designing to meet someone's needs. A usable program will be usable by those who need to use it. Right now, Joe Q. Public does not need, or want, to use Linux. But that will change. And many developers are clearly interested in designing interfaces and applications that make the power of Linux more accessible.
To illustrate: the unix command line is one of the most usable interfaces I've ever seen; a person who has been using it for years can be twice as efficient as someone who has used a GUI for the same length of time.
It's like a piano; sure, it takes years to learn to play it, but would we have George Winston and Keith Jarrett and Beethoven etc. if you played by choosing notes from a graphical menu? Nobody complains that pianos are unusable, because it's understood that it takes great skill to play one. One big problem I see with the usability industry is that it doesn't make clear conceptual distinctions between human modes of learning, and doesn't address the principle of transitioning people from initially easy-to-use to expert-efficient. I want to be able to code like I play the piano; just directly pour out my ideas in some way, and not worry about working around all the layers put there by well-intentioned designers.
Actually, it's much less confusing if you see things like "w" and "$" etc. as verbs (go to w). Nouns are arguments, which w is not really. So you really just have adjective-verb.
Create lightweight desktop applications not with configurability, but simplicity in mind. Avoid redundant functionality (i.e. button bars doubling menu entries). Most of these apps are already there, just port them to a common toolkit (fltk, for example).
I'm not sure why you threw in "avoid redundant functionality," but I have to point out; duplicating functionality where convenient is a common (and wise) practice in interface design. The point is to have a consistent, easy to find location for a function (i.e. in a menu), but also have it convenient when needed.
Reduce inter-application interfaces to classic Unix pipes, sockets and libraries. Avoid bloat and slowdown through Corba and similar interfaces.
Which causes more bloat and slowdown, a component-based system where common components can be shared across applications when needed, or a system where every program needs to build its own functionality from libraries? So, what, we embody an entire HTML-editing component and interface in a library? We increase development (and package management) headache exponentially for... what?
As for pipes and sockets, I can't wait to hear how your GUI OS makes these easier to use than drag-and-drop embedded components. Or how you explain pipes and sockets to your grandmother.
Having just turned 18 myself, I can tell you that psychologically, neurologically, physically, etc., there is a difference between a 12-year-old and an 18-year-old, especially in terms of their ability to deal with and understand sex.
True, stopping someone from viewing porn if they want to won't make them more moral. The point is to protect a child from seeing it accidentally, (for example, someone leaving it on the screen as a prank as was pointed out earlier).
I don't agree with the head-in-the-sand philosophy Americans have towards protecting minors from sex, but premature exposure to sexuality can be harmful. The best defense is to raise kids so that they are open-minded and capable of dealing with something unexpected like that, but we can hardly place our faith in the quality of American parenting.
I could fit the things I know about Real Programming into a small thimble, but I'm thinking reference counting in this case isn't for memory management in the same way it is in language-specific OOP, but for tracking the use of distributed components.
How else would one manage component lifecycle? Somebody clue me in, if only with an "Only a stupid luser wouldn't know that language blah has been doing it with blah much better way for years!"
most females... do not like technical fields. Frankly the crap about gender imbalance to access computers is a load of bull
I might agree with this if "technical fields" wasn't such a ridiculously broad term. It's like saying guys can't grasp "liberal arts." I will agree completely that men and women are different, even when it comes to the ability to solve certain problems or work in certain jobs. But the kind of thinking which is encompassed by "technical fields" is just basic intelligence coupled with an interest in the way things work.
An analogy to writing (i.e. a book) is in order. On one hand you have Tom Clancy and Isaac Asimov, on the other Nora Ephram, and while most people can agree they're all good writers, but the subjects they approach and the way they approach them vary widely. Computers are so flexible that they can and will accommodate the perspectives both (all?) genders bring.
Perhaps the reason there are so few women in technical fields is that even what a technical field is has been defined almost entirely by men before now. There is more to be done with computers than database tuning or meticulous coding.
Slashdot Mirror
Think how much fun it would be to, say, snap your fingers and have your secretary on your, um, finger, instantly.
I certainly wouldn't want to be restricted to one service that combined all of these ideas; it would be slow, complicated, hard to search, and so on. Diversity is good! Open-source is evolution in the computer world, and inbreeding has costs.
Hmmm imagine a beowu$%^#5...NO CARRIER
1. protocol
4. subdomain (...)
3. domain
2. TLD
5. root
6. subdirectories
etc.
How more ass-backwards can you get? Somebody please tell me there was some reason for this other than crack?
The fact is, nobody's willing to do the work to make sure that the best comments get seen by everyone, every time. It's an impossible task. So instead, moderation makes sure the best people get seen and hope they keep the level of discussion up. It's not the ideal, but it's a compromise, and it usually works.
(Think of the Street Performer Protocol: you're not paying for the product, you're paying for the producer, and the products are a byproduct. Same with moderation; good comments are a byproduct of smart people.)
i.e. theoretical billiard-ball computing.
The point being, he means security through obscurity of algorithm, and you're talking about security through obscurity of data. Different things.
Maybe they should've taken out the "idealab capital partners" label there.
Well, how else are we supposed to treat it? As a mail client / news reader / chat client / whatever-the-hell-else it's not competitive with other products in those domains. As a web browser it's not so hot either, come to think of it, although at least it has Gecko.
As a cross-platform toolkit, it's a horribly misguided mistake. The premise behind Mozilla is that developers should be able to write an application/interface once and have it run on anything, looking exactly as they intended it. That's a bad idea to begin with; different OSes have different interface conventions, and those MUST be followed to create a usable product. Who cares if it looks the same in X and Windows? How many people do you know that regularly switch between the two for whom interface consistency is a big concern?
And the worst part is you get the lowest common denominator and can't take advantage of a system's built-in functions; Mozilla has to basically re-impliment the clipboard on every system and it sucks. Not to mention it fails to conform to any interface standards, and native users hate it (see comments about Mac versions, for example).
Skinnability and cross-platform UIs are fine and good for simple applications like web sites and media players, but have no place in such a crucial application as a web browser or e-mail client.
A patent is a quid-pro-quo agreement between the government and the corporation. The government agrees to protect an idea for a limited time in exchange for that idea being released to the public (i.e. patent office). Under normal circumstances, if you have an idea and want to make money off of it, you want to keep the implementation secret so nobody else uses it to compete with you. This is bad for the public because you could theoretically keep your idea secret forever. It's bad for you because if someone manages to figure out or steal your idea, then you're out of luck.
A patent tries to solve both problems. Your idea is legally protected for a time so you don't have to worry about anyone stealing it. AND, your idea is opened to the public, so people can get the benefits of extending the idea.
Makes sense to me. Technically, I'm not in any more danger than usual. If I get upset and sue you, it's like a parent suing the newspaper for causing distress by reporting the latest stuff found in their child's cafeteria food.
You may not (although I wouldn't be so sure if I were you) but everyone else does. Do you really think all the "cool" people are wearing Hilfiger because it's aesthetically pleasing or well-made? Excuse me while I laugh my ass off. They wear it because they see other "cool" people wearing it. That's the beauty of name brands.
Ever heard of HAM radio? To get an operating license you have to understand the technology well, know morse code, agree to quite a few regulations, and generally "earn the privelege" to use it. The reason is that radio frequencies are a limited resource and nobody can afford to have it used irresponsibly. That's why HAM hasn't gone the way of the internet.
With a car, if you fail to maintain it or "appreciate" it, the only person suffering a loss is yourself. With broadband, if you are irresponsible about making your box secure, you could contribute to DoS attacks, virus transmission, etc. It is, to a lesser degree, like buying a semi-automatic and then putting it on the sidewalk for some kid to find and shoot themselves with.
The author's point was that people who don't understand the responsibilities that come with the technology shouldn't be permitted to use it. If necessary, they can educate themselves and earn the privelege. Seems reasonable to me.
The point of interface design is not, as you imply, to make them easy to use for people who have never seen one before, but to make them easy to use for people who have learned how to use them.
Yes, but in this case it's more like someone conned the president of the bank into giving out access to everyone's accounts. I'd sure as hell sue any bank president that stupid.
I just want to point out that one of the best things about Nautilus is the way it uses Bonobo. Because it's componentized, bloat and redundancy are not problems, and confusion is actually reduced by allowing you to do basic interaction with data in a standardized interface and environment.
They're not creating an app that does everything; you won't be editing documents or writing HTML in Nautilus, or really doing anything at all other than basic file management. But the point is to extend "basic file management" to include more intelligent handling of attributes. Right now file managers only know byte size, and date created, and filename, but this is not how information works in your mind; you don't organize your ideas by "ideaname." The file manager should know things about the file, like what it looks like if it's an image, or how long it is if it's a sound, or what the content is if it's a text file.
The only reasonable way to do this is components.
I'm sorry, but the "common man" hasn't got balls or a clue, and those that do don't hang out in the same internet you or I do. To your average citizen, the Internet's just another source of media force-feeding.
I'm tired of hearing Perl programmers whine about how "Perl doesn't write unreadable programs, programmers do." Stereotypes may be stereotypes, but they don't come from nowhere. This defense makes me wonder why it is Perl seems to draw so many bad programmers.
Not to knock Perl; I compare it to English. A mishmash of syntax, but very effective and capable of expressing complexity succinctly and cleverly. What makes Perl bad is the power it grants to use inconsistent/confusing syntax and programming style. There's More Than One Way To Do It means that you did it differently from me and I'm going to waste time figuring out why if I ever look at your code. Sure, you can write clean, tidy Perl code, but if you're going to all that trouble you're not taking full advantage of the flexibility of the language, so why the heck are you writing in Perl anyways? Better off using Python, which not only allows you to write nice code but does a much better job of enforcing it.
- Don't you hate it when people use reverse psychology to get moderated up? I'll just tell ya': moderate me up all you want!
Very much so. It'd be interesting to see what a taxonomist has to say about this.
... open up that data haven in Kinakuta I've been dreaming about all these years.
*sigh* I always hear usability people whining about stuff like this. You sound bitter. I understand. Having worked on both sides of the fence, as a usability engineer and a developer, I agree that most developers' understanding of user experience is abysmal.
BUT, that doesn't change the fact that usability is a feature (or set of features). It is an interface. A layer. No more. It's a very big feature, and a very important one, and one which permeates many aspects of design, but the fact is how the user interacts with the program and how the program operates can be completely orthogonal, hence usability can be added on like anything else.
You bring up several points:
To illustrate: the unix command line is one of the most usable interfaces I've ever seen; a person who has been using it for years can be twice as efficient as someone who has used a GUI for the same length of time.
It's like a piano; sure, it takes years to learn to play it, but would we have George Winston and Keith Jarrett and Beethoven etc. if you played by choosing notes from a graphical menu? Nobody complains that pianos are unusable, because it's understood that it takes great skill to play one. One big problem I see with the usability industry is that it doesn't make clear conceptual distinctions between human modes of learning, and doesn't address the principle of transitioning people from initially easy-to-use to expert-efficient. I want to be able to code like I play the piano; just directly pour out my ideas in some way, and not worry about working around all the layers put there by well-intentioned designers.
Actually, it's much less confusing if you see things like "w" and "$" etc. as verbs (go to w). Nouns are arguments, which w is not really. So you really just have adjective-verb.
Create lightweight desktop applications not with configurability, but simplicity in mind. Avoid redundant functionality (i.e. button bars doubling menu entries). Most of these apps are already there, just port them to a common toolkit (fltk, for example).
I'm not sure why you threw in "avoid redundant functionality," but I have to point out; duplicating functionality where convenient is a common (and wise) practice in interface design. The point is to have a consistent, easy to find location for a function (i.e. in a menu), but also have it convenient when needed.
Reduce inter-application interfaces to classic Unix pipes, sockets and libraries. Avoid bloat and slowdown through Corba and similar interfaces.
Which causes more bloat and slowdown, a component-based system where common components can be shared across applications when needed, or a system where every program needs to build its own functionality from libraries? So, what, we embody an entire HTML-editing component and interface in a library? We increase development (and package management) headache exponentially for... what?
As for pipes and sockets, I can't wait to hear how your GUI OS makes these easier to use than drag-and-drop embedded components. Or how you explain pipes and sockets to your grandmother.
True, stopping someone from viewing porn if they want to won't make them more moral. The point is to protect a child from seeing it accidentally, (for example, someone leaving it on the screen as a prank as was pointed out earlier).
I don't agree with the head-in-the-sand philosophy Americans have towards protecting minors from sex, but premature exposure to sexuality can be harmful. The best defense is to raise kids so that they are open-minded and capable of dealing with something unexpected like that, but we can hardly place our faith in the quality of American parenting.
I could fit the things I know about Real Programming into a small thimble, but I'm thinking reference counting in this case isn't for memory management in the same way it is in language-specific OOP, but for tracking the use of distributed components.
How else would one manage component lifecycle? Somebody clue me in, if only with an "Only a stupid luser wouldn't know that language blah has been doing it with blah much better way for years!"
I might agree with this if "technical fields" wasn't such a ridiculously broad term. It's like saying guys can't grasp "liberal arts." I will agree completely that men and women are different, even when it comes to the ability to solve certain problems or work in certain jobs. But the kind of thinking which is encompassed by "technical fields" is just basic intelligence coupled with an interest in the way things work.
An analogy to writing (i.e. a book) is in order. On one hand you have Tom Clancy and Isaac Asimov, on the other Nora Ephram, and while most people can agree they're all good writers, but the subjects they approach and the way they approach them vary widely. Computers are so flexible that they can and will accommodate the perspectives both (all?) genders bring.
Perhaps the reason there are so few women in technical fields is that even what a technical field is has been defined almost entirely by men before now. There is more to be done with computers than database tuning or meticulous coding.