First, to those people who make the declaration "Don't be so paranoid, they can take your fingerprints from a door handle or a cup", I retort that you should then have no problem complying with a requirement from an employer/bank/whatever to take your DNA and keep it on file, because obviously they could just get it form a piece of hair or skin you leave around everywhere(welcome to Gattica!). That argument is a batch of crap. The taking of fingerprints is absolutely an invasion of privacy for those who are concerned about malice or undesired use/supeona of the information. And the people making the argument that a hash or encoding of the fingerprint data makes it impossible to use as evidence doesn't understand that law enforcement, etc. can fairly easily obtain that hash, then get a second scan from you and compare the hashes in order to positively identify you.
All that being said, most fingerprint scanners used for timeclocks, door locks, etc. don't store the data with sufficient precision to use it as credible evidence that the scan was you. This is part of why they are both non-trivial and pretty easy to fake. It's precisely that dual, semi-contradictory nature of fingerprint scanners that make them so useful as a biometric access device.
Of course, you have no idea if the biometric scanners used by this university have that kind of precision, so it's probably best for both you and the university if they simply modify the policy to state that the precision of data the devices gather do not and shall not be able to qualify as proof of identity of in a court of law.
Then you're clear. Your biometric data at that point has the same significance as an ID badge. Any use of that data as evidence must be corroborated.
It might not have been such a good idea to contact a paper or other news outlet unless the university refused to clarify their agreement.
I read your journal, and you're essentially talking about is NAT-PT, or a derivation therein. However, there are a couple of essential problems with those solutions:
1. Any protocol that imbeds IP address information into the upper-layer protocol will fail unless that mapping was previously created by the gateway.
2. The solution requires that all communication be through DNS. If the legacy device has an app which doesn't do DNS, how can it reach the endpoint? It can't without a manual mapping in the gateway. And what if the endpoint on the other side is also behind such a gateway? How do I figure out what IPv6 address to map it to?
Essentially, the IPv6 transition problem in it's current state was born because there are 2 primary issues when changing a lower-level protocol like IP:
1. How do endpoints contact each other?
2. How does the routing system get the packets to the endpoints?
IMHO These 2 problems are antithetical to each other. Making a backwards compatible solution to the endpoint problem was causing considerible trouble for those trying to route packets. You have to remember that there were ideas in place to imbed IPv4 addresses into IPv6 packets at a lower layer, but those ideas were canned because they required essentially importing the pre-existing IPv4 BGP routing tables into IPv6, and network operators wanted not only a clean routing solution, but one that was going to clean up the global prefix advertisement space.
So, being that IPv6 was largely created by network operators, a solution was chosen that would allow themselves to cleanly implement IPv6 (once you get the firmware updates, running a dual-stack backbone is actually really easy), and as the backbones could route the traffic, endpoints would deal with both existing.
From a deployment standpoint is basically breaks down to:
1. Do we want to design a protocol that is fast to deploy by backbone providers while continuing to maintain the stability of the existing network? Or,
2. Do we want to design a protocol that is easily interoperable between endpoints?
The designers picked option 1, believing that having a network up fast first and letting endpoints migrate slowly over to it was preferable to spending a ton more time getting a fully backwards-compatible network going so that people could switch really quick. Was that the right answer? I don't know. But we're living with option 1 today, let's see what endpoints can do about it.
And everyone who's a network admin knows that it is.
NAT has created a very lazy fix to the problem of network security and filtering. If you're behind NAT, you're not addressable unless UPnP or an explicit port forward does it for you, and that's extremely convenient.
In a situation where every single computer in a network is internet addressable (something not always desired in business, which is probably the reason IPv6 adoption is so slow), you have to implement a very strict firewall to block and filter unsolicited traffic to those machines. If you're NATing them, as long as your network is physically secure, you don't have a problem.
Although I agree with your points , your post has kind of fallen into the NAT trap itself.
When most people talk about security through NAT, it's never been about "addressability". It's been about reachability. NAT offered a convenient means of deploying a default security policy that says "people secured by me can get out, but noone can get in". There's no reason whatsoever that default firewall/router policy at both the corporate and consumer levels can do this with IPv6 very easily with a couple of canned policies. In fact, people wishing to seem "ultra-secure" can still use their firewall as a transparent proxy for their outbound connections, thus making all of their normal traffic still look to come from the router/firewall in question! With IPv6, firewall/router policy could stay exactly the same, with one key feature: everyone has a unique address.
In fact, people wishing to use uPNP to make dynamic firewall policy changes can still do so! Except that instead of using oddball port mappings, we can just route the same standard port over to the proper address. Done. There's nothing inherently wrong with uPNP for consumers wishing to maintain decent security without needing to know the details on how the security policy works, but with IPv6 it's now about real security, not getting around address scarcity.
This puts a lot less stress on network security than there should be in a business environment, and much less attention to what should or shouldn't be allowed through a local firewall, let alone a site firewall.
I'll stop ranting, but the point is that NAT has created an artificial deficit of proper network security, and I fear that when IPv6 becomes ubiquitous, NAT will linger on as a replacement for real security. The skills required to secure a fully addressable network of machines simply aren't needed in the majority of current environments because making every host in a network internet addressable today is simply not an option.
As stated above, I agree that making every host internet reachable is not an option, but making every host internet addressable is. People can choose at that point to continue to use NAT/Transparent proxy services to mask the true source of requests, or they may not. At least it's a choice. As for me, I'll make every one of my hosts internet reachable with a decent security policy and take advantage of all of the benefits both in capability and in troubleshooting, thank you very much.:)
Sounds to me like you're the one living in hobby-land. Most machines don't need an externally accessible IP.
You're precisely correct. However, this problem has nothing to do with externally accessible IP addresses. It's about connectivity and global uniqueness.
Let's say that I run the network for small company A. We used 10. private addresses for our network layout. My company get's bought by slightly bigger company B, that also uses 10. address space for their network. In all likelyhood, we're going to have address conflicts. So, I have 3 choices for integrating the 2 networks:
1. Renumber company A 2. Renumber company B. 3. Employ some kind of odd-ball double-NAT solution that makes both companies appear to have unique addresses from the other's perspective.
You can very easily see that the lack of globally unique IP addresses in this situation has created a huge mess that takes a lot of time and money to resolve. If both company A and company B used globally-unique IP address (v4 or v6!), this would have never been a problem. And both companies can very easily hide internally accessible and externally accessible hosts via routing and firewall policy.
In the company I work for, we deploy a VPN solution to allow 2000+ data gateways to connect to us to deliver data. Because each data gateway resides in a unique network often addressed via non-routable IPv4 addresses, I can never trust that the VPN IP that I assign to this data gateway will not conflict with the local network on which this is deployed. So, I got globally unique addresses from ARIN to do it. Guess what? I don't even advertise that route over BGP to the public internet! I only route it via my local AS. When people gather statistics by IPv4 usage, consider that there are quite a few of us who need globally unique IP space, but will never route that out publicly.
IPv6 is designed to provide a global pool of unique addresses so large that everyone can have a globally unique addresses, regardless of how one wishes to use it. This means that networks become an issue of connectivity, not one of address management.
The IPv6 working group almost got caught up in NAT mania: They initially created a reserved IPv6 space called "site local", which was designed to be treated in the exact same way as the current private address space. On further consideration, though, the working group decided that any "private" addresses are just silly and create more headache than what they are worth. The concept of "site local" simply means "I'm not going to advertise this route publicly". If you don't want to advertise your network over the public Internet, then just don't. Take your globally unique space and have fun with it.
If your target audience is business customers, the simple answer here is none. And to rebut some of the other comments to the contrary, here's why:
Businesses care about being legal
It has been proven, time and time again, that it is cheaper for a business to have licenses for all software they use than the risk of not. Many of the major software companies recognize this, and also recognize that maintenance of a licensing system is both technically bad and bad for business. To back up this with evidence, look at software companies that don't put technical protection measures in place for business software:
- Oracle
- Computer Associates
- Microsoft (This is a special case. Business customers get one key that always works, and that is only there because they sell the software in other markets).
Now, here's what you do to help keep people honest and take care of your bottom line:
- Make sure that your program installs and uninstalls itself correctly (I don't care what platforms you use), and make sure that your platform knows about it. There are lots of software solutions out there that let companies track what software is installed. If you make yourself visible to those solutions, then the IT department at that company will thank you, even if not vocally.
- Occasionally look at how big some of your customers are, and periodically ask a couple of them to do software audits for you. You, of course, need to make sure that the right to ask for such an audit is in your EULA.
- If a customer doesn't have enough licenses, ask them to settle up with you. Give them a discount, something to make settling up a relatively inexpensive operation.
- If a customer refuses to settle up, hire a lawyer.
Remember, at the end of the day, it is up to your customers to abide by your licensing terms. If they don't, they are breaking the law. That means little to a guy at home who isn't aware of the issues, but businesses of any meaningful size do care.
Also, to go to some other comments noted here, make sure your software is the best. If businesses are stealing it, it's more than likely because there isn't enough value in the software for them to pay for it.
Yeah, I had a sinking feeling that Microsoft's problem with the EU helped to push them into a deal. However, I don't think that MS would do this for goodwill only.
One has to ask themselves, what does Microsoft have to gain by entering into such an agreement? And what does Novell have to gain? There are some possibilities here that aren't too farfetched:
Virtual Servers - Microsoft missed the first boat on virtualization, and as far as I can see Microsoft Virtual Server doesn't have much in the way of market share. By entereting into an agreement with Novell, Microsoft is attempting to gain relevance in this space. This is actually a good move for Microsoft. At the same time, Novell could help with Windows running on top of Xen. They both have a common enemy here: EMC.
Patents - Let's face it, any large company wants to avoid patent wars with another large company. It just saves tons of money. No real news here to speak of.
In reading a lot of these, I see an overall trend to do a lot of OS comparison. Myself, I have experience with a lot of OS's, and I grew up using DOS, then OS/2, then Windows, then Linux. When I look at this, and what has come to dominate the desktop, I find that there are many, MANY good things in the current Linux distros, and *nix in general. There is also a lot of work left to be done.
UNIX distros, with the exception of OSX and some of the BSD's in general, suffer from one major problem: Age. HP/UX, AIX, Solaris, etc... are so stuck to the old tools that new ones must be reinvented from the ground up in their minds. The Solaris machines I've dealt are pretty much GNU/Solaris machines, since a lot of the basic admin tools I've replaced with GNU equivalents (how hard was it ever to add a -h flag to Solaris du or dh! Sheesh!). CDE is old and antiquated ( reminds me of being on Warp 3 again). I think this stems from the commerical and niche nature of those UNIXes, and that's why I think Linux is trumping them.
That being said, here's some of the problems that Linux needs to overcome to be easier to use for everyday joes:
1. The great desktop war: KDE is great, GNOME is great. However, many people have problems dealing with which one to develop for, and a lot of times which one to use. I've found that I love KDE's look and feel, but what we really need is a SIMPLE common API for developement, that then can get morphed by the desktop to look like that desktop. I know some work is being done towards this, and when it matures, what you will find is a basic toolkit for GUI development, and the KDE and GNOME toolkits will be extensions to allow for more advanced GUI work.
2. The filesystem layout war: I don't know how many times people have bashed the *nix filesystem layout. I'll tell you right now it's far, far better than a lot of other OS's out there right now. Although some ideas like directory contained applications is cool and has some other nifty applications (such as easy chrooting), we have package managers now, and I'll tell you right now that I've fallen in love with them. RPM and deb (NOT APT!) are both good tools for checking versioning information and determining where stuff is. This makes the filesystem layout less about where binaries and config files are, and more about disk placement and security (e.g. maybe I want somebody to run an application but not change it's config: easy to do with/usr/bin and/etc, but much more complicated when things are split up). Apt, both for RPM and for DEB, is really good at solving dependencies, but I think a bigger problem involves people actually MAKING packages. For some reason developers not familiar with package managers hate making packages. Things like InstallAnywhere are starting to create the same problem that Windoze has, which is uncontrolled application installation and apps that are hard or nearly impossible to uninstall. What we need here is a GUI toolkit for developers that allows for quick package management. Imagine an app that a developer could plug in some basic info for, and it would compile a pacakage for multiple pacakage managers, and for multiple distros, and even versions of distros in some instances! I could then just post the packages, and then let MIME take care of installing them for me. If we have pacakage management that get stupid easy, we get a similar system to OSX or Linspire, where software installation is a snap. And as a community, I think we can find a way. I believe that none of these third-party app problems will exist if there is a a good package development tool and the distro vendors make plugins that will ensure that the resulting package makes the right symlinks, etc... for that distro.
3. Just simply more automation. We have all of these nice scripting languages, wouldn't it be nice if we hand these quick scripts to Joe blow and have them work? If I could put a very basic GUI on top of my tool without needing to know the in's and outs of GUI dev
Slashdot Mirror
First, to those people who make the declaration "Don't be so paranoid, they can take your fingerprints from a door handle or a cup", I retort that you should then have no problem complying with a requirement from an employer/bank/whatever to take your DNA and keep it on file, because obviously they could just get it form a piece of hair or skin you leave around everywhere(welcome to Gattica!). That argument is a batch of crap. The taking of fingerprints is absolutely an invasion of privacy for those who are concerned about malice or undesired use/supeona of the information. And the people making the argument that a hash or encoding of the fingerprint data makes it impossible to use as evidence doesn't understand that law enforcement, etc. can fairly easily obtain that hash, then get a second scan from you and compare the hashes in order to positively identify you.
All that being said, most fingerprint scanners used for timeclocks, door locks, etc. don't store the data with sufficient precision to use it as credible evidence that the scan was you. This is part of why they are both non-trivial and pretty easy to fake. It's precisely that dual, semi-contradictory nature of fingerprint scanners that make them so useful as a biometric access device.
Of course, you have no idea if the biometric scanners used by this university have that kind of precision, so it's probably best for both you and the university if they simply modify the policy to state that the precision of data the devices gather do not and shall not be able to qualify as proof of identity of in a court of law.
Then you're clear. Your biometric data at that point has the same significance as an ID badge. Any use of that data as evidence must be corroborated.
It might not have been such a good idea to contact a paper or other news outlet unless the university refused to clarify their agreement.
I read your journal, and you're essentially talking about is NAT-PT, or a derivation therein. However, there are a couple of essential problems with those solutions:
1. Any protocol that imbeds IP address information into the upper-layer protocol will fail unless that mapping was previously created by the gateway.
2. The solution requires that all communication be through DNS. If the legacy device has an app which doesn't do DNS, how can it reach the endpoint? It can't without a manual mapping in the gateway. And what if the endpoint on the other side is also behind such a gateway? How do I figure out what IPv6 address to map it to?
Essentially, the IPv6 transition problem in it's current state was born because there are 2 primary issues when changing a lower-level protocol like IP:
1. How do endpoints contact each other?
2. How does the routing system get the packets to the endpoints?
IMHO These 2 problems are antithetical to each other. Making a backwards compatible solution to the endpoint problem was causing considerible trouble for those trying to route packets. You have to remember that there were ideas in place to imbed IPv4 addresses into IPv6 packets at a lower layer, but those ideas were canned because they required essentially importing the pre-existing IPv4 BGP routing tables into IPv6, and network operators wanted not only a clean routing solution, but one that was going to clean up the global prefix advertisement space.
So, being that IPv6 was largely created by network operators, a solution was chosen that would allow themselves to cleanly implement IPv6 (once you get the firmware updates, running a dual-stack backbone is actually really easy), and as the backbones could route the traffic, endpoints would deal with both existing.
From a deployment standpoint is basically breaks down to:
1. Do we want to design a protocol that is fast to deploy by backbone providers while continuing to maintain the stability of the existing network? Or,
2. Do we want to design a protocol that is easily interoperable between endpoints?
The designers picked option 1, believing that having a network up fast first and letting endpoints migrate slowly over to it was preferable to spending a ton more time getting a fully backwards-compatible network going so that people could switch really quick. Was that the right answer? I don't know. But we're living with option 1 today, let's see what endpoints can do about it.
And everyone who's a network admin knows that it is.
NAT has created a very lazy fix to the problem of network security and filtering. If you're behind NAT, you're not addressable unless UPnP or an explicit port forward does it for you, and that's extremely convenient.
In a situation where every single computer in a network is internet addressable (something not always desired in business, which is probably the reason IPv6 adoption is so slow), you have to implement a very strict firewall to block and filter unsolicited traffic to those machines. If you're NATing them, as long as your network is physically secure, you don't have a problem.
Although I agree with your points , your post has kind of fallen into the NAT trap itself.
When most people talk about security through NAT, it's never been about "addressability". It's been about reachability. NAT offered a convenient means of deploying a default security policy that says "people secured by me can get out, but noone can get in". There's no reason whatsoever that default firewall/router policy at both the corporate and consumer levels can do this with IPv6 very easily with a couple of canned policies. In fact, people wishing to seem "ultra-secure" can still use their firewall as a transparent proxy for their outbound connections, thus making all of their normal traffic still look to come from the router/firewall in question! With IPv6, firewall/router policy could stay exactly the same, with one key feature: everyone has a unique address.
In fact, people wishing to use uPNP to make dynamic firewall policy changes can still do so! Except that instead of using oddball port mappings, we can just route the same standard port over to the proper address. Done. There's nothing inherently wrong with uPNP for consumers wishing to maintain decent security without needing to know the details on how the security policy works, but with IPv6 it's now about real security, not getting around address scarcity.
This puts a lot less stress on network security than there should be in a business environment, and much less attention to what should or shouldn't be allowed through a local firewall, let alone a site firewall. I'll stop ranting, but the point is that NAT has created an artificial deficit of proper network security, and I fear that when IPv6 becomes ubiquitous, NAT will linger on as a replacement for real security. The skills required to secure a fully addressable network of machines simply aren't needed in the majority of current environments because making every host in a network internet addressable today is simply not an option.
As stated above, I agree that making every host internet reachable is not an option, but making every host internet addressable is. People can choose at that point to continue to use NAT/Transparent proxy services to mask the true source of requests, or they may not. At least it's a choice. As for me, I'll make every one of my hosts internet reachable with a decent security policy and take advantage of all of the benefits both in capability and in troubleshooting, thank you very much. :)
Sounds to me like you're the one living in hobby-land. Most machines don't need an externally accessible IP.
You're precisely correct. However, this problem has nothing to do with externally accessible IP addresses. It's about connectivity and global uniqueness.
Let's say that I run the network for small company A. We used 10. private addresses for our network layout. My company get's bought by slightly bigger company B, that also uses 10. address space for their network. In all likelyhood, we're going to have address conflicts. So, I have 3 choices for integrating the 2 networks:
1. Renumber company A
2. Renumber company B.
3. Employ some kind of odd-ball double-NAT solution that makes both companies appear to have unique addresses from the other's perspective.
You can very easily see that the lack of globally unique IP addresses in this situation has created a huge mess that takes a lot of time and money to resolve. If both company A and company B used globally-unique IP address (v4 or v6!), this would have never been a problem. And both companies can very easily hide internally accessible and externally accessible hosts via routing and firewall policy.
In the company I work for, we deploy a VPN solution to allow 2000+ data gateways to connect to us to deliver data. Because each data gateway resides in a unique network often addressed via non-routable IPv4 addresses, I can never trust that the VPN IP that I assign to this data gateway will not conflict with the local network on which this is deployed. So, I got globally unique addresses from ARIN to do it. Guess what? I don't even advertise that route over BGP to the public internet! I only route it via my local AS. When people gather statistics by IPv4 usage, consider that there are quite a few of us who need globally unique IP space, but will never route that out publicly.
IPv6 is designed to provide a global pool of unique addresses so large that everyone can have a globally unique addresses, regardless of how one wishes to use it. This means that networks become an issue of connectivity, not one of address management.
The IPv6 working group almost got caught up in NAT mania: They initially created a reserved IPv6 space called "site local", which was designed to be treated in the exact same way as the current private address space. On further consideration, though, the working group decided that any "private" addresses are just silly and create more headache than what they are worth. The concept of "site local" simply means "I'm not going to advertise this route publicly". If you don't want to advertise your network over the public Internet, then just don't. Take your globally unique space and have fun with it.
If your target audience is business customers, the simple answer here is none. And to rebut some of the other comments to the contrary, here's why: Businesses care about being legal It has been proven, time and time again, that it is cheaper for a business to have licenses for all software they use than the risk of not. Many of the major software companies recognize this, and also recognize that maintenance of a licensing system is both technically bad and bad for business. To back up this with evidence, look at software companies that don't put technical protection measures in place for business software: - Oracle - Computer Associates - Microsoft (This is a special case. Business customers get one key that always works, and that is only there because they sell the software in other markets). Now, here's what you do to help keep people honest and take care of your bottom line: - Make sure that your program installs and uninstalls itself correctly (I don't care what platforms you use), and make sure that your platform knows about it. There are lots of software solutions out there that let companies track what software is installed. If you make yourself visible to those solutions, then the IT department at that company will thank you, even if not vocally. - Occasionally look at how big some of your customers are, and periodically ask a couple of them to do software audits for you. You, of course, need to make sure that the right to ask for such an audit is in your EULA. - If a customer doesn't have enough licenses, ask them to settle up with you. Give them a discount, something to make settling up a relatively inexpensive operation. - If a customer refuses to settle up, hire a lawyer. Remember, at the end of the day, it is up to your customers to abide by your licensing terms. If they don't, they are breaking the law. That means little to a guy at home who isn't aware of the issues, but businesses of any meaningful size do care. Also, to go to some other comments noted here, make sure your software is the best. If businesses are stealing it, it's more than likely because there isn't enough value in the software for them to pay for it.
Yeah, I had a sinking feeling that Microsoft's problem with the EU helped to push them into a deal. However, I don't think that MS would do this for goodwill only.
One has to ask themselves, what does Microsoft have to gain by entering into such an agreement? And what does Novell have to gain? There are some possibilities here that aren't too farfetched: Virtual Servers - Microsoft missed the first boat on virtualization, and as far as I can see Microsoft Virtual Server doesn't have much in the way of market share. By entereting into an agreement with Novell, Microsoft is attempting to gain relevance in this space. This is actually a good move for Microsoft. At the same time, Novell could help with Windows running on top of Xen. They both have a common enemy here: EMC. Patents - Let's face it, any large company wants to avoid patent wars with another large company. It just saves tons of money. No real news here to speak of.
In reading a lot of these, I see an overall trend to do a lot of OS comparison. Myself, I have experience with a lot of OS's, and I grew up using DOS, then OS/2, then Windows, then Linux. When I look at this, and what has come to dominate the desktop, I find that there are many, MANY good things in the current Linux distros, and *nix in general. There is also a lot of work left to be done.
/usr/bin and /etc, but much more complicated when things are split up). Apt, both for RPM and for DEB, is really good at solving dependencies, but I think a bigger problem involves people actually MAKING packages. For some reason developers not familiar with package managers hate making packages. Things like InstallAnywhere are starting to create the same problem that Windoze has, which is uncontrolled application installation and apps that are hard or nearly impossible to uninstall. What we need here is a GUI toolkit for developers that allows for quick package management. Imagine an app that a developer could plug in some basic info for, and it would compile a pacakage for multiple pacakage managers, and for multiple distros, and even versions of distros in some instances! I could then just post the packages, and then let MIME take care of installing them for me. If we have pacakage management that get stupid easy, we get a similar system to OSX or Linspire, where software installation is a snap. And as a community, I think we can find a way. I believe that none of these third-party app problems will exist if there is a a good package development tool and the distro vendors make plugins that will ensure that the resulting package makes the right symlinks, etc... for that distro.
UNIX distros, with the exception of OSX and some of the BSD's in general, suffer from one major problem: Age. HP/UX, AIX, Solaris, etc... are so stuck to the old tools that new ones must be reinvented from the ground up in their minds. The Solaris machines I've dealt are pretty much GNU/Solaris machines, since a lot of the basic admin tools I've replaced with GNU equivalents (how hard was it ever to add a -h flag to Solaris du or dh! Sheesh!). CDE is old and antiquated ( reminds me of being on Warp 3 again). I think this stems from the commerical and niche nature of those UNIXes, and that's why I think Linux is trumping them.
That being said, here's some of the problems that Linux needs to overcome to be easier to use for everyday joes:
1. The great desktop war: KDE is great, GNOME is great. However, many people have problems dealing with which one to develop for, and a lot of times which one to use. I've found that I love KDE's look and feel, but what we really need is a SIMPLE common API for developement, that then can get morphed by the desktop to look like that desktop. I know some work is being done towards this, and when it matures, what you will find is a basic toolkit for GUI development, and the KDE and GNOME toolkits will be extensions to allow for more advanced GUI work.
2. The filesystem layout war: I don't know how many times people have bashed the *nix filesystem layout. I'll tell you right now it's far, far better than a lot of other OS's out there right now. Although some ideas like directory contained applications is cool and has some other nifty applications (such as easy chrooting), we have package managers now, and I'll tell you right now that I've fallen in love with them. RPM and deb (NOT APT!) are both good tools for checking versioning information and determining where stuff is. This makes the filesystem layout less about where binaries and config files are, and more about disk placement and security (e.g. maybe I want somebody to run an application but not change it's config: easy to do with
3. Just simply more automation. We have all of these nice scripting languages, wouldn't it be nice if we hand these quick scripts to Joe blow and have them work? If I could put a very basic GUI on top of my tool without needing to know the in's and outs of GUI dev