The alternative to the scenario you depect here is not "Microsoft embraces the open source philosophy and releases their specs and code" but rather "Microsoft, being unable to interoperate with the restrictive GPL license, chooses instead to develop a new and even more incompatible protocol internally".
GPL'd code, especially cricitial "reference implementation" code and protocols doesn't necessarily lead to a blissful brotherly-love and free exchange of code. Sometimes it gets us crap like SMB which is even more difficult to to coexist with.
If Kerberos were encumbered by the GPL, Microsoft simply would have ignored it and the quadzillions of Windows users would have seen no benefit at all from the existing, well-tested, and useful code. Rather, they'd now be stuck with some new protocol with new and relatively untested code behind it. Which is better for the user?
Also, it's an interesting example you use. The reports of Microsoft's Kerb incompatibility have been grossly overstated. I've had no difficulties getting FreeBSD K5, Win2K Auth (Kerb-based), and even mod_auth_kerb to coexist quite elegantly. A few Kb of mod_auth_kerb on your apache server and you can be authenticating users against a Win2K domain/realm.
I doubt we'd have it that easy if Microsoft had found kerberos inaccessable to them as a result of the GPL. At best, all our friends over at the Samba project would be scrambling to reverse-engineer yet another undocumented protocol.
With the possible exception of emacs, you've done nothing more than prove AC's point quite effectively.
KDE: Making an open-source Windows
Windowmaker/AfterStep: Making an open-souce NeXTStep
Mozilla: Bringing the web technology of the mid-90's to the open source community
XChat: A cheap knock-off mIRC clone for the open source world
gimp: We'll keep saying it's a suitable replacement for PhotoShop until someone believes us
Now go grab your favorite public-domain dictionary and look up the word "innovation". You'll find that none of the above products are innovative in any way. In fact, the stated goal for most of the projects you mentioned is simply to replicate the function of a specific piece of proprietary software.
The original statement that "GPL sw is entirely derivative from A to Z", while not 100% accurate, certainly hits very close to the mark.
While I enjoy my open source world, and my ability to customize and extend without barriers, you'd be blind not to notice that the best the open source community is usually able to muster is simply running a step behind the innovations developed in the commercial software world.
You cannot, under any circumstances "make [BSD licensed code] proprietary. Ever. Think it through, your argument doesn't make sense.
If some company takes BSD Licensed code and incorporates it into a proprietary product the original code is unaffected. It's still just as free as it ever was in its full BSD licensed glory. To use your words, the original code "remains free".
It hasn't been "stolen", it hasn't been "made proprietary". In fact, it hasn't been affected at all. It's just as useful (or useless) as ever.
The company that's now trying to make a living selling their proprietary software will succeed or fail solely on the merits of the value of *their* efforts and labor. If the code/documentation/marketing/support they've produced is valuable, they may just be successful.
In my eyes, this is a far better situation (and a much nobler form of sharing) than one where the original authors restricted their code and only made it available to people who use the same license they do.
Is FreeBSD no longer "free" code now that Apple has used large chunks of it in MacOS X? No, of course not.
I actually don't know many open sourcers who "prefer Linux". What I find to be far more common are open sourcers who have only used Linux and do not have much experience with the alternative opensource platforms. It's unfair to call this attitude a "preference" for Linux. I would infer from your question that you fall into this category (and are in good company).
Of those folks who have used both FreeBSD and Linux, well, they all prefer FreeBSD of course.:) All glibness aside, there's a huge contingent of FreeBSD users and developers who were first exposed to open source unix through Linux and for one reason or another find FreeBSD to more closely meet their needs and goals.
Turn the unix philosophy on its ear...
on
MySQL FS
·
· Score: 2
Unix: "Everything is a file"
Linux: "Everything is a file except for the files, which are records."
The only part of this comment that is "utter bullshit" is the part where he implies that someone would be stupid enough to be using telnet in this day and age. Surely we're all smart enough now to know that telnet is a giant sucking chest wound of a security hole. Nobody is actually stupid enough to still be using telnet these days, right?
Damn, people. It's not like OpenSSH is a big secret.
I still say that backbone providers should throw all port 23 traffic on the floor just on principle. It's no different than hiding your friend's car keys until he sobers up.
I'd love to see a distributed.net chess project. It's hard to get too enthused about that, though, since my single computer can already do a fine job at kicking my ass in chess even without getting help from everyone else's computers
There have been a few stalled attempts at designing and developing a chess core for the distributed.net client, but none have ever found any traction or managed to attract a person motivated enough to make it happen. We'd certainly love to assist someone interested and committed to developing one, though.
I think that it's extremely unfair or uninformed to describe this as
distributed.net "selling out". distributed.net is, and will always be, a
501(c)(3) not-for-profit, tax-exempt organization. The projects and
activities of distributed.net will continue to be cool, public-interest, and
non-commercial in nature.
If you, as a distributed.net participant, are interested in running a
commercial distributed computing client then you now have a way of doing
that without turning your back on distributed.net, its community, and the
past work you've performed. distributed.net will port its current and future
projects to the UD platform, and you'll be able to download the UD agent
software and continue to participate in RC5 or OGR alongside commercial
projects. If you are as excited about the commercial potential of distributed
computing as we are, then this will likely be a very attractive option to
you. If, however, you're uninterested in the commercial applications for
distributed computing (or your boss won't let you be interested in it on
the company kit), then you can just continue to run the good, old dnetc cow
and the only change you'll see is a faster, more reliable statsbox.
We are also optimistic that the support and assistance that this partnership
can bring to distributed.net will also assist in its ability to develop and
deploy new and exciting projects, which benefits everyone.
For me personally, it just means that I've traded in my old day job for a new
day job which just happens to be something that I've enjoyed doing as an
avocation for the past four years. For once, my day job will actually
augment my contributions to distributed.net and not simply compete for my
time and motivation. Finally being able to get paid to do the work I've
been doing for free for so many years doesn't feel like "selling out" so much
as it feels like a really great job.
If if you feel uncomfortable about my turning the work and time I've donated
to distributed.net into an opportunity to work hard and contribute time into
a commercial venture that I'm enthusiastic about, that doesn't change the
mission, focus, and activities of the non-profit that has enjoyed your support
and energies. distributed.net is larger than any of us, and will continue
to be successful in its mission, hopefully with your continued support.
I'm glad to know that I don't need to contemplate a Guinness boycott. Having to give up Guinness would be uncomfortable enough that it might drive me to drink even more, and then where would I be?
The phrase "just say no" is as effective in preventing drug abuse as saying "have a nice day" is in treating clinical depression.
I had a weird dream friday night...
on
Kuro5hin Returns
·
· Score: 2
I had a dream friday night that kuro5hin came back online and
somehow, I'd managed to stumble upon this fact before the news hit slashdot.
As part of their recovery, they'd had to wipe out the user login database,
so everyone was having to create new user account, and since it the site
had only just then been re-introduced, only five people had managed to create
their accounts. I was really excited that I was going to be able to snag a
really 'leet low user id number, so I clicked the button to re-create my
account. However, since I'm just on a crappy old modem, and it's slow as
hell, the form I had to fill out was taking forever to load up. I just
knew that while I was sitting and waiting for the whole page to load, the
article would hit slashdot and I'd be screwed. By the time I had the page
loaded up and filled out, I ended up getting a seven-digit ID number.
I was so bummed.
I think this means I need a life.
There's really not much difference between the two
on
GPG vs. PGP?
·
· Score: 5
I just recently migrated from pgp5.0 (for unix) to gnupg and frankly the differences are quite superficial.
If you're in a windows environment, there's really no choice -- pgp is by far the more integrated and useful solution. If you're using a Windows mail reader, then go for PGP for Windows.
In a unix environment, you'll find either to be roughly equivalent. Some minor differences I've noticed since making the migration to gnupg:
gnupg has a nifty feature that makes it automatically grab a key off the keyserver if I read a signed email by someone whose key I don't have. This is nifty.
gnupg apparantly doesn't have a way to retrieve a key from the keyservers by email. This is a real pain in the ass. With pgp, you can just import the key for "nugget@slacker.com" and if there are keys on the server for that email, they'll be imported. gnupg requires you to know the key ID (like E43C5FC3).
The pgp command line syntax and commands are cryptic and obtuse
The gnupg command line syntax and commands are unnecessarily verbose and will push you over the edge with your carpal tunnel if you're doing much manual work
PGP has the edge for application integration, but this is rapidly changing. gnupg works fine with mutt, which is the mail reader you want to be using anyway, so it's a moot point.:)
gnupg's key management is vastly superior to pgp's in both conveying key-management information as well as allowing access to key-management functions.
Plus, there's a nifty GUI for gnupg that's usable but which is called GPA (It's in/usr/ports/security/gpa).
If you're already using pgp, the differences aren't enough to justify conversion, but if you're just starting out -- gnupg seems to be the most viable option. And, of course, mutt is too good to believe.
The learning curve for either is the same, mainly just getting past public key crypto concepts and mechanisms. Wrapping your brain around "public key" and "private key" and the difference between "signing" and "encrypting" is well over half the battle.
No geek's bookshelf is complete without this one. It's an approachable and practical coverage of encryption technology with a focus on application and use.
During the three years of RC5-64 processing, distributed.net has also managed to complete three DES encryption contests, complete the CSC contest sponsored by CS Communications and Systems, as well as start the Optimal Golomb Rulers project (which actually provides tangible scientific and commercial benefit).
We're currently processing, simultaneously, RC5-64, OGR-24, and OGR-25 work.
Plus, we've got about a quarter of a million machines, not 100,000.:)
Your first requirement is quite reasonable and any distributed computing project (commercial or otherwise) would be wise to do exactly that.
Howerver, it seems unlikely that a method for distributing trusted open-source clients will ever be developed. Jeff Lawson, the chief architect of the distributed.net software has written a white paper discussing the various techniques which may be employed when trying to verify the validity of work performed on untrusted machines. You can read it here.
At distributed.net, we release as much of the source code as possible, but compromise at obfuscating the function of the networking and file-handling code. In this way, we make tampering with the clients more difficult.
While we recognize that not releasing all the source and relying on binary-only clients still doesn't completely eliminate the possibility of sabotage, we feel it is a beneficial contribution to our overall security implementation.
Joe, you've made this claim a few times here (also in post #121) yet you've completely failed to explain why you think that people would inherently be motivated to share their code in the absence of copyright.
That assumption couldn't be more wrong.
If there were no copyright, then there would only be two types of source code:
First, there would be public domain code. All open source projects would fall
into this category. This code would be open, available, and owned nobody and controlled by noone. Anyone could use this code for any purpose.
Second, there would be code that nobody ever sees. Individuals and organizations
who wanted to produce closed-source software would have to shield, obscure, and otherwise
protect their code with contracts, usage licenses, and security.
The big difference would be that the public domain code would have no protection
whatsoever from being absorbed by closed-source projects. There would be no protection
for programmers who wished to enforce their choice of open source development on others.
In a world without copyright (and therefore no GPL) there would be nothing to prevent
Microsoft from using any and all of the Linux kernel code in their own closed-source
products. Without copyright protection, if your code was open, it would have to
be public domain.
It is copyright law, and nothing else, that gives the GPL its teeth. Don't believe for a minute that the lack of copyright protection will somehow eliminate all closed-source software. The truth is, without the protection of copyright, there's no middle ground and we'd see less, not more open-source code.
Anyone who was around and using software in the late seventies and early eighties
knows exactly what the software world would look like without copyright. Back when
nobody knew what "software" meant, it was very unclear exactly how much protection
copyright offered for software. Copyright law took several years to mature and adapt
to the computer revolution and during that period the growing pains were sharp and
harsh.
Would we really want to return to the days of dongles, hardware copy protection,
usage contracts, and burdensome licenses? Without copyright, that's what software
houses would have to fall back upon to protect their intellectual property.
It wasn't until copyright established itself in the software world that we were
finally able to move past those cumbersome and ineffecient methods.
If this concept bothers you, ask yourself why? The foundation of the GPL is that programmers should have the right to dictate how their code is used. If you accept the GPL, you accept that a programmer has an inherent right of control over their code that they can then be able to say "this code should never be used in a closed-source program".
How is it that programmers should have this right and musicians should not? Why should software have protections that music should not? Shouldn't a musician have the same degree of control and be able to say "this song shouldn't be made freely available"?
While I'm sure you'd love to write off the "GPLNet" guy (cid #17) as just a simple troll, this isn't the case. The theoretical GPLnet that the AC proposes circumvents the wishes of GPL programmers in the same manner that napster circumvents the wishes of artists who do not wish to have their music freely distributed. Instead of calling those on the other side of the argument trolls and stating your opinion as if it was an undisputable truth, why don't you take a stab at actually supporting your position with some reasoning and logic. Then, perhaps, we could take your opinion seriously.
cruelworld has already said it more eloquently than I can, but it needs repeating
Copyright is just one of many ways to protect software intellectual property. Two decades ago, when the scope of copyright protection over software was in question, we saw many of these methods employed. Believe me, it was not a better world for software users then.
Without copyright, closed-source software would continue to exist. The publishers would just be forced to protect it with far less convienent methods like copy protection and restrictive licenses.
While cruelworld's examples are the most frightening, there are plenty of other methods.
It's possible to sell Microsoft Windows (to use your example) in a world without copyright if that software will only run if you have a certified original microsoft windows dvd and duplicating that dvd is impractical. Or how about a nice usb unlocker device that required you to swipe your visa or mastercard before the software would run?
The means and techniques available to protect software exist in the absence of copyright, they're just a lot less friendly to the users.
Without copyright, the software world is a worse place, not a better place.
And there is always the fundamental philosophical issue. If you are a GPL supporter, then you believe that a programmer has a right to control how his or her code is used. Copyright is the means by which that right is enforced.
If you don't agree that a programmer has a right to dictate the terms of use for their code, then you should be advocating that software be released in the public domain, and not under a license like the GPL.
This couldn't be more wrong. If there were no copyright, then there would only be two types of source code:
First, there would be public domain code. All open source projects would fall into this category. This code would be open, available, and owned nobody and controlled by noone. Anyone could use this code for any purpose.
Second, there would be code that nobody ever sees. Individuals and organizations who wanted to produce closed-source software would have to shield, obscure, and otherwise protect their code with contracts, usage licenses, and security.
The big difference would be that the public domain code would have no protection whatsoever from being absorbed by closed-source projects. There would be no protection for programmers who wished to enforce their choice of open source development on others.
In a world without copyright (and therefore no GPL) there would be nothing to prevent Microsoft from using any and all of the Linux kernel code in their own closed-source products. Without copyright protection, if your code was open, it would have to be public domain.
It is copyright law, and nothing else, that gives the GPL its teeth. Don't believe for a minute that the lack of copyright protection will somehow eliminate all closed-source software. The truth is, without the protection of copyright, there's no middle ground and we'd see less, not more open-source code.
Anyone who was around and using software in the late seventies and early eighties knows exactly what the software world would look like without copyright. Back when nobody knew what "software" meant, it was very unclear exactly how much protection copyright offered for software. Copyright law took several years to mature and adapt to the computer revolution and during that period the growing pains were sharp and harsh.
Would we really want to return to the days of dongles, hardware copy protection, usage contracts, and burdensome licenses? Without copyright, that's what software houses would have to fall back upon to protect their intellectual property. It wasn't until copyright established itself in the software world that we were finally able to move past those cumbersome and ineffecient methods.
If this concept bothers you, ask yourself why? The foundation of the GPL is that programmers should have the right to dictate how their code is used. If you accept the GPL, you accept that a programmer has an inherent right of control over their code that they can then be able to say "this code should never be used in a closed-source program".
How is it that programmers should have this right and musicians should not? Why should software have protections that music should not? Shouldn't a musician have the same degree of control and be able to say "this song shouldn't be made freely available"?
If there were no copyright, the GPL would be unnecessary
This couldn't be more wrong. If there were no copyright, then there would only be two types of source code:
First, there would be public domain code. All open source projects would fall into this category. This code would be open, available, and owned nobody and controlled by noone. Anyone could use this code for any purpose.
Second, there would be code that nobody ever sees. Individuals and organizations who wanted to produce closed-source software would have to shield, obscure, and otherwise protect their code with contracts, usage licenses, and security.
The big difference would be that the public domain code would have no protection whatsoever from being absorbed by closed-source projects. There would be no protection for programmers who wished to enforce their choice of open source development on others.
In a world without copyright (and therefore no GPL) there would be nothing to prevent Microsoft from using any and all of the Linux kernel code in their own closed-source products. Without copyright protection, if your code was open, it would have to be public domain.
It is copyright law, and nothing else, that gives the GPL its teeth. Don't believe for a minute that the lack of copyright protection will somehow eliminate all closed-source software. The truth is, without the protection of copyright, there's no middle ground and we'd see less, not more open-source code.
Anyone who was around and using software in the late seventies and early eighties knows exactly what the software world would look like without copyright. Back when nobody knew what "software" meant, it was very unclear exactly how much protection copyright offered for software. Copyright law took several years to mature and adapt to the computer revolution and during that period the growing pains were sharp and harsh.
Would we really want to return to the days of dongles, hardware copy protection, usage contracts, and burdensome licenses? Without copyright, that's what software houses would have to fall back upon to protect their intellectual property. It wasn't until copyright established itself in the software world that we were finally able to move past those cumbersome and ineffecient methods.
If this concept bothers you, ask yourself why? The foundation of the GPL is that programmers should have the right to dictate how their code is used. If you accept the GPL, you accept that a programmer has an inherent right of control over their code that they can then be able to say "this code should never be used in a closed-source program".
How is it that programmers should have this right and musicians should not? Why should software have protections that music should not? Shouldn't a musician have the same degree of control and be able to say "this song shouldn't be made freely available"?
As ozzmosis and questionlp have indicated, there is sblive support in FreeBSD 4. Although I'm curious exactly why there needs to be a howto on using one. It's a simple matter of "device pcm" in your kernel config and you're ready to go.
The howto listed above lists steps which are no longer necessary and haven't been for quite some time.
The only issue I'm aware of (which may be resovled, but hadn't been as of about a month ago) is that the sblive driver appears to conflict with some systems using ECC memory. I had to disable ECC in my bios for some reason. Before doing so, I experienced occassional lockups during pcm playback.
The "feature" they're referring to is the USB Connection not the hotsync itself. This is correct. The current PalmOS Hotsync doesn't support a USB connection in Win2K. You must use a serial connection to the cradle. According to the palm.com site, this will be remedied in the next release of the software.
Slashdot Mirror
Windows 2000 and MIT kerberos 5 are completely interoperable, and Microsoft's changes are well-documented and "legal" according to the kerberos spec.
GPL'd code, especially cricitial "reference implementation" code and protocols doesn't necessarily lead to a blissful brotherly-love and free exchange of code. Sometimes it gets us crap like SMB which is even more difficult to to coexist with.
If Kerberos were encumbered by the GPL, Microsoft simply would have ignored it and the quadzillions of Windows users would have seen no benefit at all from the existing, well-tested, and useful code. Rather, they'd now be stuck with some new protocol with new and relatively untested code behind it. Which is better for the user?
Also, it's an interesting example you use. The reports of Microsoft's Kerb incompatibility have been grossly overstated. I've had no difficulties getting FreeBSD K5, Win2K Auth (Kerb-based), and even mod_auth_kerb to coexist quite elegantly. A few Kb of mod_auth_kerb on your apache server and you can be authenticating users against a Win2K domain/realm.
I doubt we'd have it that easy if Microsoft had found kerberos inaccessable to them as a result of the GPL. At best, all our friends over at the Samba project would be scrambling to reverse-engineer yet another undocumented protocol.
With the possible exception of emacs, you've done nothing more than prove AC's point quite effectively.
KDE: Making an open-source Windows
Windowmaker/AfterStep: Making an open-souce NeXTStep
Mozilla: Bringing the web technology of the mid-90's to the open source community
XChat: A cheap knock-off mIRC clone for the open source world
gimp: We'll keep saying it's a suitable replacement for PhotoShop until someone believes us
Now go grab your favorite public-domain dictionary and look up the word "innovation". You'll find that none of the above products are innovative in any way. In fact, the stated goal for most of the projects you mentioned is simply to replicate the function of a specific piece of proprietary software.
The original statement that "GPL sw is entirely derivative from A to Z", while not 100% accurate, certainly hits very close to the mark.
While I enjoy my open source world, and my ability to customize and extend without barriers, you'd be blind not to notice that the best the open source community is usually able to muster is simply running a step behind the innovations developed in the commercial software world.
If some company takes BSD Licensed code and incorporates it into a proprietary product the original code is unaffected. It's still just as free as it ever was in its full BSD licensed glory. To use your words, the original code "remains free".
It hasn't been "stolen", it hasn't been "made proprietary". In fact, it hasn't been affected at all. It's just as useful (or useless) as ever.
The company that's now trying to make a living selling their proprietary software will succeed or fail solely on the merits of the value of *their* efforts and labor. If the code/documentation/marketing/support they've produced is valuable, they may just be successful.
In my eyes, this is a far better situation (and a much nobler form of sharing) than one where the original authors restricted their code and only made it available to people who use the same license they do.
Is FreeBSD no longer "free" code now that Apple has used large chunks of it in MacOS X? No, of course not.
Of course you get root, since they're using telnet and not openssh. Just sniff the traffic.
Of those folks who have used both FreeBSD and Linux, well, they all prefer FreeBSD of course. :) All glibness aside, there's a huge contingent of FreeBSD users and developers who were first exposed to open source unix through Linux and for one reason or another find FreeBSD to more closely meet their needs and goals.
Unix: "Everything is a file" Linux: "Everything is a file except for the files, which are records."
Damn, people. It's not like OpenSSH is a big secret.
I still say that backbone providers should throw all port 23 traffic on the floor just on principle. It's no different than hiding your friend's car keys until he sobers up.
If he disabled telnet, he did you a favor. Telnet is a sucking chest wound of a security hole. Install OpenSSH.
There have been a few stalled attempts at designing and developing a chess core for the distributed.net client, but none have ever found any traction or managed to attract a person motivated enough to make it happen. We'd certainly love to assist someone interested and committed to developing one, though.
If you, as a distributed.net participant, are interested in running a commercial distributed computing client then you now have a way of doing that without turning your back on distributed.net, its community, and the past work you've performed. distributed.net will port its current and future projects to the UD platform, and you'll be able to download the UD agent software and continue to participate in RC5 or OGR alongside commercial projects. If you are as excited about the commercial potential of distributed computing as we are, then this will likely be a very attractive option to you. If, however, you're uninterested in the commercial applications for distributed computing (or your boss won't let you be interested in it on the company kit), then you can just continue to run the good, old dnetc cow and the only change you'll see is a faster, more reliable statsbox.
We are also optimistic that the support and assistance that this partnership can bring to distributed.net will also assist in its ability to develop and deploy new and exciting projects, which benefits everyone.
For me personally, it just means that I've traded in my old day job for a new day job which just happens to be something that I've enjoyed doing as an avocation for the past four years. For once, my day job will actually augment my contributions to distributed.net and not simply compete for my time and motivation. Finally being able to get paid to do the work I've been doing for free for so many years doesn't feel like "selling out" so much as it feels like a really great job.
If if you feel uncomfortable about my turning the work and time I've donated to distributed.net into an opportunity to work hard and contribute time into a commercial venture that I'm enthusiastic about, that doesn't change the mission, focus, and activities of the non-profit that has enjoyed your support and energies. distributed.net is larger than any of us, and will continue to be successful in its mission, hopefully with your continued support.
I'm glad to know that I don't need to contemplate a Guinness boycott. Having to give up Guinness would be uncomfortable enough that it might drive me to drink even more, and then where would I be?
The phrase "just say no" is as effective in preventing drug abuse as saying "have a nice day" is in treating clinical depression.
I think this means I need a life.
If you're in a windows environment, there's really no choice -- pgp is by far the more integrated and useful solution. If you're using a Windows mail reader, then go for PGP for Windows.
In a unix environment, you'll find either to be roughly equivalent. Some minor differences I've noticed since making the migration to gnupg:
- gnupg has a nifty feature that makes it automatically grab a key off the keyserver if I read a signed email by someone whose key I don't have. This is nifty.
- gnupg apparantly doesn't have a way to retrieve a key from the keyservers by email. This is a real pain in the ass. With pgp, you can just import the key for "nugget@slacker.com" and if there are keys on the server for that email, they'll be imported. gnupg requires you to know the key ID (like E43C5FC3).
- The pgp command line syntax and commands are cryptic and obtuse
- The gnupg command line syntax and commands are unnecessarily verbose and will push you over the edge with your carpal tunnel if you're doing much manual work
- PGP has the edge for application integration, but this is rapidly changing. gnupg works fine with mutt, which is the mail reader you want to be using anyway, so it's a moot point.
:)
- gnupg's key management is vastly superior to pgp's in both conveying key-management information as well as allowing access to key-management functions.
Plus, there's a nifty GUI for gnupg that's usable but which is called GPA (It's inIf you're already using pgp, the differences aren't enough to justify conversion, but if you're just starting out -- gnupg seems to be the most viable option. And, of course, mutt is too good to believe.
The learning curve for either is the same, mainly just getting past public key crypto concepts and mechanisms. Wrapping your brain around "public key" and "private key" and the difference between "signing" and "encrypting" is well over half the battle.
No geek's bookshelf is complete without this one. It's an approachable and practical coverage of encryption technology with a focus on application and use.
We're currently processing, simultaneously, RC5-64, OGR-24, and OGR-25 work.
Plus, we've got about a quarter of a million machines, not 100,000. :)
Howerver, it seems unlikely that a method for distributing trusted open-source clients will ever be developed. Jeff Lawson, the chief architect of the distributed.net software has written a white paper discussing the various techniques which may be employed when trying to verify the validity of work performed on untrusted machines. You can read it here.
At distributed.net, we release as much of the source code as possible, but compromise at obfuscating the function of the networking and file-handling code. In this way, we make tampering with the clients more difficult.
While we recognize that not releasing all the source and relying on binary-only clients still doesn't completely eliminate the possibility of sabotage, we feel it is a beneficial contribution to our overall security implementation.
That assumption couldn't be more wrong. If there were no copyright, then there would only be two types of source code:
First, there would be public domain code. All open source projects would fall into this category. This code would be open, available, and owned nobody and controlled by noone. Anyone could use this code for any purpose.
Second, there would be code that nobody ever sees. Individuals and organizations who wanted to produce closed-source software would have to shield, obscure, and otherwise protect their code with contracts, usage licenses, and security.
The big difference would be that the public domain code would have no protection whatsoever from being absorbed by closed-source projects. There would be no protection for programmers who wished to enforce their choice of open source development on others.
In a world without copyright (and therefore no GPL) there would be nothing to prevent Microsoft from using any and all of the Linux kernel code in their own closed-source products. Without copyright protection, if your code was open, it would have to be public domain.
It is copyright law, and nothing else, that gives the GPL its teeth. Don't believe for a minute that the lack of copyright protection will somehow eliminate all closed-source software. The truth is, without the protection of copyright, there's no middle ground and we'd see less, not more open-source code.
Anyone who was around and using software in the late seventies and early eighties knows exactly what the software world would look like without copyright. Back when nobody knew what "software" meant, it was very unclear exactly how much protection copyright offered for software. Copyright law took several years to mature and adapt to the computer revolution and during that period the growing pains were sharp and harsh.
Would we really want to return to the days of dongles, hardware copy protection, usage contracts, and burdensome licenses? Without copyright, that's what software houses would have to fall back upon to protect their intellectual property. It wasn't until copyright established itself in the software world that we were finally able to move past those cumbersome and ineffecient methods.
If this concept bothers you, ask yourself why? The foundation of the GPL is that programmers should have the right to dictate how their code is used. If you accept the GPL, you accept that a programmer has an inherent right of control over their code that they can then be able to say "this code should never be used in a closed-source program".
How is it that programmers should have this right and musicians should not? Why should software have protections that music should not? Shouldn't a musician have the same degree of control and be able to say "this song shouldn't be made freely available"?
While I'm sure you'd love to write off the "GPLNet" guy (cid #17) as just a simple troll, this isn't the case. The theoretical GPLnet that the AC proposes circumvents the wishes of GPL programmers in the same manner that napster circumvents the wishes of artists who do not wish to have their music freely distributed. Instead of calling those on the other side of the argument trolls and stating your opinion as if it was an undisputable truth, why don't you take a stab at actually supporting your position with some reasoning and logic. Then, perhaps, we could take your opinion seriously.
Still have my original box, manual, and 5 1/4" disks. :)
Copyright is just one of many ways to protect software intellectual property. Two decades ago, when the scope of copyright protection over software was in question, we saw many of these methods employed. Believe me, it was not a better world for software users then.
Without copyright, closed-source software would continue to exist. The publishers would just be forced to protect it with far less convienent methods like copy protection and restrictive licenses.
While cruelworld's examples are the most frightening, there are plenty of other methods.
It's possible to sell Microsoft Windows (to use your example) in a world without copyright if that software will only run if you have a certified original microsoft windows dvd and duplicating that dvd is impractical. Or how about a nice usb unlocker device that required you to swipe your visa or mastercard before the software would run?
The means and techniques available to protect software exist in the absence of copyright, they're just a lot less friendly to the users.
Without copyright, the software world is a worse place, not a better place.
And there is always the fundamental philosophical issue. If you are a GPL supporter, then you believe that a programmer has a right to control how his or her code is used. Copyright is the means by which that right is enforced.
If you don't agree that a programmer has a right to dictate the terms of use for their code, then you should be advocating that software be released in the public domain, and not under a license like the GPL.
First, there would be public domain code. All open source projects would fall into this category. This code would be open, available, and owned nobody and controlled by noone. Anyone could use this code for any purpose.
Second, there would be code that nobody ever sees. Individuals and organizations who wanted to produce closed-source software would have to shield, obscure, and otherwise protect their code with contracts, usage licenses, and security.
The big difference would be that the public domain code would have no protection whatsoever from being absorbed by closed-source projects. There would be no protection for programmers who wished to enforce their choice of open source development on others.
In a world without copyright (and therefore no GPL) there would be nothing to prevent Microsoft from using any and all of the Linux kernel code in their own closed-source products. Without copyright protection, if your code was open, it would have to be public domain.
It is copyright law, and nothing else, that gives the GPL its teeth. Don't believe for a minute that the lack of copyright protection will somehow eliminate all closed-source software. The truth is, without the protection of copyright, there's no middle ground and we'd see less, not more open-source code.
Anyone who was around and using software in the late seventies and early eighties knows exactly what the software world would look like without copyright. Back when nobody knew what "software" meant, it was very unclear exactly how much protection copyright offered for software. Copyright law took several years to mature and adapt to the computer revolution and during that period the growing pains were sharp and harsh.
Would we really want to return to the days of dongles, hardware copy protection, usage contracts, and burdensome licenses? Without copyright, that's what software houses would have to fall back upon to protect their intellectual property. It wasn't until copyright established itself in the software world that we were finally able to move past those cumbersome and ineffecient methods.
If this concept bothers you, ask yourself why? The foundation of the GPL is that programmers should have the right to dictate how their code is used. If you accept the GPL, you accept that a programmer has an inherent right of control over their code that they can then be able to say "this code should never be used in a closed-source program".
How is it that programmers should have this right and musicians should not? Why should software have protections that music should not? Shouldn't a musician have the same degree of control and be able to say "this song shouldn't be made freely available"?
This couldn't be more wrong. If there were no copyright, then there would only be two types of source code:
First, there would be public domain code. All open source projects would fall into this category. This code would be open, available, and owned nobody and controlled by noone. Anyone could use this code for any purpose.
Second, there would be code that nobody ever sees. Individuals and organizations who wanted to produce closed-source software would have to shield, obscure, and otherwise protect their code with contracts, usage licenses, and security.
The big difference would be that the public domain code would have no protection whatsoever from being absorbed by closed-source projects. There would be no protection for programmers who wished to enforce their choice of open source development on others.
In a world without copyright (and therefore no GPL) there would be nothing to prevent Microsoft from using any and all of the Linux kernel code in their own closed-source products. Without copyright protection, if your code was open, it would have to be public domain.
It is copyright law, and nothing else, that gives the GPL its teeth. Don't believe for a minute that the lack of copyright protection will somehow eliminate all closed-source software. The truth is, without the protection of copyright, there's no middle ground and we'd see less, not more open-source code.
Anyone who was around and using software in the late seventies and early eighties knows exactly what the software world would look like without copyright. Back when nobody knew what "software" meant, it was very unclear exactly how much protection copyright offered for software. Copyright law took several years to mature and adapt to the computer revolution and during that period the growing pains were sharp and harsh.
Would we really want to return to the days of dongles, hardware copy protection, usage contracts, and burdensome licenses? Without copyright, that's what software houses would have to fall back upon to protect their intellectual property. It wasn't until copyright established itself in the software world that we were finally able to move past those cumbersome and ineffecient methods.
If this concept bothers you, ask yourself why? The foundation of the GPL is that programmers should have the right to dictate how their code is used. If you accept the GPL, you accept that a programmer has an inherent right of control over their code that they can then be able to say "this code should never be used in a closed-source program".
How is it that programmers should have this right and musicians should not? Why should software have protections that music should not? Shouldn't a musician have the same degree of control and be able to say "this song shouldn't be made freely available"?
The howto listed above lists steps which are no longer necessary and haven't been for quite some time.
The only issue I'm aware of (which may be resovled, but hadn't been as of about a month ago) is that the sblive driver appears to conflict with some systems using ECC memory. I had to disable ECC in my bios for some reason. Before doing so, I experienced occassional lockups during pcm playback.
The "feature" they're referring to is the USB Connection not the hotsync itself. This is correct. The current PalmOS Hotsync doesn't support a USB connection in Win2K. You must use a serial connection to the cradle. According to the palm.com site, this will be remedied in the next release of the software.