In the software world, it appears that often only the commercial leader is really profitable. For all the also-rans, open sourcing is a good alternative for the creator of the software and benefits everybody (except the frontrunner).
Another, similar route to open source software is through research projects that, for one reason or another, aren't commercialized; the research code is released and often becomes an important open source/free software system.
We should be happy about that: much (if not most) open source and free software started out that way.
Because so much free software starts out as commercial or research projects that, I think it's important to think about how to encourage development and research organizations to build it in such a way that the transition to free software will be easy. That means that such organizations should find it easy to use existing free software libraries, build on open APIs with free implementations, and should not feel the need to rely on proprietary libraries (which would make freeing the software later much harder).
One thing that I think is very important is to use licenses like LGPL or BSD (as opposed to GPL or QPL) for important libraries. Research and development organizations will not use software if that means making a strong commitment early on to open sourcing their software later or face uncertain expenses later. Both GPL and QPL, unfortunately, impose such uncertainties and limit options. If there is no unencumbered free or open source software, they will pick the best and most affordable proprietary libraries to build on.
The LGPL and BSD licenses, on the other hand, allow development and research organizations to keep their options open for what to do with their code. When infrastructure libraries (standard libraries, networking, gui, etc.) are released under those licenses, research and development organizations can use them, and when they decide to release their software as "free software", it will be so much more useful to the free software community than if it had been based on proprietary libraries or APIs.
For similar considerations, I think it's also important to get as much free software infrastructure on Windows. If companies start programming to free software APIs on Windows (and they have to cover the Windows market), when they go open source, their software will be much more useful to the free software community. So, the more unencumbered networking, database, and GUI libraries we can get onto Windows, the better.
So, keep that in mind when thinking about policies and licenses. While the idea that all free software is created by altruistic volunteers is appealing (and a significant amount of free software is), the reality is that a lot of free software is created by companies and donated if the software turned out not to be a winner in the market or is otherwise not commercializable. Making the life of those companies easier and allowing them to develop code that interoperates well with other free software is a win for everybody.
Securing a system does not mean checking the bug lists and applying the appropriate patches, or by throwing in a buzz-word Firewall. Although that is an excellent start, You can see the big difference with NT and OpenBSD.
NT has a decent security model. But Microsoft's goals with NT is functionality, not security. So with file permission defaults such as Everyone: FULL CONTROL and Exchange KM Server Admin passwords being "Password", it's not hard to see that M$ wants Admins to have an easy job. Everything works, but it ain't secure. Although one can configure NT to be secure, it will take many hours of work and tests.
On the other side of the spectrum, consider OpenBSD. Paranoid? Obviously. Everything's off, users have no access to anything, users can't su unless they're allowed. Here, security is well taken care of, but the admin's big job here is opening up the system so users can get some functionality.
Then put Linux in the middle. A relatively secure OS, with (as most distros) almost all daemons running without even asking for them. Shut off sendmail, wu-ftpd, httpd, etc, and boom, magnitudes more security.
Then consider the admin who uses the root account straight through telnet. One co-worker I knew does this on a regular basis, then brags that he's never been cracked!!! Patching bugs is the easy part...
This is not a trivial question. Firstly, SETI@Home uses the Aricebo Radio Telescope. This is a very nice dish for radio astronomy, but useless for SETI work. It's far too small. The smallest useful dish or array will be the hectare array, being built by the SETI Institute. Aricebo will only be able to detect signals from nearby stars that are: (a) at LEAST as strong as our most powerful RADAR, (b) SUSATAINED for a substantial period of time, (c) containing information on a carrier wave, (d) orbiting a planet or star, with no compensation for motion
In short, leakage (the most likely sort of signal to be found) will be invisible, actual RADAR type devices will be screened out (too short a duration and no information content), and any civilisation advanced enough to WANT to locate other civilisations by sending deliberate signals are likely to be filtered, by being screened out as local interference through a lack of doplar shift.
Methinks that SETI@Home is ingenious, but is using the wrong telescope. And it'll be finished before the RIGHT telescope has been built & put on-line.
As for "Open Sourcing" SETI@Home, it was, to start off with. The original UNIX client was GPLed. Hardly anyone bothered to do anything with it, and so they closed the source & shoved it over to a commercial house. Don't blame them - look to yourself first.
Having said that, SETI@Home's attitude has been somewhat attrocious. They've been going on about security, when that was never the cause of them going non-Open Source. Progress was. And part of that is their fault. They refused to set up a CVS repository, did VERY slow (and low-quality) releases, and basically impeded themselves at every turn. They should have done a damn sight better than that. Yes, there were only a few people there, which is EXACTLY WHY they needed to use CVS, rather than relying on manually testing every e-mailed patch, and rolling a fresh tarball by hand every few weeks or months.
Honestly, if SETI@Home has shown anything, it's shown that we should be less worried about intelligence "out there" and rather more worried by the lack of it down here.
Why not ban unsolicited commercial direct marketing? What would happen?
Well, the US Post Office would get an exemption on the grounds that junk mail subsidises other mail (or at least it should; I'm not sure if it's really not the other way around).
For phone, fax, and email direct marketing, a new business would be created. Consumers would get paid to opt-in. You could fill out a marketing demographic survey, and then you would get a credit on your phone bill paid for by the direct marketers who called you.
With opt-in systems, consumers get paid for putting up with advertising. Those who don't want the advertising pay their own way. This is already happening with ISPs. This is also how TV works (you can get free TV with ads, or premium/rental services without).
But the author realizes that it is infeasible to enforce copyright through technological means. Any copy protection can be broken by someone sufficiently motivated to do so, and somewhere out there on the internet there is bound to be someone who is sufficiently motivated. All it takes is one person to break the protection scheme, and then the cat is out of the bag. Consequently, copyright enforcement turns to laws and the tools of law enforcement. That isn't necessarily a bad thing, but we have to ask ourselves, if a law is widely violated by a majority of the citizens, then is that law really an expression of the will of the people (the ultimate force from which the law's authority is derived)? And if not, then should we really be enforcing legal penalties on those who violate this law that does not derive from the will of the people?
O.K., so there's a little out-and-out fixing. However, reviews often skim over negative points. Again, there are two common justifications. The first reason -- and one that affects "community" publications, such as those in the Mac and Linux worlds -- is that readers really *want* to hear good things about their community, rather than serious evaluations. That's understandable, but not (IMHO) good: Saplings may need protection, but they also need a chance to grow into storm-weathered oaks.
Given that a benchmark as popular as this will tend to have vendors adding, uhh, "features" to make their webservers run faster for the benchmark, how did he manage to beat them anyway? Did he modify the TCP/IP stack? DoS the other servers during the test? Connect a compulsator to a large coil?
Standardize hardware so you can have a reference box the admins can work with and then duplicate the settings on the server for download.
We already have standards. You can get the latest version by typing "vi/usr/doc/HOWTO/Hardware-HOWTO". This isn't a joke, I'm dead serious. The linux standard is the kernel, so the sooner we convince manufacturers to provide modules for the KERNEL for their devices, the better we'll be. It could be worse.. they could be creating must-run-as-root daemons with closed-source APIs. I say we formalize an existing standard.. afterall, it's worked quite well so far.
We already have standards. You can get the latest version by typing "vi/usr/doc/HOWTO/Hardware-HOWTO". This isn't a joke, I'm dead serious. The linux standard is the kernel, so the sooner we convince manufacturers to provide modules for the KERNEL for their devices, the better we'll be. It could be worse.. they could be creating must-run-as-root daemons with closed-source APIs. I say we formalize an existing standard.. afterall, it's worked quite well so far.
You have to remember that encryption is a tool like any other, and its use or misuse is determined by personal ethics and law. In the same way that a gun advocate can advocate that every citizen should be able to bear arms while saying murder is bad, geeks have a seperation between "owning" and "using".
I doubt this would be possible unless the MP3 format were changed to allow for some kind of ad header to be applied to the front or back. If it's just some audio that they encode and stick on the back or front of the MP3, how are you going to know which frames contain the ad audio and which contain the audio you want to hear?
Same way we do it with TV. Advertisements have a distinct signature audio-wise - the volume usually is higher than the TV programming. Simply normalize the output, and chop the high point. But that may only be effective for, say, classical music - Fear Factory might not have the same approach. Now most music has a prelude, a quiet opener, or atleast a distinct silence. You can't put that ad in the middle of the song or people will scream murder. So it has to be at the beginning or the end.
There's also the encoding - they might mismatch the bitrates. They will almost definately use 1 encoder - and probably not the one the MP3 has. So you can just analyze the MP3 and determine when the encoder changes - non-trivial, but considering how much geeks detest forced-advertisement, I'm sure it's possible. It's a BIG itch to scratch.
Another method I can think of is to simply visit the advertiser's site. Most of them are MORE than happy to provide ALL of their releases. A few waveforms and an FFT calculation later, and all your mp3's have had that signature removed.
Given that the primary method of MP3 distribution is currently online, someone could simply md5 sum the "bad" mp3's, and blacklist them. The servers (or clients) could then automagically purge them from the network. THAT is a trivial programming exercise.
We already have standards. You can get the latest version by typing "vi/usr/doc/HOWTO/Hardware-HOWTO". This isn't a joke, I'm dead serious. The linux standard is the kernel, so the sooner we convince manufacturers to provide modules for the KERNEL for their devices, the better we'll be. It could be worse.. they could be creating must-run-as-root daemons with closed-source APIs. I say we formalize an existing standard.. afterall, it's worked quite well so far.
It's not the level of skill, or lack thereof, of the script kiddies, it is the lack of time on the part of system administrators. Security is a low priority for most organizations. Why spend $50,000 to secure your computing facilities when you can spend that on a choice advertisement spot on tomorrow's evening news?
Justify security expenditures to management and you'll solve the internet's "security problem" lock, stock and barrel.
You have to remember that encryption is a tool like any other, and its use or misuse is determined by personal ethics and law. In the same way that a gun advocate can advocate that every citizen should be able to bear arms while saying murder is bad, geeks have a seperation between "owning" and "using".
Given that a benchmark as popular as this will tend to have vendors adding, uh, "features" to make their webservers run faster for the benchmark, how did you manage to beat them anyway? Did you modify the TCP/IP stack? DoS the other servers during the test? Connect a compulsator to a large coil? Slashdot is dying to know.
Slashdot Mirror
In the software world, it appears that often only the commercial leader is really profitable. For all the also-rans, open sourcing is a good alternative for the creator of the software and benefits everybody (except the frontrunner).
Another, similar route to open source software is through research projects that, for one reason or another, aren't commercialized; the research code is released and often becomes an important open source/free software system.
We should be happy about that: much (if not most) open source and free software started out that way.
Because so much free software starts out as commercial or research projects that, I think it's important to think about how to encourage development and research organizations to build it in such a way that the transition to free software will be easy. That means that such organizations should find it easy to use existing free software libraries, build on open APIs with free implementations, and should not feel the need to rely on proprietary libraries (which would make freeing the software later much harder).
One thing that I think is very important is to use licenses like LGPL or BSD (as opposed to GPL or QPL) for important libraries. Research and development organizations will not use software if that means making a strong commitment early on to open sourcing their software later or face uncertain expenses later. Both GPL and QPL, unfortunately, impose such uncertainties and limit options. If there is no unencumbered free or open source software, they will pick the best and most affordable proprietary libraries to build on.
The LGPL and BSD licenses, on the other hand, allow development and research organizations to keep their options open for what to do with their code. When infrastructure libraries (standard libraries, networking, gui, etc.) are released under those licenses, research and development organizations can use them, and when they decide to release their software as "free software", it will be so much more useful to the free software community than if it had been based on proprietary libraries or APIs.
For similar considerations, I think it's also important to get as much free software infrastructure on Windows. If companies start programming to free software APIs on Windows (and they have to cover the Windows market), when they go open source, their software will be much more useful to the free software community. So, the more unencumbered networking, database, and GUI libraries we can get onto Windows, the better.
So, keep that in mind when thinking about policies and licenses. While the idea that all free software is created by altruistic volunteers is appealing (and a significant amount of free software is), the reality is that a lot of free software is created by companies and donated if the software turned out not to be a winner in the market or is otherwise not commercializable. Making the life of those companies easier and allowing them to develop code that interoperates well with other free software is a win for everybody.
Securing a system does not mean checking the bug lists and applying the appropriate patches, or by throwing in a buzz-word Firewall. Although that is an excellent start, You can see the big difference with NT and OpenBSD.
NT has a decent security model. But Microsoft's goals with NT is functionality, not security. So with file permission defaults such as Everyone: FULL CONTROL and Exchange KM Server Admin passwords being "Password", it's not hard to see that M$ wants Admins to have an easy job. Everything works, but it ain't secure. Although one can configure NT to be secure, it will take many hours of work and tests.
On the other side of the spectrum, consider OpenBSD. Paranoid? Obviously. Everything's off, users have no access to anything, users can't su unless they're allowed. Here, security is well taken care of, but the admin's big job here is opening up the system so users can get some functionality.
Then put Linux in the middle. A relatively secure OS, with (as most distros) almost all daemons running without even asking for them. Shut off sendmail, wu-ftpd, httpd, etc, and boom, magnitudes more security.
Then consider the admin who uses the root account straight through telnet. One co-worker I knew does this on a regular basis, then brags that he's never been cracked!!! Patching bugs is the easy part...
This is not a trivial question. Firstly, SETI@Home uses the Aricebo Radio Telescope. This is a very nice dish for radio astronomy, but useless for SETI work. It's far too small. The smallest useful dish or array will be the hectare array, being built by the SETI Institute. Aricebo will only be able to detect signals from nearby stars that are: (a) at LEAST as strong as our most powerful RADAR, (b) SUSATAINED for a substantial period of time, (c) containing information on a carrier wave, (d) orbiting a planet or star, with no compensation for motion
In short, leakage (the most likely sort of signal to be found) will be invisible, actual RADAR type devices will be screened out (too short a duration and no information content), and any civilisation advanced enough to WANT to locate other civilisations by sending deliberate signals are likely to be filtered, by being screened out as local interference through a lack of doplar shift.
Methinks that SETI@Home is ingenious, but is using the wrong telescope. And it'll be finished before the RIGHT telescope has been built & put on-line.
As for "Open Sourcing" SETI@Home, it was, to start off with. The original UNIX client was GPLed. Hardly anyone bothered to do anything with it, and so they closed the source & shoved it over to a commercial house. Don't blame them - look to yourself first.
Having said that, SETI@Home's attitude has been somewhat attrocious. They've been going on about security, when that was never the cause of them going non-Open Source. Progress was. And part of that is their fault. They refused to set up a CVS repository, did VERY slow (and low-quality) releases, and basically impeded themselves at every turn. They should have done a damn sight better than that. Yes, there were only a few people there, which is EXACTLY WHY they needed to use CVS, rather than relying on manually testing every e-mailed patch, and rolling a fresh tarball by hand every few weeks or months.
Honestly, if SETI@Home has shown anything, it's shown that we should be less worried about intelligence "out there" and rather more worried by the lack of it down here.
Why not ban unsolicited commercial direct marketing? What would happen?
Well, the US Post Office would get an exemption on the grounds that junk mail subsidises other mail (or at least it should; I'm not sure if it's really not the other way around).
For phone, fax, and email direct marketing, a new business would be created. Consumers would get paid to opt-in. You could fill out a marketing demographic survey, and then you would get a credit on your phone bill paid for by the direct marketers who called you.
With opt-in systems, consumers get paid for putting up with advertising. Those who don't want the advertising pay their own way. This is already happening with ISPs. This is also how TV works (you can get free TV with ads, or premium/rental services without).
But the author realizes that it is infeasible to enforce copyright through technological means. Any copy protection can be broken by someone sufficiently motivated to do so, and somewhere out there on the internet there is bound to be someone who is sufficiently motivated. All it takes is one person to break the protection scheme, and then the cat is out of the bag. Consequently, copyright enforcement turns to laws and the tools of law enforcement. That isn't necessarily a bad thing, but we have to ask ourselves, if a law is widely violated by a majority of the citizens, then is that law really an expression of the will of the people (the ultimate force from which the law's authority is derived)? And if not, then should we really be enforcing legal penalties on those who violate this law that does not derive from the will of the people?
O.K., so there's a little out-and-out fixing. However, reviews often skim over negative points. Again, there are two common justifications. The first reason -- and one that affects "community" publications, such as those in the Mac and Linux worlds -- is that readers really *want* to hear good things about their community, rather than serious evaluations. That's understandable, but not (IMHO) good: Saplings may need protection, but they also need a chance to grow into storm-weathered oaks.
which may give the grammar checker fits but which won't erase your hard drive
Grammar checkers are for morons.
Given that a benchmark as popular as this will tend to have vendors adding, uhh, "features" to make their webservers run faster for the benchmark, how did he manage to beat them anyway? Did he modify the TCP/IP stack? DoS the other servers during the test? Connect a compulsator to a large coil?
Standardize hardware so you can have a reference box the admins can work with and then duplicate the settings on the server for download.
/usr/doc/HOWTO/Hardware-HOWTO". This isn't a joke, I'm dead serious. The linux standard is the kernel, so the sooner we convince manufacturers to provide modules for the KERNEL for their devices, the better we'll be. It could be worse.. they could be creating must-run-as-root daemons with closed-source APIs. I say we formalize an existing standard.. afterall, it's worked quite well so far.
We already have standards. You can get the latest version by typing "vi
We already have standards. You can get the latest version by typing "vi /usr/doc/HOWTO/Hardware-HOWTO". This isn't a joke, I'm dead serious. The linux standard is the kernel, so the sooner we convince manufacturers to provide modules for the KERNEL for their devices, the better we'll be. It could be worse.. they could be creating must-run-as-root daemons with closed-source APIs. I say we formalize an existing standard.. afterall, it's worked quite well so far.
Who says you have to read them?
You have to remember that encryption is a tool like any other, and its use or misuse is determined by personal ethics and law. In the same way that a gun advocate can advocate that every citizen should be able to bear arms while saying murder is bad, geeks have a seperation between "owning" and "using".
Same way we do it with TV. Advertisements have a distinct signature audio-wise - the volume usually is higher than the TV programming. Simply normalize the output, and chop the high point. But that may only be effective for, say, classical music - Fear Factory might not have the same approach. Now most music has a prelude, a quiet opener, or atleast a distinct silence. You can't put that ad in the middle of the song or people will scream murder. So it has to be at the beginning or the end.
There's also the encoding - they might mismatch the bitrates. They will almost definately use 1 encoder - and probably not the one the MP3 has. So you can just analyze the MP3 and determine when the encoder changes - non-trivial, but considering how much geeks detest forced-advertisement, I'm sure it's possible. It's a BIG itch to scratch.
Another method I can think of is to simply visit the advertiser's site. Most of them are MORE than happy to provide ALL of their releases. A few waveforms and an FFT calculation later, and all your mp3's have had that signature removed.
Given that the primary method of MP3 distribution is currently online, someone could simply md5 sum the "bad" mp3's, and blacklist them. The servers (or clients) could then automagically purge them from the network. THAT is a trivial programming exercise.
Cheers,
We already have standards. You can get the latest version by typing "vi /usr/doc/HOWTO/Hardware-HOWTO". This isn't a joke, I'm dead serious. The linux standard is the kernel, so the sooner we convince manufacturers to provide modules for the KERNEL for their devices, the better we'll be. It could be worse.. they could be creating must-run-as-root daemons with closed-source APIs. I say we formalize an existing standard.. afterall, it's worked quite well so far.
It's not the level of skill, or lack thereof, of the script kiddies, it is the lack of time on the part of system administrators. Security is a low priority for most organizations. Why spend $50,000 to secure your computing facilities when you can spend that on a choice advertisement spot on tomorrow's evening news?
Justify security expenditures to management and you'll solve the internet's "security problem" lock, stock and barrel.
You have to remember that encryption is a tool like any other, and its use or misuse is determined by personal ethics and law. In the same way that a gun advocate can advocate that every citizen should be able to bear arms while saying murder is bad, geeks have a seperation between "owning" and "using".
Given that a benchmark as popular as this will tend to have vendors adding, uh, "features" to make their webservers run faster for the benchmark, how did you manage to beat them anyway? Did you modify the TCP/IP stack? DoS the other servers during the test? Connect a compulsator to a large coil? Slashdot is dying to know.
I'm going to use this sparingly, so I don't get bitchslapped right away.
While I appreciate the unusual brevity of Katz's article, I'd like to know whether or not the book is worth reading.
--