Both "Brave New World" and "1984" both describe societies with the same three key problems - both societies are structured to stay unchanged indefinitely, both societies place no value on individual rights, and both societies have successfully encompassed all of humanity.
As long as we can keep separate sovereign nations some of which value individual rights, we should be reasonably safe from the utter nightmare scenarios that those books describe - even if some fraction of people are stuck in places like North Korea.
The last time I messed with it it was pretty straightforward. Is it somehow more complicated now than "type in some name/version info for the release, upload a source tarball"?
About the only thing it has going for it is a large user base and shell accounts.
Well, that and free web hosting for the project site.
If that were true, it wouldn't take 16 kLoC for a driver. With that much code, it's exposing quite a bit of hardware-specific functionality - which means hardware acceleration for something.
Most of those refer to government editing of published works. Personally, I like the first sentence in the Wikipedia entry:
Censorship is the removal or withholding of information from the public by a controlling group or body.
Note that it's not about what you refer to as "speech" at all. It's about publicly available information.
Going further, I would claim that the phrase "freedom of speech" doesn't refer simply to any speech, but to those forms of communication that are subject to censorship. That doesn't include (falsely) yelling "fire" in a crowded theater, because such an utterance doesn't communicate any information to the public that couldn't be communicated without committing the (non free speech related) crime of reckless endangerment.
Yes, that does mean that the phrase "freedom of speech" has a different meaning than simply interpreting the individual words as strung together would imply - but that sometimes happens with natural languages.
What you are saying is that speech used to commit a crime should not be free, but you don't want to admit that it is in fact speech being censored, so you redefine it as some kind of "unspeech".
Hmm... apparently you're resorting to the tactic of defending your definition of a disputed word in the face of my attempt to clarify a concept.
I'm not really interested. If you can't differentiate between censorship and laws against crimes like "fraud", "accessory to murder", and "Reckless endangerment" *AND* you're unwilling to recognize my attempts to find a line of differentiation then we're not going to be able to have a useful discussion.
Spam is a social problem, not a technical one. There is no such thing as a technical solution to a social problem.
That's generally true.
The problem is that SMTP makes it drastically worse than it needs to be with a push model. The spammer can send a million messages, and they've all already been accepted by the destination server before anyone has a chance to complain.
If it were a notification / pull model then when someone complained the ISP could pull the spammer's plug for a TOS violation before most of the messages in his first batch were delivered. Sure, that doesn't kill the spam problem utterly dead - but it does mean that current spam management resources could keep it down to well under 90% of all email.
Oh come on. You're just intentionally misunderstanding the concepts involved here.
Freedom of speech in no way means that just because someone's action involved making noises with their mouth they couldn't possibly have committed a crime. It means that they shouldn't be prevented from communicating their thoughts and ideas with any willing audience.
You're also misunderstanding the meaning of the word "censorship". Censorship is when an authority (like a government) *prevents* communication based on its intellectual content. Arresting someone for the content of their speech isn't censorship except perhaps indirectly through its chilling effect on future speech. It's a violation of freedom of speech, but it's not directly censorship.
It's just as bad to NEVER INVENT something as to not sell it, or to sell it at high prices.
If that were really the choice, then I would agree with you completely. But in reality if Bob doesn't invent something today then Charlie will likely invent it next year, or Dave the hobbyist will invent it in a decade when the field becomes widely understood.
Thinking about "NEVER INVENT" is absurd. The best case for patents is that they cause something to be invented sooner. And patents that last for 20 years are only a good deal if they, on average, cause inventions to be published more than 20 years sooner than they otherwise would be.
Neither of us have any solid figures comparing the date of publications of inventions with or without patents - I can't even think of any way to collect that data - but a claim that patents speed up innovations by more than 20 years in todays high tech fields is obviously absurd.
You are ignoring the primary reason why people contribute to F/OSS software: It doesn't do what they want it to, so they just fix it and share the results.
That may seem like incomprehensible altruism to you, but it just seems like simple fair play to the people who do it. Others did a bunch of work to get them program X, they've done the work to give it feature Y anyway, sharing feature Y costs them nothing so they do it. Hell, it could even convince other people to contribute more useful functionality.
While the cowboys and attention whores you mention are the most *visible* of F/OSS contributors (naturally), the majority just want the software that they use to do what they need better and are willing to do the coding and share their improvements.
despite the fanatical rantings of RMS and other drinkers of the Koolaid, most people who are using computers aren't going to be able to "hack the code" even if all the specification are open and all the necessary information is available.
I don't care if Joe Random Guy can hack the code. There are six billion people in the world - the bet is that *someone* will be willing to hack and share. In practice, that's usually a good bet.
Things don't happen instantly, and corporate performance is measured by quarterly profits.
Linux machines would have to go from like 3% to like 30% of a vendor's sales in a single quarter in order for it to be worth Microsoft raising the OEM Windows license cost by 50%.
The original company doesn't have to do this (since, as the author, it doesn't have to release its own changes).
That strategy breaks down as soon as they incorporate anyone else's changes into their version. The GPL doesn't require any copyright assignments, so the product would then have two separate copyright holders - and both are bound to release their changes in order to meet the GPL license on the other one's code.
There are rarely free lunches when it comes to computer system configuration choices - and when there are free lunches, you can be sure that the hardware / software will be using that configuration by default.
The safest bet is this: If you aren't sure that you understand the trade-off you are making by using a tool like LVM, you should assume that it's going to come back and bite you in the ass. This isn't just true for software stuff either, hardware RAID 0 has basically the same reliability issues - but it's still sometimes the right engineering choice for someone who understands the trade-offs.
Sure, in practice you optimize bottlenecks - frequently by writing modules in lower level languages. The same is true for concurrency issues - the amazing lock-free data structure or message passing primitives are going to be written in low level code (probably with assembly for atomic compare and swap).
But... that doesn't change the fact that 99% of code will never need to be optimized like that, and trying to optimize code that doesn't need it usually just results pointless obfuscation and wasted programmer time (both to do it and to debug it later).
I think you've misunderstood my argument. Let me try to state it clearly.
1.) The only thing that has any effect on "the market" is sales of new hardware.
2.) It is possible to select readily available hardware to build computers such that it is fully supported under any up-to-date GNU+Linux distro.
3.) Any agent making market choices can therefore select hardware that works (with free drivers) to go with their software.
4.) A group of major resellers has declared their intention to favor such hardware.
5.) Therefore, it's too late to gain much market benefit by creating new proprietary Linux drivers in hardware markets where free drivers are already available for an existing product.
6.) Therefore, rational hardware vendors who have not already done so will release free drivers and/or specs for their hardware.
These things don't happen quickly. We won't see the effects of the ATI documentation release until at least the end of the year, but the market inflection point where blob drivers are relevent has already passed - the vast majority of what we will see from here on out is new free drivers.
If you're coding for cell phones, that may be relevant. When it comes to embedded systems the hardware is one of the design parameters that the developers control. For desktops, any reasonably modern system is fast enough that paying abstraction penalties is fine - if it's too slow you can use a different algorithm or make the task simpler.
If you don't think that we should be using hardware advances to make things easier on programmers, then why do you use compilers? Compared to hand-tuned machine code specific to each target processor, the stuff that comes out of a C compiler is slower by a factor of 2 to 10 at least. Other languages even more so.
The fact of the matter is that high level tools are almost always the right choice, and the standard rules of optimization apply:
Rules of Optimization:
1. Don't do it.
2. (experts only) Don't do it yet.
With concurrent code that's just as true as it ever was. If you can use an abstraction that makes thing easier to understand, you'll get the project finished on time and stable. On time and stable trumps 3% faster with deadlocks a year late *every single time*.
You're not going to get anywhere by complaining about flame wars between the OpenBSD guys, the GNU guys and the Linux guys. They disagree, and all three groups have people with forcible personalities and no reason not to start a flame war. RMS was asking for it this time. Linus was asking for it last time. Theo was asking for it the time before that.
All of these groups create very solid software - and creating a modern free OS distribution currently requires software from at least two of the groups (gcc and OpenSSH are in everything these days). I see no downside to letting them continue to flame each other - it hasn't slowed any of them down in the 7+ years I've been watching them do it.
For exactly the opposite reason from what you'd probably expect. Flame Wars = Ad views, and Slashdot has been working for years to create an atmosphere where RMS's concept of "free software" is flame war material. gNewSense article = "free software" flame war. OpenBSD is just a solid OS, and therefore triggers no flame war (except when Theo starts one - those always get full articles).
Have you actually used it? Did you try the old version?
If not, why do you have an opinion on it at all? If so, what specifically is wrong with it.
Personally, I've been using it for a while now and it works fine - most messages are a single line and having the text box grow by a line when I exceed the length of a line is wonderfully convenient.
The hardware that you happen to have is irrelevant to my argument. Sure, if you buy random hardware you'll probably get some that doesn't have in-kernel drivers. If you wanted to actually chose hardware intentionally though you'd have little trouble finding hardware with full in-kernel (or in-X.org) support.
The latter is the only property that really matters to anyone except for hobbyists trying to install stuff on their old computers. If Dell wants to build machines that work perfectly, they can do that today (and they do it). If they want to favor vendors who have in-kernel drivers, they have that option (and they've declared that they'll do so).
There may never be drivers for the hardware that you already have - but that doesn't matter in the market at all, because that hardware has already been sold. If you want to buy new hardware (buy - that means that it matters to the market), you can chose supported hardware.
Slashdot Mirror
Both "Brave New World" and "1984" both describe societies with the same three key problems - both societies are structured to stay unchanged indefinitely, both societies place no value on individual rights, and both societies have successfully encompassed all of humanity.
As long as we can keep separate sovereign nations some of which value individual rights, we should be reasonably safe from the utter nightmare scenarios that those books describe - even if some fraction of people are stuck in places like North Korea.
The last time I messed with it it was pretty straightforward. Is it somehow more complicated now than "type in some name/version info for the release, upload a source tarball"?
Well, that and free web hosting for the project site.
If that were true, it wouldn't take 16 kLoC for a driver. With that much code, it's exposing quite a bit of hardware-specific functionality - which means hardware acceleration for something.
So... we disagree on the definition of censorship. The only effective argument that leaves me with is to bring in references. How about a stack of them: http://www.google.com/search?hl=en&q=define%3A+censorship
Most of those refer to government editing of published works. Personally, I like the first sentence in the Wikipedia entry:
Note that it's not about what you refer to as "speech" at all. It's about publicly available information.
Going further, I would claim that the phrase "freedom of speech" doesn't refer simply to any speech, but to those forms of communication that are subject to censorship. That doesn't include (falsely) yelling "fire" in a crowded theater, because such an utterance doesn't communicate any information to the public that couldn't be communicated without committing the (non free speech related) crime of reckless endangerment.
Yes, that does mean that the phrase "freedom of speech" has a different meaning than simply interpreting the individual words as strung together would imply - but that sometimes happens with natural languages.
Hmm... apparently you're resorting to the tactic of defending your definition of a disputed word in the face of my attempt to clarify a concept.
I'm not really interested. If you can't differentiate between censorship and laws against crimes like "fraud", "accessory to murder", and "Reckless endangerment" *AND* you're unwilling to recognize my attempts to find a line of differentiation then we're not going to be able to have a useful discussion.
That's generally true.
The problem is that SMTP makes it drastically worse than it needs to be with a push model. The spammer can send a million messages, and they've all already been accepted by the destination server before anyone has a chance to complain.
If it were a notification / pull model then when someone complained the ISP could pull the spammer's plug for a TOS violation before most of the messages in his first batch were delivered. Sure, that doesn't kill the spam problem utterly dead - but it does mean that current spam management resources could keep it down to well under 90% of all email.
Oh come on. You're just intentionally misunderstanding the concepts involved here.
Freedom of speech in no way means that just because someone's action involved making noises with their mouth they couldn't possibly have committed a crime. It means that they shouldn't be prevented from communicating their thoughts and ideas with any willing audience.
You're also misunderstanding the meaning of the word "censorship". Censorship is when an authority (like a government) *prevents* communication based on its intellectual content. Arresting someone for the content of their speech isn't censorship except perhaps indirectly through its chilling effect on future speech. It's a violation of freedom of speech, but it's not directly censorship.
If that were really the choice, then I would agree with you completely. But in reality if Bob doesn't invent something today then Charlie will likely invent it next year, or Dave the hobbyist will invent it in a decade when the field becomes widely understood.
Thinking about "NEVER INVENT" is absurd. The best case for patents is that they cause something to be invented sooner. And patents that last for 20 years are only a good deal if they, on average, cause inventions to be published more than 20 years sooner than they otherwise would be.
Neither of us have any solid figures comparing the date of publications of inventions with or without patents - I can't even think of any way to collect that data - but a claim that patents speed up innovations by more than 20 years in todays high tech fields is obviously absurd.
You are ignoring the primary reason why people contribute to F/OSS software: It doesn't do what they want it to, so they just fix it and share the results.
That may seem like incomprehensible altruism to you, but it just seems like simple fair play to the people who do it. Others did a bunch of work to get them program X, they've done the work to give it feature Y anyway, sharing feature Y costs them nothing so they do it. Hell, it could even convince other people to contribute more useful functionality.
While the cowboys and attention whores you mention are the most *visible* of F/OSS contributors (naturally), the majority just want the software that they use to do what they need better and are willing to do the coding and share their improvements.
I don't care if Joe Random Guy can hack the code. There are six billion people in the world - the bet is that *someone* will be willing to hack and share. In practice, that's usually a good bet.
Things don't happen instantly, and corporate performance is measured by quarterly profits.
Linux machines would have to go from like 3% to like 30% of a vendor's sales in a single quarter in order for it to be worth Microsoft raising the OEM Windows license cost by 50%.
That strategy breaks down as soon as they incorporate anyone else's changes into their version. The GPL doesn't require any copyright assignments, so the product would then have two separate copyright holders - and both are bound to release their changes in order to meet the GPL license on the other one's code.
There are rarely free lunches when it comes to computer system configuration choices - and when there are free lunches, you can be sure that the hardware / software will be using that configuration by default.
The safest bet is this: If you aren't sure that you understand the trade-off you are making by using a tool like LVM, you should assume that it's going to come back and bite you in the ass. This isn't just true for software stuff either, hardware RAID 0 has basically the same reliability issues - but it's still sometimes the right engineering choice for someone who understands the trade-offs.
How many 10 year old books are still read today?
If games are somehow less culturally significant than books, then why do they deserve copyright protection at all?
Multicast doesn't magically help with every possible application, but it *would* help with classical block-based P2P file trading.
Sure, in practice you optimize bottlenecks - frequently by writing modules in lower level languages. The same is true for concurrency issues - the amazing lock-free data structure or message passing primitives are going to be written in low level code (probably with assembly for atomic compare and swap).
But... that doesn't change the fact that 99% of code will never need to be optimized like that, and trying to optimize code that doesn't need it usually just results pointless obfuscation and wasted programmer time (both to do it and to debug it later).
I think you've misunderstood my argument. Let me try to state it clearly.
1.) The only thing that has any effect on "the market" is sales of new hardware.
2.) It is possible to select readily available hardware to build computers such that it is fully supported under any up-to-date GNU+Linux distro.
3.) Any agent making market choices can therefore select hardware that works (with free drivers) to go with their software.
4.) A group of major resellers has declared their intention to favor such hardware.
5.) Therefore, it's too late to gain much market benefit by creating new proprietary Linux drivers in hardware markets where free drivers are already available for an existing product.
6.) Therefore, rational hardware vendors who have not already done so will release free drivers and/or specs for their hardware.
These things don't happen quickly. We won't see the effects of the ATI documentation release until at least the end of the year, but the market inflection point where blob drivers are relevent has already passed - the vast majority of what we will see from here on out is new free drivers.
If you're coding for cell phones, that may be relevant. When it comes to embedded systems the hardware is one of the design parameters that the developers control. For desktops, any reasonably modern system is fast enough that paying abstraction penalties is fine - if it's too slow you can use a different algorithm or make the task simpler.
If you don't think that we should be using hardware advances to make things easier on programmers, then why do you use compilers? Compared to hand-tuned machine code specific to each target processor, the stuff that comes out of a C compiler is slower by a factor of 2 to 10 at least. Other languages even more so.
The fact of the matter is that high level tools are almost always the right choice, and the standard rules of optimization apply:
With concurrent code that's just as true as it ever was. If you can use an abstraction that makes thing easier to understand, you'll get the project finished on time and stable. On time and stable trumps 3% faster with deadlocks a year late *every single time*.
Luckily, unlike caffine, the functional alternatives to Windows are legal.
You're not going to get anywhere by complaining about flame wars between the OpenBSD guys, the GNU guys and the Linux guys. They disagree, and all three groups have people with forcible personalities and no reason not to start a flame war. RMS was asking for it this time. Linus was asking for it last time. Theo was asking for it the time before that.
All of these groups create very solid software - and creating a modern free OS distribution currently requires software from at least two of the groups (gcc and OpenSSH are in everything these days). I see no downside to letting them continue to flame each other - it hasn't slowed any of them down in the 7+ years I've been watching them do it.
For exactly the opposite reason from what you'd probably expect. Flame Wars = Ad views, and Slashdot has been working for years to create an atmosphere where RMS's concept of "free software" is flame war material. gNewSense article = "free software" flame war. OpenBSD is just a solid OS, and therefore triggers no flame war (except when Theo starts one - those always get full articles).
Have you actually used it? Did you try the old version?
If not, why do you have an opinion on it at all? If so, what specifically is wrong with it.
Personally, I've been using it for a while now and it works fine - most messages are a single line and having the text box grow by a line when I exceed the length of a line is wonderfully convenient.
The hardware that you happen to have is irrelevant to my argument. Sure, if you buy random hardware you'll probably get some that doesn't have in-kernel drivers. If you wanted to actually chose hardware intentionally though you'd have little trouble finding hardware with full in-kernel (or in-X.org) support.
The latter is the only property that really matters to anyone except for hobbyists trying to install stuff on their old computers. If Dell wants to build machines that work perfectly, they can do that today (and they do it). If they want to favor vendors who have in-kernel drivers, they have that option (and they've declared that they'll do so).
There may never be drivers for the hardware that you already have - but that doesn't matter in the market at all, because that hardware has already been sold. If you want to buy new hardware (buy - that means that it matters to the market), you can chose supported hardware.
Good: You're trying to recognize privacy problems.
Bad: You apparently don't understand the problem well enough to differentiate problems from non-problems.