An excellent idea in theory. Now try and code such a beast:-)
Trying to build efficient structure into peer networks is like building a house of sand. They are extremely volatile.
You need to take into account numerous factors, like many orders of magnitude in bandwidth capacity between peers, NAT and unNAT'ed hosts, high churn rates, volatile peer groups, etc, etc.
Most people who have tried to overlay fragile yet elegant topologies on top of peer networks have seen them crumble under volatile real world scenarios.
This is not to say it is impossible, but that it is much harder to implement such a network in today's internet environment than it first appears.
I doubt that developers of those free p2p applications have gave much thought to efficiency
Some of us have. Search is much of the bandwidth in peer networks is wasted (downloads are downloads, but search can eat up a lot of bandwidth for little return)
There are some efficient, effective peer network search apps currently in development. Hopefully we can eventually leave gnutella and kazaa in the past and move on to more open, efficient networks...
the best practice for wireless users is to use SSH and/or SSL tunnels to secure sensitive traffic to a proxy
This can be abused, however, if someone sets up a rogue access point with the same ESSID (perhaps even spoofing a good AP's MAC) and then executes various known and implemented man-in-the-middle attacks against SSH/SSL sessions.
In fact, many, many applications fail silently in the presence of a MITM attack. If you are lucky you will see a warning from SSH. If you are UNlucky, you will think you are secure while someone with a rogue AP captures all your traffic, and perhaps even hijacks a session.
You can do this with commodity amplifiers (to ensure that your AP signal is higher than all the legitimate AP's) and easy to come by antennas.
I am seeing a lot of confused comments in this thread, so I will throw in my $0.02.
Disclosure: I wardrive on occasion. I keep a list of access points that I find while driving. Currently in excess of 1,000 for the Portland, OR area.
1. Why wardriving? Everyone has their reasons. Mine are security related. Myself and a small group of other local wifi enthusiasts enjoy passive monitoring to identify security weaknesses. We also inform insecure node operators of the fact that their networks are wide open.
We have found a number of extremely sensitive, wide open access points operated by city and state governments, corporations, and home users. By this I mean networks that are obviously not intended to be public.
If your government has weak security on sensitive information, this can affect you directly (which means Us, the wardrivers too). So we like to notify them of the vulnerabilities and give them information on fixing the holes. Sometimes we get paid to do this.
[You will notice the results page is missing GPS coordinates. This is intentional, as there are those out there who would take advantage of unsecured networks]
This is also usefull for identifying trends and generating usefull statistics.
2. How do you really secure a wireless network? You have a few options: Basic security and high security.
Basic Security: Enable MAC ID restrictions, allowing only those cards with a specific MAC id to connect to the network. Also turn on 128bit WEP encryption. You can switch to a lesser used channel, like 1 or 11 if you wish.
Please note that this is still easily circumvented with the right tools, like AirSnort and MAC ID spoofing. Despite this, most people will find a network in this state and move on. It significantly raises the barrier to entry.
High Security: Install a VPN with very good passwords or preferably something like SecureID cryptographic tokens. This is the only way to be truly secure, where truly secure is as good as the firewall VPN combo you use at work.
This is what I got my wife. It is a bit more subtle, which means she has no problems wearing it all the time, even when doing minor work with horses, etc.
Platinum bands do not have a mounted stone that can catch on things or fall out. This is a bigger problem than you think.
Platinum is also a truly scarce resource, and its high price is reflected by an open market rather than an artificial scarcity using monopoly powers (DeBeers).
In short, a nice platinum comfort fit band works great.
The problem is that gnutella's reliance on broadcast forwarding and indirect communication will always allow rogue peers to exploit bandwidth or queries in the network.
There are a number of alternative discovery mechanisms which do not suffere from these kinds of architectural problems.
For example, NeuroGrid and alpine both use social discovery and peer profiling to prevent bandwidth hogging or query spamming.
There are also hybrid network that use super peers like the Kazaa and Grokster clients.
There is only so much you can do to improve a flooding broadcast architecture. Gnutella will always have some kind of bandwidth and query problems no matter how optimized the clients become.
I am the first to admit this is a hack, but I have no idea what you think will suddenly implode in such a setup. It is one thing to be kludge / hack, and another to be unrecoverably faulty.
KVM over IP is going to be costly into the near future. This isn't exactly commodity hardware, so it may stay high for a looong time.
You may want to consider an alternative approach (which is what I have been doing ever since the remote KVM sticker shock faded) which obviates the need for a remote KVM at all.
For example: 1. All systems boot from custom CD-R (good for security too) which then boots the remainder off a network drive or perhaps hdd.
2. Remote power cycling (cheap, $100 for 8 ports you can controll over IP) is used to power cycle one or more machines to force a reboot.
3. If you need to reimage the OS, simply replace the OS stored on the boot server, or have the CDROM boot image reimage remotely when given a specific trigger (this is the area wide open for all kinds of solutions. Luckily, all software based using linux and cheap CDR's, network filesytems, etc)
This still has a number of drawbacks. If the machine doesnt come back, there is no remote KVM access to tell you what the bios is complaigning about (bad disk?).
The bootup process is cumbersome. I.e. you need to always boot from CDR to be able to reimage a system later (dedicated hosting) and such.
The main advantage of intelligent walking is the ability to find obscure or unpopular data quickly once a peer group is tuned to your preferences (all done locally using implicit query feedback when interacting with peers).
This is important as the paper mentions the problems random walkers have with regards to unpopular resources.
I use this on my home network to keep bandwidth usage allocated correctly on my cable modem connection. It works great. I have 20ms latency while gnutella, kazaa, and FTP uploads are all running concurrently.
This prevents you from the task of blocking them out completely, while ensuring that high priority student/teacher use of the net remains fast.
Chemical: Red Bull, Adderall (dextroamphetamine HCL), Lots of Water, Healthy Food snacked on at least once per hour.
Aural: Chemical Brothers, Crystal Method, Prodigy, etc, etc. Some good punk and rock is nice to mix in.
Visual: 19"+ Sony Trinitron E400 with a decent amount of light coming from behind and to the side of my desk. No flourescent, nothing directly behind causing glare. Muted sunlight may also work.
The next generation peer networks are going to make all of this a moot point. Large, fully decentralized open source peer networks have no point of centralized vulnerability to law suits or attack. They have no corporate owner to go after. They are written by the people, for the people, and nothing will be able to stifle their use to share and distribute digital information.
The RIAA/MPAA and other content industries know this, and are pushing for the only possible way to thwart this inevitable digital bazaar by using extreme legislation (SSSCA and co) to restrict general purpose computing and networking devices.
They will fail. The coming years will bring ever more resilient, secure, efficient, and useable peer networking software to accomplish everything from file sharing to colloborative development, distributed processing & storage, etc.
This is one of the few situations where the individual has the capability to fight back and win against the vested interests of the powers that be to restrict freedoms and profit from it.
Your missing the point. This is content distribution, where those "problematic public servers" are actually usefull. I.e indie bands sharing music (etree). And they server as Quality Control, you know your getting the files from a central source.
Regarding eDonkey, they provide no detailed information on how they implement multisource downloads, so it may be that they are actually very similiar. Who knows.
Lastly, swarmcast is designed for larger decentralized peer networks where no central broker is present. In that scenario FEC and cryptographically secure block transfer make sense, but its a lot of overhead for simply transferring a file. I dont see how your can say BitTorrent is potentially slower. BitTorrent will be faster, as it avoids that overhead entirely, and has a centralized broker/server to fall back on.
Sure. Fast Track is decentralized file sharing network where there is no guarantee that what you ask for is what you get. They may be codecon mp3's, they may be nasty midget porn incognito.
eDonkey likewise is more of a filesharing (aka, keyword search, then dowload hits) method.
Swarmcast is the closest relative to BitTorrent, but BitTorrent avoids the FEC encoding and cryptographically secure block verification in favor of a more centrally controlled broker that uses multi source downloading at various offsets to accomplish the same task.
In short, BitTorrent is a distribution system where a central server provides content, and peers requesting that content join a mulitsource downloading group where they also share offsets of data with each other (preferably) and download from the central server when necessary.
This isnt file sharing (really), this is content distribution in a fast and effective manner using peer networking concepts.
I worked on a large project (20+ developers) where this situation occured from time to time. There were specific interdependencies between some sources files for various parts of the development effort, and it was easy to step on other peoples feet unless specific steps were taken to prevent this.
Before I describe how we handled this situation, I want to stress the fact that if someone intelligently devides the labor according to how the changes will affect other parts of the code, the need for developers to sqabble over specific changes in specific files should be eliminated.
Labor should be devided at well defined "interface points" where the additions/changes to the interface can be done quickly, satisfying the needs of other developers requiring those interfaces to build against, and then completion of the underlying code can be done with little interference or effect on others.
In short, devide work along interface boundaries, and stub out interfaces with enough code to allow compiling, while developer(s) continue to actually implement the code behind the scenes. Thus, swapping in the actual code has no effect on any one else code, exept that the stubs are now full implementations and work correctly.
Ok, so what happens if the devision isnt clean and you have two people working on the same file?
NOTE: When I am talking about file granularity, or developers "owning" specific files, you can also substiture "subsystem", etc. Sometimes developers are working in entirely different areas of the source tree for the most part, and it makes sense to assign an entire sub tree to a specific developer. This is the devision by interface, which is the usual case.
What we did was assign specific files to specific developers, who have the most work to add/modify to the file. When other developers require changes to a file "owned" by another, they perform the merge, which is verified by both sides to work correctly, and then it is checked in by the "owner".
This was all accomplished using locks (file checked out, ClearCase) and multiple views. The locking of files was a benifit, as it prevented accidental overwrites of other peoples code. Once you check out a file and lock it, no one else (short of the administrator) can check in a modified version and clobber your changes.
Tree is something like this: RootBranch
|
|-- Devel
|
|-- AliceView ---- BobView
| |
[code] [code]
Alice and Bob are both working in a development branch. Alice has the files she is modifying and "owns" checked out and locked. Same for bob.
Bob realizes he needs to make changes to "something.cpp" to support some changes he is making in "modified.cpp".
He checks out a temporary version, unlocked, of "something.cpp" and makes the required changes.
He then notifies alice of the changes, and using the automated merge features she adds his changes, manually resolving conflicts if necessary.
Bob changes his view to use Alice's version of the file with the rest of the code from his view. He builds and verifies that everything is working correctly. Once this is verified, Alice can check in the changes, and Bob can now use the most recently committed version and continue on his merry way.
What this boils down to is basically enforcing ownership through locks to prevent accidental overwrites of others code, and defining clear lines of ownership so that a change is only accepted and merged when the person responsible for that code has tested it (in addition to the developer desiring his minor modifications be included)
You are vastly over simplyfying the concept of a timing source.
A true reference clock takes a number of inputs, GPS being a less desired form. Almost all of the major carriers also include an atomic clock as part of their reference.
The militiary pioneered the design of insane consistency when it comes to reference clock signals, with entire 1000+ page documetns describing the various levels of reliability and consistency and the proper combination of all sorts of timing sources from GPS to atomic clocks.
The phone networks will not go down if GPS does.
Re:GPGME - GPG Made Easy
on
How to Save PGP
·
· Score: 3, Informative
you can't get IO from another running process in ISO C
No, but you can use ISO C to make system calls (ported like everything else in the dual *nix/win/mac universes) that can communicate with the GPG process.
Really, this isnt that big of a deal. It's a slight inconvienance, but you still end up with a very portable library that can be used to interface with GPG in a programmable manner.
Re:GPG, OpenPGP, and what needs saving
on
How to Save PGP
·
· Score: 4, Informative
How 'bout putting the algorithm into a library?
This has been asked many, many times of the GPG developers, and they always have a very sound, technically reasonable explanation: Making a shared or static library for the GPG code would be a security risk.
Once you have the code linked in (statically or dynamically) you can do Bad Things to the GPG code. Manipulate static variables, change environment settings, corrupt memory, all in an attempt to compromise security.
This makes integration a bit more difficult, but there are still a number of wrapper libraries that provide similar functionality using fork() and exec() with the command line.
Personally I prefer a bit more integration effort with more security than vice versa.
GPG, OpenPGP, and what needs saving
on
How to Save PGP
·
· Score: 5, Insightful
In the article Phil focuses on easy to use GUI interfaces for less technically adept end users as the major feature that the OpenPGP/GPG projects need to focus on. This is the main advantage that the commerical version provided, and the main thing lacking in all the other alternatives.
He clearly states that the PGP protocol is in no danger whatsoever, and will continue to remain widely implemented.
Having spent many hours deciphering gpg command lines to use PGP to its full potential makes you realize how usefull a simple, easy to use GUI interface to a PGP would be. (Implicit in this task is integration with other applications, however, you can find plugin support for almost anything that you wish to use PGP in)
Slashdot Mirror
An excellent idea in theory. Now try and code such a beast :-)
Trying to build efficient structure into peer networks is like building a house of sand. They are extremely volatile.
You need to take into account numerous factors, like many orders of magnitude in bandwidth capacity between peers, NAT and unNAT'ed hosts, high churn rates, volatile peer groups, etc, etc.
Most people who have tried to overlay fragile yet elegant topologies on top of peer networks have seen them crumble under volatile real world scenarios.
This is not to say it is impossible, but that it is much harder to implement such a network in today's internet environment than it first appears.
I doubt that developers of those free p2p applications have gave much thought to efficiency
Some of us have. Search is much of the bandwidth in peer networks is wasted (downloads are downloads, but search can eat up a lot of bandwidth for little return)
There are some efficient, effective peer network search apps currently in development. Hopefully we can eventually leave gnutella and kazaa in the past and move on to more open, efficient networks...
the best practice for wireless users is to use SSH and/or SSL tunnels to secure sensitive traffic to a proxy
This can be abused, however, if someone sets up a rogue access point with the same ESSID (perhaps even spoofing a good AP's MAC) and then executes various known and implemented man-in-the-middle attacks against SSH/SSL sessions.
In fact, many, many applications fail silently in the presence of a MITM attack. If you are lucky you will see a warning from SSH. If you are UNlucky, you will think you are secure while someone with a rogue AP captures all your traffic, and perhaps even hijacks a session.
You can do this with commodity amplifiers (to ensure that your AP signal is higher than all the legitimate AP's) and easy to come by antennas.
This is news? People have been
scanning wireless
networks
for a long time now...
I am seeing a lot of confused comments in this thread, so I will throw in my $0.02.
Disclosure: I wardrive on occasion. I keep a list of access points that I find while driving. Currently in excess of 1,000 for the Portland, OR area.
1. Why wardriving? Everyone has their reasons. Mine are security related. Myself and a small group of other local wifi enthusiasts enjoy passive monitoring to identify security weaknesses. We also inform insecure node operators of the fact that their networks are wide open.
We have found a number of extremely sensitive, wide open access points operated by city and state governments, corporations, and home users. By this I mean networks that are obviously not intended to be public.
If your government has weak security on sensitive information, this can affect you directly (which means Us, the wardrivers too). So we like to notify them of the vulnerabilities and give them information on fixing the holes. Sometimes we get paid to do this.
[You will notice the results page is missing GPS coordinates. This is intentional, as there are those out there who would take advantage of unsecured networks]
This is also usefull for identifying trends and generating usefull statistics.
2. How do you really secure a wireless network? You have a few options: Basic security and high security.
Basic Security: Enable MAC ID restrictions, allowing only those cards with a specific MAC id to connect to the network. Also turn on 128bit WEP encryption. You can switch to a lesser used channel, like 1 or 11 if you wish.
Please note that this is still easily circumvented with the right tools, like AirSnort and MAC ID spoofing. Despite this, most people will find a network in this state and move on. It significantly raises the barrier to entry.
High Security: Install a VPN with very good passwords or preferably something like SecureID cryptographic tokens. This is the only way to be truly secure, where truly secure is as good as the firewall VPN combo you use at work.
This is what I got my wife. It is a bit more subtle, which means she has no problems wearing it all the time, even when doing minor work with horses, etc.
Platinum bands do not have a mounted stone that can catch on things or fall out. This is a bigger problem than you think.
Platinum is also a truly scarce resource, and its high price is reflected by an open market rather than an artificial scarcity using monopoly powers (DeBeers).
In short, a nice platinum comfort fit band works great.
The problem is that gnutella's reliance on broadcast forwarding and indirect communication will always allow rogue peers to exploit bandwidth or queries in the network.
There are a number of alternative discovery mechanisms which do not suffere from these kinds of architectural problems.
For example, NeuroGrid and alpine both use social discovery and peer profiling to prevent bandwidth hogging or query spamming.
There are also hybrid network that use super peers like the Kazaa and Grokster clients.
There is only so much you can do to improve a flooding broadcast architecture. Gnutella will always have some kind of bandwidth and query problems no matter how optimized the clients become.
House of cards?
I am the first to admit this is a hack, but I have no idea what you think will suddenly implode in such a setup. It is one thing to be kludge / hack, and another to be unrecoverably faulty.
KVM over IP is going to be costly into the near future. This isn't exactly commodity hardware, so it may stay high for a looong time.
You may want to consider an alternative approach (which is what I have been doing ever since the remote KVM sticker shock faded) which obviates the need for a remote KVM at all.
For example:
1. All systems boot from custom CD-R (good for security too) which then boots the remainder off a network drive or perhaps hdd.
2. Remote power cycling (cheap, $100 for 8 ports you can controll over IP) is used to power cycle one or more machines to force a reboot.
3. If you need to reimage the OS, simply replace the OS stored on the boot server, or have the CDROM boot image reimage remotely when given a specific trigger (this is the area wide open for all kinds of solutions. Luckily, all software based using linux and cheap CDR's, network filesytems, etc)
This still has a number of drawbacks. If the machine doesnt come back, there is no remote KVM access to tell you what the bios is complaigning about (bad disk?).
The bootup process is cumbersome. I.e. you need to always boot from CDR to be able to reimage a system later (dedicated hosting) and such.
We are currently running a BitTorrent load test at:
http://66.139.73.165/
If you would like to help out an open source content distribution network we would greatly appreciate it!
The main advantage of intelligent walking is the ability to find obscure or unpopular data quickly once a peer group is tuned to your preferences (all done locally using implicit query feedback when interacting with peers).
This is important as the paper mentions the problems random walkers have with regards to unpopular resources.
Use a non random walk (i.e. tuned to a specific domain or set of preferences) and let it walk the network with a lightweight UDP protocol:
cubicmetercrystal.com/alpine/
The conservative use of bandwidth with an intelligent search mechanism can provide scalable decentralized search for peer networks of any size.
A copy of the Flash animation is now available as well:
http://cubicmetercrystal.com/eff_tinsel.swf
I have a copy at:
m p3
/.'ed pretty good, so try to use some kind of mirror if possible.
http://cubicmetercrystal.com/eff_tinseltown_club.
The EFF is getting
Linux 2.4.x networking supports traffic control / quality of service.
Read up on the advanced networking: http://www.fibrespeed.net/~mbabcock/linux/qos_tc/
I use this on my home network to keep bandwidth usage allocated correctly on my cable modem connection. It works great. I have 20ms latency while gnutella, kazaa, and FTP uploads are all running concurrently.
This prevents you from the task of blocking them out completely, while ensuring that high priority student/teacher use of the net remains fast.
Chemical: Red Bull, Adderall (dextroamphetamine HCL), Lots of Water, Healthy Food snacked on at least once per hour.
Aural: Chemical Brothers, Crystal Method, Prodigy, etc, etc. Some good punk and rock is nice to mix in.
Visual: 19"+ Sony Trinitron E400 with a decent amount of light coming from behind and to the side of my desk. No flourescent, nothing directly behind causing glare. Muted sunlight may also work.
ISP's have safe harbor. The content industries can no sooner shutdown all ISP's than they can get the SSSCA passed.
Neither one is going to happen.
... the flow of digital information
The next generation peer networks are going to make all of this a moot point. Large, fully decentralized open source peer networks have no point of centralized vulnerability to law suits or attack. They have no corporate owner to go after. They are written by the people, for the people, and nothing will be able to stifle their use to share and distribute digital information.
The RIAA/MPAA and other content industries know this, and are pushing for the only possible way to thwart this inevitable digital bazaar by using extreme legislation (SSSCA and co) to restrict general purpose computing and networking devices.
They will fail. The coming years will bring ever more resilient, secure, efficient, and useable peer networking software to accomplish everything from file sharing to colloborative development, distributed processing & storage, etc.
This is one of the few situations where the individual has the capability to fight back and win against the vested interests of the powers that be to restrict freedoms and profit from it.
Your missing the point. This is content distribution, where those "problematic public servers" are actually usefull. I.e indie bands sharing music (etree). And they server as Quality Control, you know your getting the files from a central source.
Regarding eDonkey, they provide no detailed information on how they implement multisource downloads, so it may be that they are actually very similiar. Who knows.
Lastly, swarmcast is designed for larger decentralized peer networks where no central broker is present. In that scenario FEC and cryptographically secure block transfer make sense, but its a lot of overhead for simply transferring a file. I dont see how your can say BitTorrent is potentially slower. BitTorrent will be faster, as it avoids that overhead entirely, and has a centralized broker/server to fall back on.
Sure. Fast Track is decentralized file sharing network where there is no guarantee that what you ask for is what you get. They may be codecon mp3's, they may be nasty midget porn incognito.
eDonkey likewise is more of a filesharing (aka, keyword search, then dowload hits) method.
Swarmcast is the closest relative to BitTorrent, but BitTorrent avoids the FEC encoding and cryptographically secure block verification in favor of a more centrally controlled broker that uses multi source downloading at various offsets to accomplish the same task.
In short, BitTorrent is a distribution system where a central server provides content, and peers requesting that content join a mulitsource downloading group where they also share offsets of data with each other (preferably) and download from the central server when necessary.
This isnt file sharing (really), this is content distribution in a fast and effective manner using peer networking concepts.
I worked on a large project (20+ developers) where this situation occured from time to time. There were specific interdependencies between some sources files for various parts of the development effort, and it was easy to step on other peoples feet unless specific steps were taken to prevent this.
Before I describe how we handled this situation, I want to stress the fact that if someone intelligently devides the labor according to how the changes will affect other parts of the code, the need for developers to sqabble over specific changes in specific files should be eliminated.
Labor should be devided at well defined "interface points" where the additions/changes to the interface can be done quickly, satisfying the needs of other developers requiring those interfaces to build against, and then completion of the underlying code can be done with little interference or effect on others.
In short, devide work along interface boundaries, and stub out interfaces with enough code to allow compiling, while developer(s) continue to actually implement the code behind the scenes. Thus, swapping in the actual code has no effect on any one else code, exept that the stubs are now full implementations and work correctly.
Ok, so what happens if the devision isnt clean and you have two people working on the same file?
NOTE: When I am talking about file granularity, or developers "owning" specific files, you can also substiture "subsystem", etc. Sometimes developers are working in entirely different areas of the source tree for the most part, and it makes sense to assign an entire sub tree to a specific developer. This is the devision by interface, which is the usual case.
What we did was assign specific files to specific developers, who have the most work to add/modify to the file. When other developers require changes to a file "owned" by another, they perform the merge, which is verified by both sides to work correctly, and then it is checked in by the "owner".
This was all accomplished using locks (file checked out, ClearCase) and multiple views. The locking of files was a benifit, as it prevented accidental overwrites of other peoples code. Once you check out a file and lock it, no one else (short of the administrator) can check in a modified version and clobber your changes.
A short scenario:
Alice: owns file/tree "something.cpp"
Bob: owns file/tree "modified.cpp"
Tree is something like this:
RootBranch
|
|-- Devel
|
|-- AliceView ---- BobView
| |
[code] [code]
Alice and Bob are both working in a development branch. Alice has the files she is modifying and "owns" checked out and locked. Same for bob.
Bob realizes he needs to make changes to "something.cpp" to support some changes he is making in "modified.cpp".
He checks out a temporary version, unlocked, of "something.cpp" and makes the required changes.
He then notifies alice of the changes, and using the automated merge features she adds his changes, manually resolving conflicts if necessary.
Bob changes his view to use Alice's version of the file with the rest of the code from his view. He builds and verifies that everything is working correctly. Once this is verified, Alice can check in the changes, and Bob can now use the most recently committed version and continue on his merry way.
What this boils down to is basically enforcing ownership through locks to prevent accidental overwrites of others code, and defining clear lines of ownership so that a change is only accepted and merged when the person responsible for that code has tested it (in addition to the developer desiring his minor modifications be included)
You are vastly over simplyfying the concept of a timing source.
A true reference clock takes a number of inputs, GPS being a less desired form. Almost all of the major carriers also include an atomic clock as part of their reference.
The militiary pioneered the design of insane consistency when it comes to reference clock signals, with entire 1000+ page documetns describing the various levels of reliability and consistency and the proper combination of all sorts of timing sources from GPS to atomic clocks.
The phone networks will not go down if GPS does.
you can't get IO from another running process in ISO C
No, but you can use ISO C to make system calls (ported like everything else in the dual *nix/win/mac universes) that can communicate with the GPG process.
Really, this isnt that big of a deal. It's a slight inconvienance, but you still end up with a very portable library that can be used to interface with GPG in a programmable manner.
How 'bout putting the algorithm into a library?
This has been asked many, many times of the GPG developers, and they always have a very sound, technically reasonable explanation: Making a shared or static library for the GPG code would be a security risk.
Once you have the code linked in (statically or dynamically) you can do Bad Things to the GPG code. Manipulate static variables, change environment settings, corrupt memory, all in an attempt to compromise security.
This makes integration a bit more difficult, but there are still a number of wrapper libraries that provide similar functionality using fork() and exec() with the command line.
Personally I prefer a bit more integration effort with more security than vice versa.
In the article Phil focuses on easy to use GUI interfaces for less technically adept end users as the major feature that the OpenPGP/GPG projects need to focus on. This is the main advantage that the commerical version provided, and the main thing lacking in all the other alternatives.
He clearly states that the PGP protocol is in no danger whatsoever, and will continue to remain widely implemented.
Having spent many hours deciphering gpg command lines to use PGP to its full potential makes you realize how usefull a simple, easy to use GUI interface to a PGP would be. (Implicit in this task is integration with other applications, however, you can find plugin support for almost anything that you wish to use PGP in)