German censorship has mostly to do with nazis. Now if you are a nazi, that censoring will hit you pretty hard, admittedly, please note, that germany (population and even more so the government) is very sensible when it comes to the subject of nazis. That's because of our (yes i am german) history. There are still nazis in germany, but i think, many other countries have a worse problem with that. Anyway that's not the point. The point is, that a lot of german censoring (probably all) that hit the "slashdot news" probably has to do with nazi propaganda.
That is not to say, that this is a domestic problem and noone else should have a say in this, but please discriminate what is censored, and take the german history into consideration. I don't know if we're better off with respect to free speech than the USA, but i notice that there's a worldwide trend of limiting free speech rights.
As an aside i'd like to thank the allies (among them the US of A) that i don't have to live in a "national socialism" today, i consider some well defined limits to free speech rights (e.g. prohibiting to deny the holocaust and to glorify the nazis) a fair price if it prevents those assholes from spreading their lies again. I'm really happy that thousand years went over so fast i didn't have to live in them.
I don't know about the US, but in most european countries bikes are banned from sideways (unless you push them or it's obviously a toy for childs less than 5yr.). The reasoning makes sense: Anyone riding a vehicle should do so on the roads while anyone on the sidewalk mustn't endager anyone else on said sidewalk (which basically means you should choose a mode of transportation that lets you come to a halt within 3ft and doesn't endanger anyone seriously if you don't (not considering freak accidents)). I wouldn't like to walk on a sidewalk with those segways whizzing past me, would you?
It is important to consider when they had to decide which codebase to choose. Over a year ago means mozilla version less than.9.8, and while that version was already usable it was very obvious that it still needed a lot of work. I don't know the state KHTML was in at that time, but its main advantage is the smaller codebase. It's a very sound decision to keep the project overseeable and manageable. Had they used the mozilla-code they'd had to invest much more into the development, they might still depend on (parts of) the mozilla development, and it'd probably have taken much longer. The benefits of using the mozilla-codebase don't outweigh these costs considering that all apple wanted was a standalone-browser.
Over all the ruckus about HTML vs. mozilla aparently nobody noticed that Apple based their browser on an open source project and decided against doing it closed-source on their own. I think that's great news.
Sure it's a good thing for a company to make money. But if they do that by taking something away from me (e.g. free software) so they can sell it to me I don't have to agree that this is best for all concerned, do i?
It's really sickening how people get screwed over by big corporations and then even cheer them on because "it's their godgiven right to make money any way they can". No it isn't they have to play by some rules too, at least if their customers come to their senses and don't buy their products if they are screwed over by their business practices.
The important part is telling the people how and by who they're screwed, and that they can do something about it. The equation 'making money = good for business' has two sides, if people react appropriately to bad business practice and boycot then it becomes 'bad business practice = bad for business'.
You don't have to use the put-options, you simply trade them, but you could as well buy the stock after the price dropped and then use the put-options to resell it again at a higher price.
It's not like that at all, that's why they're called options. Nobody would be so silly and pay for the kind of papers you describe. Only the guy who sells the options has got the other end of the stick, meaning he has to pay for the difference if anyone makes use of their put options.
There's also BUY-options (or something like that) letting you buy stock at a fixed price sometime in the future. So if you know there's an important event in the near future that will have a huge impact on the stock price of a company (one way or the other) you can even buy PUT and BUY options, make lots of cash on one of them and throw away the other.
Maybe after some lengthy lawyering you could get rid of some of the shadier points in the EULA (but it'd probably be easier to attack them directly and not confuse the case with M$'s breach of contract). Anyway, you'd spend more on lawyers than you could ever hope to get out of this, and you couldn't ever wriggle out of basic copyright, since that's covered even without any EULA.
This example illustrates a more general problem: Lately we see more and more license changes for existing software, BitKeeper and various Microsoft products are only the most notable cases. License changes accompany updates and patches, or it's just a document on some website that changes.
Most Software isn't ever a `finished' product, it's subject to changes called `new version', `upgrade' or `patch'. Often the customers depend on having the latest version of a software, be it for security reasons, compatibility issues, or just part of a leasing contract for the software. The software makers use these changes in the software to change the license terms in the software. In the BitKeeper example, someone using BitKeeper in a large project probably depends on it, or it would at least cause a lot of additional work and delay the project to switch from BK to something else.
This means, that even subtle license changes may have a huge effect on anyone depending on that software, done right such a license change might even ruin someones business (imagine someone using free BK on some project competing with BK, and imagine BK had gone one step further and made their "no competition" clause mandatory on all new licenses. Done just a few months before some critical timeline this might have killed the whole project. Even so any project using BK for a competing open-source product would probably have a hard time or even falter).
To protect businesses from being at the whim of software-makers there should be some regulations in place, that only allow license changes within reasonable limits, and demand that such changes are announced some time beforehand, so the customers have time to react. Most companies protect their business by making sure that they can't be cut of from any resource they depend on, they should realize that software is just such a resource and enforce license terms that don't allow for ugly surprises due to one-sided changes. But since few companies have the leverage to change Microsofts license terms i think there's a need for legislation considering software license changes.
Yeah, equating some burglar breaking into a house to someone redirecting mail through a mailserver is probably a good analogy. Also, at least the second time around the guy specifically asked them to recheck his server.
Let me first state, that it's obvious that blacklists can be abused. Only until now they're the only means to get a grip on the spam problem, and that is, what gives them so much power. If there were other ways to fight spam, noone would need to rely on these blacklists. Also they apparently do more good than bad, or they wouldn't be in wide use. In the end the operators of the mailservers decide if they rely on those lists or not. Also this system can't work if there's a large overhead and every action has to be considered for two weeks before anything is done, so a flexible organisation that isn't hindered by procedural overhead is necessary or it won't work at all.
So while your statement is true that the blacklist operators wield much (maybe too much) power, they have that power because their system at least works. And one reason why there's no better way to deal with spammers is that there's no legislation in place so one could sue spammers and ruin their business.
Once you figured out the correct angles you can make glasses such that it is unnecessary to tilt the head. Also you don't need to tilt the head in an exact angle, probably anything within 15-20 degree of the correct angle will do well enough. And there's already sunglasses out there with polarisation filters.
If the person gets a cup of coffe it pretty damn better lock the screen. It's really sad to hear, that banking business not yet discovered the use of a screensaver/screenlock and sees a need to "close all applications" for a cigarette break.
Also often the "average customer" might have a legitimate interest in the data that's displayed (maybe because it's his own data about what he's discussing with a bank employee) and he will feel a bit silly if he has to put on those funny looking glasses first. Let alone walking into a bank where half the employees (all that are working with computers) wear the same kind of geeky looking glasses.
So let's conclude: This technology isn't secure against anyone who really wants the data from that screens, it only creates a false sense of security. At the same time it makes everyone in the bank (including the customers) look silly. Also there are already better ways to protect that information (screensavers, arranging displays such that customers normally can't see it, displays with a narrow viewing angle).
Maybe privacy is big in banking, but i think it's more important to avoid looking silly.
I use a blank screen for my screensaver anyway. I don't see any sense in a screensaver that wastes cycles on something that nobody will watch for more than a few seconds. But then i worked in an university lab where old MIPS-workstations were used to run jobs 24/7. Also i find screensavers to be distracting.
... or at least some reasons, why it would make sense to time the relese of information in such a way. Also that person(s) might hide their information for all the wrong reasons, maybe a crisis he predicts could be averted, given enough time, maybe the upheaval will be even greater in X years time, maybe someone else already discovered what he found and puts it to the wrong purpose... so i think someone who considers to go to great length to delay informing the world about the facts he learned should also consider if holding back that information is really the right thing, and if the mechanisms he chooses to release the information are appropriate.
I'm sory, but i fail to see a case where it would make sense to go to great lengths to keep information hidden until a specific date:
My main point is, that it's hard to announce (and why delay the revelation unless you inform at least someone who can do something in the meantime?) a discovery without revealing the identity of the person (or even worse: group) that discovered it. If he/they visibily go through a lot of trouble to hide the information, then someone will consider the information worthy enough to reproduce it. He has many options:
- ask/bribe/torture the person who discovered (whatever) to reproduce the information, or give out enough details that someone else can reproduce it. - find out what the line of work of that person was and invest heavily in that direction (virtually noone can make an important discovery today without at least working with someone or refer to other's works (oops all that queries in a scientific database may reveal a pattern)) - find a way to get at the information anyway (maybe it resided on some harddisk that wasn't overwritten 10 times, maybe the method of keeping it secret is flawed)
Also, does it make sense to reveal that information at a fixed date in the future (e.g. bouncing it of a celestial body)? How can you know now what revealing the information might do at that date, and why do you think mankind will then be "ready" for it? revealing information at a fixed date in the future makes only sense for astronomical events (an asteroid will hit earth at it's next pass near the sun (maybe 80 years from now) and you think it's better to spare mankind the upheaval for the next 70 years (but how can you know, maybe we could do something about the asteroid in 40 years from now if only we knew, maybe shooting at it with a strong laser, so gas emissions will alter the course ever so slightly).
For other discoveries it makes even less sense to hide them for a fixed time, since it's impossible to guess, how fast (and whereto) society will evolve, when scientific discoveries will provide us with a good replacement for some technology or other, and, generally speaking, when the time is 'just right'. In that case it'd probably be better to involve some kind of human intervention/judgement to determine when to reveal the discovery.
One way to do that would be to build a (not necessarily secret, depends on the discovery) "society" to guard the information. maybe politicians from different countries, people from international organisations or even corporations. Technically you could give each member (or different groups of members) part of the information which makes only sense when it's all (or a significant number of information pieces) are put together (there are codes that do that for you: e.g. give one part a oneway pad, the other the encrypted information). But that still leaves the problem, that the information might be discovered independantly, somehow cajoled out of the original discoverers, or just 'rediscovered' (it's easier to get funding for a project if you know you will discover something).
1) If you apply an e-mail to an officially sanctioned opt-out list, it is illegal and subject to fines to e-mail an unsolicited e-mail to that address.
No way will i help the spammers by providing them with a neat list of my email-addresses. Opt-out is the wrong way anyway. If someone wants to send me spam he should have to search my digitally signed entry out of an Opt-in list.
The RIAAs and MPAAs plans were to use DOS-attacks on the sites/networks which (they claim to) distribute their copyrighted content. Flooding the networks with faked mp3 or bringing servers down to their knees with faked download requests isn't breaking into systems. Not that i would consider waging DOS-wars over the internet a good thing, and yeah, i'd love to see some music exec locked away in a stinky jail (although that will never happen).
But wouldn't the proposed US-law only allow the copyright-holders to use DOS-attacks, and aren't DOS-attacks considered a lesser offense in most countries (especially if you don't break into thousends of foreign systems to misuse them but buy the necessary bandwith)?
Also who would sue those execs and set the lawyers and the police into motion to catch that evil hacking RIAA-exec? The owner of that site who probably did infringe on copyrights? The provider who only thinks about business and anyway doesn't like customers which use more bandwith than others who pay the same?
It'd be better to use political leverage: since every action has to be allowed by US-officials those officials (and thereby the USA government) can't free themselves from the responsibility for such attacks. Thus other countries can respond politically. That would be more of a threat, if those countries took it upon them to make the internet a place that can work without the US-backbones.
Aparently big corporations don't want flaws in their products exposed and prefer to use lawyers to "secure" their OS. So it's back to the days when exploits floated around in usenet-news (from untracable sources) and a worm/virus had to bring down millions of systems before the softwarecompanies admit there is a security hole?
And there i thought that those companies learned to value security over marketing issues. But obviously thinking farther into the future than 3 months is uncalled for these days. Business sense is dictated by the shareholders now, and the results are shortterm tactics without overseeing the big picture (in this case that fixing security holes is more important in the long run, than sweeping them under the carpet).
Your "example" of "driving 90 in a 55" was uncalled for, noone was driving 90, so please avoid silly "examples" that serve no other purpose than confusing the subjects.
It's nice to know who to turn to, if we want to know when to use which tools, and when civil disobedience is appropriate. Only i think that everyone should decide for himself when that point is reached, and what he thinks is appropriate to raise public awarenes for his ideas. Also it can be argued, that after the DMCA was bought by big business, and even worse legislation is in the works (CBDTPA) without any sign of a major outcry, civil disobedience is highly called for to stop things from going even farther downhill.
This is just another instance, where politicians are outselling public interests for corporate interests, it's not a separate event, and it's high time someone raises awereness of that.
You make up your statistics, so why not avoid it at all (it serves no purpose) and just say what you want to say: "Software projects consist of a huge chunk of work that is neither creative nor cool. Someone who is payed for his work (opposed to someone who does it as a hobby) is much more likeley to do the uncool parts as well as the cool ones."
The rest of your argumentation leaves some gaps:
- you leap to the conclusion that open source software is only done as an unpaid hobby. That is untrue. If someone (AOL) has enough interest in an open source project (mozilla) there will be paid jobs for open source development. Only you also get to benefit from free contributors (who do this as a hobby) and from the work of partners who are interested in the same project (while in closed source work there's so much overhead in drawing up the contracts that it's often not feasible to do joint work between corporations at a project).
- you cite "hundreds" (i assume you made up the order of magnitude) of unsuccessful open-source projects for every successful (what do you consider a success for an OS-project?) one. Well compare that to all the closed-source projects noone ever heared about and which died a silent death for whatever reason (budget ran out, management changed their mind, marketing didn't see a market, key developers changed workplace, nobody wanted to do the uncool parts (hey that can happen in closed-source development too)...). I think it's more liekley that all that cool code is used in later projects for open source projects for obvious reasons (anyone who wants can use it), so even that "stagnating projects" are still good for something.
- A big percentage of "uncool" code is just reinventing the wheel, doing something that already has been done. But code reusability is much higher for open source projects, since you can reuse code from a huge base of open source code without legal hassles, while all that nice GPLd (or similarly licensed) code is off limits for reuse in proprietary projects. Thus the percentage of "uncool" work is even higher in closed-source projects.
The argument that "uncool work" is more of a problem for open source projects than for closed source ones is neither new, nor is it completely unfounded. But the picture you draw up (all open source is hobbyprogramming, noone does the uncool parts and that is the reason so many projects stagnate) is just too onesided. It also completely neglects the benefits of open source development: code reusability, the possibility of working together at one project without occupying a horde of lawyers and swear every programmer to absolute secrecy, contributions from individuals as well as corporations all over the world who are interested in the project,...
Large corporations invest heavily in open source projects (kernel, mozilla,...) because of these benefits, and they see to it, that the boring parts get done too. The question isn't just if some programmers hobby can result in a better product than a project some corporation invested millions of dollars in (even that is possible, many of the OS-projects that are now backed by the big industry already got a far way on their own), but also if (and for which projects) someone/a corporation considers open source development superior to closed source development.
TreoCentral also offers this explanation and it explains why Handspring doesn't announce this feature. But TreoCentral also mentions, that it might cost about $5 per device to include the Flash-Rom. But Flash-Rom, and the ability to upgrade your OS is a great sales argument, so i wonder if the value-add isn't worth $5 (or probably a little more after taxes) to a lot of customers (this brings up the question, which market is their main target: the geeky folk who want a device they can upgrade when they want to, or the folks who don't want to be bothered with "complicated" updating-procedures).
Also now that the information is out, that there are flashable treos available maybe Handspring better rethink their sales-strategy. If they now start producing treos without Flash-ROM a lot of folks will still try to get the flashable versions and pester salespeople about version numbers etc. and in general be dissatisfied with a treo that has this feature removed (and to them it makes no difference if Handspring anounced it as a feature or someone else).
No, there's a third way, and that's the way Theo proposes: make sshd's privsep work with your system (maybe it already works), then the bug is still there but harmless (since it is in the part of code that doesn't have root-privileges when running with privsep enabled), and will only get the attacker in a sandbox with no privileges. After doing that, everyone (including the Debian folks) has all the time in the world to apply the patch.
Note that privsep is simply a mechanism to reduce the parts of code that run under root-privileges to about 10% of the total lines sshd(8) consists of. That means, any attack which affects the other 90% will not give the attacker root access on a machine running sshd with privsep. This is a great mechanism to reduce the risk of being exploited. So this means, that the "critical" part of code (where a bug might give root access) is greatly reduced, which also makes it easier for developpers, since they can give the critical part more attention, it's obviously easier to keep 2,500 lines of code (mostly) bugfree, than 27,000, and it makes sense to review those 2,500 lines with greater scrunity.
The problem with enabling privsep for sshd(8) is, that this only works if some devices/executables/directories have the correct permissions set (my assumption), so it depends on the configuration of other parts of the system that isn't provided/controled by the OpenSSH developpers. This is clearly a packaging issue, and lies in the responsibility of the vendors/distributors.
So the OpenSSH developpers need the cooperation of the vendors to pull the teeth of at least one known bug (and maybe some yet unknowns) before the patch (and thus the specifics of the security-hole) is released, to ensure a safe period between the release of the patch and its propagation to servers administrated by concerned sysadmins. Also it is generally a good idea to run only that parts of code under root privileges, that is absolutely necessary, so making sshd(8) work with privsep shouldn't have the lowest priority with vendors anyway.
I don't believe that MS does so much testing for their patches. I heared enough about MS patches not fixing the bug/hole it's supposed to, causing new problems, or not play well with some applications (i.e. causing them to crash). How can that happen if MS did all that testing you describe? Also i really wonder why it should take two weeks to put a patch on a webserver and write a brief documentation about it, especially since they've enough time to put together documentation while doing internal testing (they need that anyway for customer testing).
And while some (unsure about the percentage) mozilla fixes cause regression, they often hit the nail on the head with the first patch. In that ideal case the bug is squished within 3 days. Even if your "schedule" for mozilla fixes were correct, the mozilla developpers can do four iterations of that in the six weeks time it takes MS to issue their first patch. Then you assume that usually MS get's the fix right the first time, but if they don't and find regression after one week of internal testing they have to iterate too until they get it right and it'd be about as fast as an iteration in the mozilla case. If they catch it in the first week of "customer testing" they need 3.5 weeks for a cycle.
The advantage of the mozilla strategy is, that as soon as the patch is ready, anyone can test it (and at least the big linux distributions probably do so), and if there is a problem with a patch, information gets back to the developpers much earlier.
They wouldn't have a stranglehold on it, but they would certainly have a market.
But that's just the point: MS not being able to establish a stranglehold on that market, at least not to the extent they have now with Windows.
I don't mind if MS churns out another Linux-Distro, and if it's good enough, why shouldn't it grab a significant share of the market? But they'd have to play by a different ruleset there which would ensure a much more level playing field than there's now with Windows.
The Problem with that is, that people would note that even MS got on the Linux-train. Once they do this they'd have a hard time to explain why the GPL is "unamerican", only not when used by Microsoft.
Also anyone looking into buying MSLinux is even more likely to consider buying Redhat/debian/etc., so that move could boost Linux in general and hurt Windows even more.
Finally Microsoft would have to play on a more level playing field, and what's even more important: until now they didn't figure out how to skew the "GPLd Software" playing field to their advantage. Locking customers in with proprietary file formats won't work here, it's harder to aim the FUD-cannon when they're playing in the same arena, and it's really hard to enforce licence restrictions on the users of GPLd Software.
Slashdot Mirror
German censorship has mostly to do with nazis. Now if you are a nazi, that censoring will hit you pretty hard, admittedly, please note, that germany (population and even more so the government) is very sensible when it comes to the subject of nazis. That's because of our (yes i am german) history. There are still nazis in germany, but i think, many other countries have a worse problem with that. Anyway that's not the point. The point is, that a lot of german censoring (probably all) that hit the "slashdot news" probably has to do with nazi propaganda.
That is not to say, that this is a domestic problem and noone else should have a say in this, but please discriminate what is censored, and take the german history into consideration. I don't know if we're better off with respect to free speech than the USA, but i notice that there's a worldwide trend of limiting free speech rights.
As an aside i'd like to thank the allies (among them the US of A) that i don't have to live in a "national socialism" today, i consider some well defined limits to free speech rights (e.g. prohibiting to deny the holocaust and to glorify the nazis) a fair price if it prevents those assholes from spreading their lies again. I'm really happy that thousand years went over so fast i didn't have to live in them.
Yeah, mod me offtopic, it is, and i'm drunk.
I don't know about the US, but in most european countries bikes are banned from sideways (unless you push them or it's obviously a toy for childs less than 5yr.). The reasoning makes sense: Anyone riding a vehicle should do so on the roads while anyone on the sidewalk mustn't endager anyone else on said sidewalk (which basically means you should choose a mode of transportation that lets you come to a halt within 3ft and doesn't endanger anyone seriously if you don't (not considering freak accidents)). I wouldn't like to walk on a sidewalk with those segways whizzing past me, would you?
It is important to consider when they had to decide which codebase to choose. Over a year ago means mozilla version less than .9.8, and while that version was already usable it was very obvious that it still needed a lot of work. I don't know the state KHTML was in at that time, but its main advantage is the smaller codebase. It's a very sound decision to keep the project overseeable and manageable. Had they used the mozilla-code they'd had to invest much more into the development, they might still depend on (parts of) the mozilla development, and it'd probably have taken much longer. The benefits of using the mozilla-codebase don't outweigh these costs considering that all apple wanted was a standalone-browser.
Over all the ruckus about HTML vs. mozilla aparently nobody noticed that Apple based their browser on an open source project and decided against doing it closed-source on their own. I think that's great news.
Sure it's a good thing for a company to make money. But if they do that by taking something away from me (e.g. free software) so they can sell it to me I don't have to agree that this is best for all concerned, do i?
It's really sickening how people get screwed over by big corporations and then even cheer them on because "it's their godgiven right to make money any way they can". No it isn't they have to play by some rules too, at least if their customers come to their senses and don't buy their products if they are screwed over by their business practices.
The important part is telling the people how and by who they're screwed, and that they can do something about it. The equation 'making money = good for business' has two sides, if people react appropriately to bad business practice and boycot then it becomes 'bad business practice = bad for business'.
You don't have to use the put-options, you simply trade them, but you could as well buy the stock after the price dropped and then use the put-options to resell it again at a higher price.
It's not like that at all, that's why they're called options. Nobody would be so silly and pay for the kind of papers you describe. Only the guy who sells the options has got the other end of the stick, meaning he has to pay for the difference if anyone makes use of their put options.
There's also BUY-options (or something like that) letting you buy stock at a fixed price sometime in the future. So if you know there's an important event in the near future that will have a huge impact on the stock price of a company (one way or the other) you can even buy PUT and BUY options, make lots of cash on one of them and throw away the other.
Maybe after some lengthy lawyering you could get rid of some of the shadier points in the EULA (but it'd probably be easier to attack them directly and not confuse the case with M$'s breach of contract). Anyway, you'd spend more on lawyers than you could ever hope to get out of this, and you couldn't ever wriggle out of basic copyright, since that's covered even without any EULA.
This example illustrates a more general problem:
Lately we see more and more license changes for existing software, BitKeeper and various Microsoft products are only the most notable cases. License changes accompany updates and patches, or it's just a document on some website that changes.
Most Software isn't ever a `finished' product, it's subject to changes called `new version', `upgrade' or `patch'. Often the customers depend on having the latest version of a software, be it for security reasons, compatibility issues, or just part of a leasing contract for the software. The software makers use these changes in the software to change the license terms in the software. In the BitKeeper example, someone using BitKeeper in a large project probably depends on it, or it would at least cause a lot of additional work and delay the project to switch from BK to something else.
This means, that even subtle license changes may have a huge effect on anyone depending on that software, done right such a license change might even ruin someones business (imagine someone using free BK on some project competing with BK, and imagine BK had gone one step further and made their "no competition" clause mandatory on all new licenses. Done just a few months before some critical timeline this might have killed the whole project. Even so any project using BK for a competing open-source product would probably have a hard time or even falter).
To protect businesses from being at the whim of software-makers there should be some regulations in place, that only allow license changes within reasonable limits, and demand that such changes are announced some time beforehand, so the customers have time to react. Most companies protect their business by making sure that they can't be cut of from any resource they depend on, they should realize that software is just such a resource and enforce license terms that don't allow for ugly surprises due to one-sided changes. But since few companies have the leverage to change Microsofts license terms i think there's a need for legislation considering software license changes.
I mean, could it get any better than one group wanting to screw fair use rights going after another?
My analogy stands ...
Yeah, equating some burglar breaking into a house to someone redirecting mail through a mailserver is probably a good analogy. Also, at least the second time around the guy specifically asked them to recheck his server.
Let me first state, that it's obvious that blacklists can be abused. Only until now they're the only means to get a grip on the spam problem, and that is, what gives them so much power. If there were other ways to fight spam, noone would need to rely on these blacklists. Also they apparently do more good than bad, or they wouldn't be in wide use. In the end the operators of the mailservers decide if they rely on those lists or not. Also this system can't work if there's a large overhead and every action has to be considered for two weeks before anything is done, so a flexible organisation that isn't hindered by procedural overhead is necessary or it won't work at all.
So while your statement is true that the blacklist operators wield much (maybe too much) power, they have that power because their system at least works. And one reason why there's no better way to deal with spammers is that there's no legislation in place so one could sue spammers and ruin their business.
Once you figured out the correct angles you can make glasses such that it is unnecessary to tilt the head. Also you don't need to tilt the head in an exact angle, probably anything within 15-20 degree of the correct angle will do well enough. And there's already sunglasses out there with polarisation filters.
If the person gets a cup of coffe it pretty damn better lock the screen. It's really sad to hear, that banking business not yet discovered the use of a screensaver/screenlock and sees a need to "close all applications" for a cigarette break.
Also often the "average customer" might have a legitimate interest in the data that's displayed (maybe because it's his own data about what he's discussing with a bank employee) and he will feel a bit silly if he has to put on those funny looking glasses first. Let alone walking into a bank where half the employees (all that are working with computers) wear the same kind of geeky looking glasses.
So let's conclude: This technology isn't secure against anyone who really wants the data from that screens, it only creates a false sense of security. At the same time it makes everyone in the bank (including the customers) look silly. Also there are already better ways to protect that information (screensavers, arranging displays such that customers normally can't see it, displays with a narrow viewing angle).
Maybe privacy is big in banking, but i think it's more important to avoid looking silly.
I use a blank screen for my screensaver anyway. I don't see any sense in a screensaver that wastes cycles on something that nobody will watch for more than a few seconds. But then i worked in an university lab where old MIPS-workstations were used to run jobs 24/7. Also i find screensavers to be distracting.
... or at least some reasons, why it would make sense to time the relese of information in such a way. Also that person(s) might hide their information for all the wrong reasons, maybe a crisis he predicts could be averted, given enough time, maybe the upheaval will be even greater in X years time, maybe someone else already discovered what he found and puts it to the wrong purpose ... so i think someone who considers to go to great length to delay informing the world about the facts he learned should also consider if holding back that information is really the right thing, and if the mechanisms he chooses to release the information are appropriate.
I'm sory, but i fail to see a case where it would make sense to go to great lengths to keep information hidden until a specific date:
My main point is, that it's hard to announce (and why delay the revelation unless you inform at least someone who can do something in the meantime?) a discovery without revealing the identity of the person (or even worse: group) that discovered it. If he/they visibily go through a lot of trouble to hide the information, then someone will consider the information worthy enough to reproduce it. He has many options:
- ask/bribe/torture the person who discovered (whatever) to reproduce the information, or give out enough details that someone else can reproduce it.
- find out what the line of work of that person was and invest heavily in that direction (virtually noone can make an important discovery today without at least working with someone or refer to other's works (oops all that queries in a scientific database may reveal a pattern))
- find a way to get at the information anyway (maybe it resided on some harddisk that wasn't overwritten 10 times, maybe the method of keeping it secret is flawed)
Also, does it make sense to reveal that information at a fixed date in the future (e.g. bouncing it of a celestial body)? How can you know now what revealing the information might do at that date, and why do you think mankind will then be "ready" for it? revealing information at a fixed date in the future makes only sense for astronomical events (an asteroid will hit earth at it's next pass near the sun (maybe 80 years from now) and you think it's better to spare mankind the upheaval for the next 70 years (but how can you know, maybe we could do something about the asteroid in 40 years from now if only we knew, maybe shooting at it with a strong laser, so gas emissions will alter the course ever so slightly).
For other discoveries it makes even less sense to hide them for a fixed time, since it's impossible to guess, how fast (and whereto) society will evolve, when scientific discoveries will provide us with a good replacement for some technology or other, and, generally speaking, when the time is 'just right'. In that case it'd probably be better to involve some kind of human intervention/judgement to determine when to reveal the discovery.
One way to do that would be to build a (not necessarily secret, depends on the discovery) "society" to guard the information. maybe politicians from different countries, people from international organisations or even corporations. Technically you could give each member (or different groups of members) part of the information which makes only sense when it's all (or a significant number of information pieces) are put together (there are codes that do that for you: e.g. give one part a oneway pad, the other the encrypted information). But that still leaves the problem, that the information might be discovered independantly, somehow cajoled out of the original discoverers, or just 'rediscovered' (it's easier to get funding for a project if you know you will discover something).
1) If you apply an e-mail to an officially sanctioned opt-out list, it is illegal and subject to fines to e-mail an unsolicited e-mail to that address.
No way will i help the spammers by providing them with a neat list of my email-addresses. Opt-out is the wrong way anyway. If someone wants to send me spam he should have to search my digitally signed entry out of an Opt-in list.
The RIAAs and MPAAs plans were to use DOS-attacks on the sites/networks which (they claim to) distribute their copyrighted content. Flooding the networks with faked mp3 or bringing servers down to their knees with faked download requests isn't breaking into systems. Not that i would consider waging DOS-wars over the internet a good thing, and yeah, i'd love to see some music exec locked away in a stinky jail (although that will never happen).
But wouldn't the proposed US-law only allow the copyright-holders to use DOS-attacks, and aren't DOS-attacks considered a lesser offense in most countries (especially if you don't break into thousends of foreign systems to misuse them but buy the necessary bandwith)?
Also who would sue those execs and set the lawyers and the police into motion to catch that evil hacking RIAA-exec? The owner of that site who probably did infringe on copyrights? The provider who only thinks about business and anyway doesn't like customers which use more bandwith than others who pay the same?
It'd be better to use political leverage: since every action has to be allowed by US-officials those officials (and thereby the USA government) can't free themselves from the responsibility for such attacks. Thus other countries can respond politically. That would be more of a threat, if those countries took it upon them to make the internet a place that can work without the US-backbones.
Aparently big corporations don't want flaws in their products exposed and prefer to use lawyers to "secure" their OS. So it's back to the days when exploits floated around in usenet-news (from untracable sources) and a worm/virus had to bring down millions of systems before the softwarecompanies admit there is a security hole?
And there i thought that those companies learned to value security over marketing issues. But obviously thinking farther into the future than 3 months is uncalled for these days. Business sense is dictated by the shareholders now, and the results are shortterm tactics without overseeing the big picture (in this case that fixing security holes is more important in the long run, than sweeping them under the carpet).
Your "example" of "driving 90 in a 55" was uncalled for, noone was driving 90, so please avoid silly "examples" that serve no other purpose than confusing the subjects.
It's nice to know who to turn to, if we want to know when to use which tools, and when civil disobedience is appropriate. Only i think that everyone should decide for himself when that point is reached, and what he thinks is appropriate to raise public awarenes for his ideas. Also it can be argued, that after the DMCA was bought by big business, and even worse legislation is in the works (CBDTPA) without any sign of a major outcry, civil disobedience is highly called for to stop things from going even farther downhill.
This is just another instance, where politicians are outselling public interests for corporate interests, it's not a separate event, and it's high time someone raises awereness of that.
You make up your statistics, so why not avoid it at all (it serves no purpose) and just say what you want to say: "Software projects consist of a huge chunk of work that is neither creative nor cool. Someone who is payed for his work (opposed to someone who does it as a hobby) is much more likeley to do the uncool parts as well as the cool ones."
...). I think it's more liekley that all that cool code is used in later projects for open source projects for obvious reasons (anyone who wants can use it), so even that "stagnating projects" are still good for something.
...
...) because of these benefits, and they see to it, that the boring parts get done too. The question isn't just if some programmers hobby can result in a better product than a project some corporation invested millions of dollars in (even that is possible, many of the OS-projects that are now backed by the big industry already got a far way on their own), but also if (and for which projects) someone/a corporation considers open source development superior to closed source development.
The rest of your argumentation leaves some gaps:
- you leap to the conclusion that open source software is only done as an unpaid hobby. That is untrue. If someone (AOL) has enough interest in an open source project (mozilla) there will be paid jobs for open source development. Only you also get to benefit from free contributors (who do this as a hobby) and from the work of partners who are interested in the same project (while in closed source work there's so much overhead in drawing up the contracts that it's often not feasible to do joint work between corporations at a project).
- you cite "hundreds" (i assume you made up the order of magnitude) of unsuccessful open-source projects for every successful (what do you consider a success for an OS-project?) one. Well compare that to all the closed-source projects noone ever heared about and which died a silent death for whatever reason (budget ran out, management changed their mind, marketing didn't see a market, key developers changed workplace, nobody wanted to do the uncool parts (hey that can happen in closed-source development too)
- A big percentage of "uncool" code is just reinventing the wheel, doing something that already has been done. But code reusability is much higher for open source projects, since you can reuse code from a huge base of open source code without legal hassles, while all that nice GPLd (or similarly licensed) code is off limits for reuse in proprietary projects. Thus the percentage of "uncool" work is even higher in closed-source projects.
The argument that "uncool work" is more of a problem for open source projects than for closed source ones is neither new, nor is it completely unfounded. But the picture you draw up (all open source is hobbyprogramming, noone does the uncool parts and that is the reason so many projects stagnate) is just too onesided. It also completely neglects the benefits of open source development: code reusability, the possibility of working together at one project without occupying a horde of lawyers and swear every programmer to absolute secrecy, contributions from individuals as well as corporations all over the world who are interested in the project,
Large corporations invest heavily in open source projects (kernel, mozilla,
TreoCentral also offers this explanation and it explains why Handspring doesn't announce this feature. But TreoCentral also mentions, that it might cost about $5 per device to include the Flash-Rom. But Flash-Rom, and the ability to upgrade your OS is a great sales argument, so i wonder if the value-add isn't worth $5 (or probably a little more after taxes) to a lot of customers (this brings up the question, which market is their main target: the geeky folk who want a device they can upgrade when they want to, or the folks who don't want to be bothered with "complicated" updating-procedures).
Also now that the information is out, that there are flashable treos available maybe Handspring better rethink their sales-strategy. If they now start producing treos without Flash-ROM a lot of folks will still try to get the flashable versions and pester salespeople about version numbers etc. and in general be dissatisfied with a treo that has this feature removed (and to them it makes no difference if Handspring anounced it as a feature or someone else).
No, there's a third way, and that's the way Theo proposes: make sshd's privsep work with your system (maybe it already works), then the bug is still there but harmless (since it is in the part of code that doesn't have root-privileges when running with privsep enabled), and will only get the attacker in a sandbox with no privileges. After doing that, everyone (including the Debian folks) has all the time in the world to apply the patch.
Note that privsep is simply a mechanism to reduce the parts of code that run under root-privileges to about 10% of the total lines sshd(8) consists of. That means, any attack which affects the other 90% will not give the attacker root access on a machine running sshd with privsep. This is a great mechanism to reduce the risk of being exploited. So this means, that the "critical" part of code (where a bug might give root access) is greatly reduced, which also makes it easier for developpers, since they can give the critical part more attention, it's obviously easier to keep 2,500 lines of code (mostly) bugfree, than 27,000, and it makes sense to review those 2,500 lines with greater scrunity.
The problem with enabling privsep for sshd(8) is, that this only works if some devices/executables/directories have the correct permissions set (my assumption), so it depends on the configuration of other parts of the system that isn't provided/controled by the OpenSSH developpers. This is clearly a packaging issue, and lies in the responsibility of the vendors/distributors.
So the OpenSSH developpers need the cooperation of the vendors to pull the teeth of at least one known bug (and maybe some yet unknowns) before the patch (and thus the specifics of the security-hole) is released, to ensure a safe period between the release of the patch and its propagation to servers administrated by concerned sysadmins. Also it is generally a good idea to run only that parts of code under root privileges, that is absolutely necessary, so making sshd(8) work with privsep shouldn't have the lowest priority with vendors anyway.
I don't believe that MS does so much testing for their patches. I heared enough about MS patches not fixing the bug/hole it's supposed to, causing new problems, or not play well with some applications (i.e. causing them to crash). How can that happen if MS did all that testing you describe? Also i really wonder why it should take two weeks to put a patch on a webserver and write a brief documentation about it, especially since they've enough time to put together documentation while doing internal testing (they need that anyway for customer testing).
And while some (unsure about the percentage) mozilla fixes cause regression, they often hit the nail on the head with the first patch. In that ideal case the bug is squished within 3 days. Even if your "schedule" for mozilla fixes were correct, the mozilla developpers can do four iterations of that in the six weeks time it takes MS to issue their first patch. Then you assume that usually MS get's the fix right the first time, but if they don't and find regression after one week of internal testing they have to iterate too until they get it right and it'd be about as fast as an iteration in the mozilla case. If they catch it in the first week of "customer testing" they need 3.5 weeks for a cycle.
The advantage of the mozilla strategy is, that as soon as the patch is ready, anyone can test it (and at least the big linux distributions probably do so), and if there is a problem with a patch, information gets back to the developpers much earlier.
They wouldn't have a stranglehold on it, but they would certainly have a market.
But that's just the point: MS not being able to establish a stranglehold on that market, at least not to the extent they have now with Windows.
I don't mind if MS churns out another Linux-Distro, and if it's good enough, why shouldn't it grab a significant share of the market? But they'd have to play by a different ruleset there which would ensure a much more level playing field than there's now with Windows.
The Problem with that is, that people would note that even MS got on the Linux-train. Once they do this they'd have a hard time to explain why the GPL is "unamerican", only not when used by Microsoft.
Also anyone looking into buying MSLinux is even more likely to consider buying Redhat/debian/etc., so that move could boost Linux in general and hurt Windows even more.
Finally Microsoft would have to play on a more level playing field, and what's even more important: until now they didn't figure out how to skew the "GPLd Software" playing field to their advantage. Locking customers in with proprietary file formats won't work here, it's harder to aim the FUD-cannon when they're playing in the same arena, and it's really hard to enforce licence restrictions on the users of GPLd Software.