A unified open free OS is only easy to develop for if nobody uses the rights that they prize. If people start modifying the OS the way they claim to want, instead of a small number of, say, mediocre and predictably broken OSes, you end up with a large number of unpredictably broken OSes, simply by virtue of the fact that, while visible and reproducible, changes do not instantly apply everywhere, and by the principles of F/OSS software, indeed they should not.
Does anybody remember UNIX? UNIXes embodies far more fully the principles of Open Source in that they spread, forked, and changed by whim far more freely than, say, Linux has done. Many UNIXes were flat-out incompatible, even with source, with other flavours of UNIX. It is for this sort of incompatibility (among other issues) that many people looked to Open Source software for a remedy, not realizing that it is simply a codification of the same principles that produced the problem.
The ability to fork (essentially, the only difference between F/OSS and proprietary software) can only exist in a vibrant community when it is used exceedingly sparingly. This is why Linux (the kernel) has such popularity, while so many distributions essentially repackage the same software, creating more confusion than value. It is precisely by failing to embrace the principles of F/OSS software that Linux, Apache, and other enduring open source projects have attained the popularity, ubiquity, and even quality that they have.
Imagine if everyone who wanted a bug fixed in Apache had simply patched their own version, and distributed the patch themselves. Imagine the confusion of patching, having to know whose versions of what patches were previously applied, because there are dozens of versions of each bug's patch, and some (many) of them change internal values or structure in incompatible ways. It is precisely because Apache has been centrally maintained that it is so simple and easy to say "I'll just use Apache."
But, you say, surely the ability to see the code is the key? Apple and Microsoft both have ways of allowing people to see certain parts of their useful codebases, under licenses that claim any changes (Apple) and/or forbid further use (Microsoft). These are typically criticised as being "not open". What, then, is left? The key difference, then, is simply the ability to re-use - i.e. fork and own. From a practical standpoint, therefore, access to the source without the ability to directly make changes and use/distribute the modified versions is not sufficient to satisfy the demands for F/OSS software.
The one line that differentiates F/OSS software from proprietary software is the ability to fork without permission or recourse, and it is that ability that prevents an open free PC with a unified open free OS from ever existing.
The ability to modify the Javascript neither grants the ability to read statements from a server that no longer supplies them (by far the most common cause in such a scenario) nor does the lack of such ability prevent a trivial, yet far, far more effective counter to such changes - downloading or making PDF versions of the statements. Further, allowing such modifications could be construed to relieve the bank of the burden of providing a working web interface, as the blame could be put squarely on the open-source community, and any problems attributed to the use of the wrong version of the Javascript display code.
Google Documents stores documents on Google's servers. Having a modified version of the Javascript used will not grant access to server-side resources from an even moderately competently designed web service.
Business web apps tend to be either in-house apps or likewise tied to external servers. Having access to the front end does not in any way mitigate the problem of losing the back end server and database. If you want an entire F/OSS system (front and back end) those are already available and clearly marked as such. The F/OSS status of the Javascript really only matters when it is part of such a system.
Most sites either provide their account terms online in text (rather than Javascript) form, and the license status of the Javascript itself is completely irrelevant to the terms for the service itself.
If you want to study encryption, download the Firefox code and see how it implements SSL. Real applications typically use SSL for encryption rather than relying on tricky Javascript encryption that just adds complexity without benefit. Anyone who does use such encryption or other security features in Javascript already exposes the code to public scrutiny by virtue of View Source. Allowing others to re-use that bad decision just results in worse web apps and bad attempts at "encryption" under the assumption that somebody would notice if it was a problem.
If you only use your web "browser" to ensure that you meet the most stringent standards of pointless ideological purity, then you might want only F/OSS Javascript running in it, but your application scenarios have shown that not only does GPL'ed Javascript provide no practical benefit, it has serious drawbacks both from the perspectives of consumers and businesses.
I want the option to "(x) Warn before running dodgy F/OSS Javascript"
Verizon has their InPulse prepaid line, and hosts Amp'd Mobile, which also sells prepaid phones Sprint hosts Virgin Mobile prepaid on CDMA and Boost Mobile prepaid on iDen Cingular has their own prepaid service
There are others, but I can't think of them off the top of my head.
Actually, Windows Server 2k3 is fine for longer than that. I've seen it run for upwards of three months at a time before being rebooted, not for performance issues, but as part of a patch. Now, if you're running Windows Media Player and Kazaa on you server...
And how do you propose to make this certification relevent? If, say, only 50% of the people you want to receive emails from have got certified by their ISP, then dropping spam based on that method, even with massive (50% of relevent end users) deployment, dropping emails based on this would give a 50% false-positive rate. Given that false positives are much more costly than false negatives, and that most companies need to receive emails from a relatively wide segment of the population, this seems that it would be harmful for most corporate users.
In addition, it would seem to lock out users who have to spoof their from field when sending from a corporate account through their residential ISP.
Additionally, many users would find the burden of obtaining personal certification and configuring signing in their mailclient to be beyond them, while many others would simply find that their mail client does not support the protocol. Remember, a lot of people still use hotmail, so you can't just pull the plug on a large service at will.
Then there are organizations that also offer webmail access - they would have to store both public and private keys on their server, which is just a plain silly thing to do with an asymmetric encryption system.
Also, you've got the minor issue of all of those certified senders that just don't know that they're sending out massive amounts of certified spam because they're running a bot that uses their own mail settings.
Oh, and of course there is the minor problem of just who would issue the certifications. Passing the buck on to the ISP is convenient, until you realize two things: first, that the ISP already has the ability to TOS spammers, and second, that if an ISP won't do this, they're not likely to bother pulling the user's certification. This, of course, only leads up to the other question of whether you intend that every mailserver be its own signing authority, in which case the whole system is just a broken designated-sender system, or if you intend, as it appears, a system of delegated certification, in which there must logically be one or more authoritative root signing authorities. In the latter case, you'd have to justify the cost of running the signing authorities, and the cost of this certification that would gain next to nothing, and find a way that, should spammers actually be inconvenienced by this, they wouldn't just set up a fake entity, buy a certificate from Thawte, Verisign, etc. or their equivalent, and sign for a whole slew of their friends?
Plus, of course, there's the fact that you would need to avoid action on false reporting, or someone might just complain about your own doman. Gee, nec.com is suddenly no longer certified?
approach to fighting spam. Your idea will not work. Here is why it won't work. (One or more of the following may apply to your particular idea, and it may have other flaws which used to vary from state to state before a bad federal law was passed.)
( ) Spammers can easily use it to harvest email addresses (*) Mailing lists and other legitimate email uses would be affected ( ) No one will be able to find the guy or collect the money ( ) It is defenseless against brute force attacks (*) It will stop spam for two weeks and then we'll be stuck with it (*) Users of email will not put up with it ( ) Microsoft will not put up with it ( ) The police will not put up with it (*) Requires too much cooperation from spammers (*) Requires immediate total cooperation from everybody at once (*) Many email users cannot afford to lose business or alienate potential employers ( ) Spammers don't care about invalid addresses in their lists ( ) Anyone could anonymously destroy anyone else's career or business
Specifically, your plan fails to account for
( ) Laws expressly prohibiting it (*) Lack of centrally controlling authority for email
The race and sex information is not used for the hiring process - it is used for statistical analysis later on (e.g. monitoring compliance with diversity requirements) and for reporting to the Department of Labor. HR and hiring managers don't even see it.
Re:The problem of nerve impulse conduction
on
An Alternate Human
·
· Score: 1
Blackberry isn't just email - it's a sturdy device (quality handset design), running a solid operating system, with a good interface that lets you do a lot of simple tasks one-handed, along with synchronised email, calendar, notes, task list, the ability to dial from contacts you establish on your desktop - and then there are the third-party apps like Berry411 and Google local for Blackberry, general web browsing, the ability to use some models for tethered data service - and that's just on the user side of things.
For the IT department, it gives you the ability to enforce policy on the pda, integration with a Microsoft or Lotus mail systems, easy deployment of new units, a secure connection, and, most valuable of all, almost no hassle.
Contrast that with the fact that the RedBerry looks to be a Windows-based system. Now, I'm not saying that this is inherently a minus, but just about every Windows phone I've worked with has... well... sucked. And I work at a cellular phone company, so I've seen a few.
Now, if you're a home user, maybe email is all you need - but when you start doing everything that a Blackberry does, you start to realize that it's a lot more than just slapping smtp/pop/imap into a phone. Still, I think that the RedBerry could be quite useful for those home users who really don't need much more than that smtp/pop/imap and the mobile equivalent of pine.
Much what I was thinking, seeing the references to specifically GSM phones. I suppose it wouldn't be practical to say (in the U.S.) "Please turn off all cell phones, unless they are CDMA phones, which means you Verizon Wireless and Sprint customers may commence mockery of Cingular and T-Mobile customers."
(OTOH, I work for an MVNO using a CDMA network, and it would be cool to be able to add "legal to use on airplanes" to our marketing.)
How about functioning as a tetherable EVDO modem? My 7250 does that.
The fact is, a Blackberry is a one-handed device, and the MS attempt is a two-handed device that is noticeably clumsier.
I guess you haven't tried to upgrade FF to a recent release and found that - whoopsie! - half your extensions hadn't been updated to the new version, and weren't working. That's what keeps FF users on old versions.
I suppose the obvious answer would be "What is the lowest level that you could reasonably expect from your userbase". For a site touting the latest and greatest in web technology, you might be a bit heavier in your requirements than for, say, a site on nutrition.
For regular applications, you might ask yourself what the lowest level is that can reasonably be expected to do what's required. i.e. if you need a gig and a half of RAM for most operations, you might not support Win95 simply because it can't support you RAM-wise.
Then, even if you could do it in '95, would your userbase still be in '95? Really, it just boils down to "what's on the machines of the people you want to serve?"
Slashdot Mirror
Oh, come on, it's much more complex than that. It's more like an hour.
A unified open free OS is only easy to develop for if nobody uses the rights that they prize. If people start modifying the OS the way they claim to want, instead of a small number of, say, mediocre and predictably broken OSes, you end up with a large number of unpredictably broken OSes, simply by virtue of the fact that, while visible and reproducible, changes do not instantly apply everywhere, and by the principles of F/OSS software, indeed they should not.
Does anybody remember UNIX? UNIXes embodies far more fully the principles of Open Source in that they spread, forked, and changed by whim far more freely than, say, Linux has done. Many UNIXes were flat-out incompatible, even with source, with other flavours of UNIX. It is for this sort of incompatibility (among other issues) that many people looked to Open Source software for a remedy, not realizing that it is simply a codification of the same principles that produced the problem.
The ability to fork (essentially, the only difference between F/OSS and proprietary software) can only exist in a vibrant community when it is used exceedingly sparingly. This is why Linux (the kernel) has such popularity, while so many distributions essentially repackage the same software, creating more confusion than value. It is precisely by failing to embrace the principles of F/OSS software that Linux, Apache, and other enduring open source projects have attained the popularity, ubiquity, and even quality that they have.
Imagine if everyone who wanted a bug fixed in Apache had simply patched their own version, and distributed the patch themselves. Imagine the confusion of patching, having to know whose versions of what patches were previously applied, because there are dozens of versions of each bug's patch, and some (many) of them change internal values or structure in incompatible ways. It is precisely because Apache has been centrally maintained that it is so simple and easy to say "I'll just use Apache."
But, you say, surely the ability to see the code is the key? Apple and Microsoft both have ways of allowing people to see certain parts of their useful codebases, under licenses that claim any changes (Apple) and/or forbid further use (Microsoft). These are typically criticised as being "not open". What, then, is left? The key difference, then, is simply the ability to re-use - i.e. fork and own. From a practical standpoint, therefore, access to the source without the ability to directly make changes and use/distribute the modified versions is not sufficient to satisfy the demands for F/OSS software.
The one line that differentiates F/OSS software from proprietary software is the ability to fork without permission or recourse, and it is that ability that prevents an open free PC with a unified open free OS from ever existing.
The ability to modify the Javascript neither grants the ability to read statements from a server that no longer supplies them (by far the most common cause in such a scenario) nor does the lack of such ability prevent a trivial, yet far, far more effective counter to such changes - downloading or making PDF versions of the statements. Further, allowing such modifications could be construed to relieve the bank of the burden of providing a working web interface, as the blame could be put squarely on the open-source community, and any problems attributed to the use of the wrong version of the Javascript display code.
Google Documents stores documents on Google's servers. Having a modified version of the Javascript used will not grant access to server-side resources from an even moderately competently designed web service.
Business web apps tend to be either in-house apps or likewise tied to external servers. Having access to the front end does not in any way mitigate the problem of losing the back end server and database. If you want an entire F/OSS system (front and back end) those are already available and clearly marked as such. The F/OSS status of the Javascript really only matters when it is part of such a system.
Most sites either provide their account terms online in text (rather than Javascript) form, and the license status of the Javascript itself is completely irrelevant to the terms for the service itself.
If you want to study encryption, download the Firefox code and see how it implements SSL. Real applications typically use SSL for encryption rather than relying on tricky Javascript encryption that just adds complexity without benefit. Anyone who does use such encryption or other security features in Javascript already exposes the code to public scrutiny by virtue of View Source. Allowing others to re-use that bad decision just results in worse web apps and bad attempts at "encryption" under the assumption that somebody would notice if it was a problem.
If you only use your web "browser" to ensure that you meet the most stringent standards of pointless ideological purity, then you might want only F/OSS Javascript running in it, but your application scenarios have shown that not only does GPL'ed Javascript provide no practical benefit, it has serious drawbacks both from the perspectives of consumers and businesses.
I want the option to "(x) Warn before running dodgy F/OSS Javascript"
Verizon has their InPulse prepaid line, and hosts Amp'd Mobile, which also sells prepaid phones
Sprint hosts Virgin Mobile prepaid on CDMA and Boost Mobile prepaid on iDen
Cingular has their own prepaid service
There are others, but I can't think of them off the top of my head.
Imagine a beowulf cluster of Natalie Portman's pants!
Actually, Windows Server 2k3 is fine for longer than that. I've seen it run for upwards of three months at a time before being rebooted, not for performance issues, but as part of a patch. Now, if you're running Windows Media Player and Kazaa on you server...
Actually, that study was faked.
a _wikipedia_nature_study/
http://www.theregister.co.uk/2006/03/23/britannic
Pliny the Elder reports of a race of men with no mouths, who subsist entirely by smelling flowers. Give me real food any day.
No, it's asynchronous. I use my leet skills against a soldier, and 60 years later he gets around to dying.
That's funny - what are you doing actually reading /.?
And how do you propose to make this certification relevent? If, say, only 50% of the people you want to receive emails from have got certified by their ISP, then dropping spam based on that method, even with massive (50% of relevent end users) deployment, dropping emails based on this would give a 50% false-positive rate. Given that false positives are much more costly than false negatives, and that most companies need to receive emails from a relatively wide segment of the population, this seems that it would be harmful for most corporate users.
In addition, it would seem to lock out users who have to spoof their from field when sending from a corporate account through their residential ISP.
Additionally, many users would find the burden of obtaining personal certification and configuring signing in their mailclient to be beyond them, while many others would simply find that their mail client does not support the protocol. Remember, a lot of people still use hotmail, so you can't just pull the plug on a large service at will.
Then there are organizations that also offer webmail access - they would have to store both public and private keys on their server, which is just a plain silly thing to do with an asymmetric encryption system.
Also, you've got the minor issue of all of those certified senders that just don't know that they're sending out massive amounts of certified spam because they're running a bot that uses their own mail settings.
Oh, and of course there is the minor problem of just who would issue the certifications. Passing the buck on to the ISP is convenient, until you realize two things: first, that the ISP already has the ability to TOS spammers, and second, that if an ISP won't do this, they're not likely to bother pulling the user's certification. This, of course, only leads up to the other question of whether you intend that every mailserver be its own signing authority, in which case the whole system is just a broken designated-sender system, or if you intend, as it appears, a system of delegated certification, in which there must logically be one or more authoritative root signing authorities. In the latter case, you'd have to justify the cost of running the signing authorities, and the cost of this certification that would gain next to nothing, and find a way that, should spammers actually be inconvenienced by this, they wouldn't just set up a fake entity, buy a certificate from Thawte, Verisign, etc. or their equivalent, and sign for a whole slew of their friends?
Plus, of course, there's the fact that you would need to avoid action on false reporting, or someone might just complain about your own doman. Gee, nec.com is suddenly no longer certified?
In conclusion:
Your post advocates a
(*) technical ( ) legislative ( ) market-based ( ) vigilante
approach to fighting spam. Your idea will not work. Here is why it won't work. (One or more of the following may apply to your particular idea, and it may have other flaws which used to vary from state to state before a bad federal law was passed.)
( ) Spammers can easily use it to harvest email addresses
(*) Mailing lists and other legitimate email uses would be affected
( ) No one will be able to find the guy or collect the money
( ) It is defenseless against brute force attacks
(*) It will stop spam for two weeks and then we'll be stuck with it
(*) Users of email will not put up with it
( ) Microsoft will not put up with it
( ) The police will not put up with it
(*) Requires too much cooperation from spammers
(*) Requires immediate total cooperation from everybody at once
(*) Many email users cannot afford to lose business or alienate potential employers
( ) Spammers don't care about invalid addresses in their lists
( ) Anyone could anonymously destroy anyone else's career or business
Specifically, your plan fails to account for
( ) Laws expressly prohibiting it
(*) Lack of centrally controlling authority for email
I take it you haven't met my neighbors.
"mild"? You misspelled "pleasant".
The race and sex information is not used for the hiring process - it is used for statistical analysis later on (e.g. monitoring compliance with diversity requirements) and for reporting to the Department of Labor. HR and hiring managers don't even see it.
AMD, I think. ;)
Blackberry isn't just email - it's a sturdy device (quality handset design), running a solid operating system, with a good interface that lets you do a lot of simple tasks one-handed, along with synchronised email, calendar, notes, task list, the ability to dial from contacts you establish on your desktop - and then there are the third-party apps like Berry411 and Google local for Blackberry, general web browsing, the ability to use some models for tethered data service - and that's just on the user side of things.
For the IT department, it gives you the ability to enforce policy on the pda, integration with a Microsoft or Lotus mail systems, easy deployment of new units, a secure connection, and, most valuable of all, almost no hassle.
Contrast that with the fact that the RedBerry looks to be a Windows-based system. Now, I'm not saying that this is inherently a minus, but just about every Windows phone I've worked with has... well... sucked. And I work at a cellular phone company, so I've seen a few.
Now, if you're a home user, maybe email is all you need - but when you start doing everything that a Blackberry does, you start to realize that it's a lot more than just slapping smtp/pop/imap into a phone. Still, I think that the RedBerry could be quite useful for those home users who really don't need much more than that smtp/pop/imap and the mobile equivalent of pine.
Simple - products that smell like curry right out of the box are less competitive.
(well, unless they're supposed to smell like curry.)
Try blocking 22 and 443 then ;)
Much what I was thinking, seeing the references to specifically GSM phones. I suppose it wouldn't be practical to say (in the U.S.) "Please turn off all cell phones, unless they are CDMA phones, which means you Verizon Wireless and Sprint customers may commence mockery of Cingular and T-Mobile customers."
(OTOH, I work for an MVNO using a CDMA network, and it would be cool to be able to add "legal to use on airplanes" to our marketing.)
How about functioning as a tetherable EVDO modem? My 7250 does that. The fact is, a Blackberry is a one-handed device, and the MS attempt is a two-handed device that is noticeably clumsier.
While that rate may have been accurate at one time, we have since far surpassed that number.
Well, no wonder the country is in its current state - Sim City 3000 is so much better!
>without even evidence of them suing the computer during office hours.
Wow. You know you live in a litigious society when people start suing computers.
I guess you haven't tried to upgrade FF to a recent release and found that - whoopsie! - half your extensions hadn't been updated to the new version, and weren't working. That's what keeps FF users on old versions.
I suppose the obvious answer would be "What is the lowest level that you could reasonably expect from your userbase". For a site touting the latest and greatest in web technology, you might be a bit heavier in your requirements than for, say, a site on nutrition.
For regular applications, you might ask yourself what the lowest level is that can reasonably be expected to do what's required. i.e. if you need a gig and a half of RAM for most operations, you might not support Win95 simply because it can't support you RAM-wise.
Then, even if you could do it in '95, would your userbase still be in '95? Really, it just boils down to "what's on the machines of the people you want to serve?"