Which is change management. When and how do you make needed changes to code? Like it or not, most developers have absolutely NO skills in actually managing a project of this sort, and have none of the related process/management skills. Some do, but most don't.
What most projects REALLY need is a small committee which handles policy changes. Do we want to refactor in the middle of a stable branch? What are the policies involved in releases, etc, and actually enforcing this sort of thing. Then you have a much larger group of people who do development and get pushback from this management committee when they don't play by the rules. The management committee should have the power to grant and revoke commit access to the source repositories. And really that access needs to be earned.
A third, related question is support lifecycle. How many older versions do you support?
If all of the above are well managed the developers can build better products, but you can still properly manage legacy users and general use of the software.
I agree. The only exception ought to be material directly relating to ongoing military operations and only then when Congress authorizes the military operation in a public and transparent way.
On the whole, this is probably a good thing. If the application is under your control, you can use whichever mode you want. If you're relying on somebody else's application, forcing it to use strict mode when it wasn't written for this environment could introduce subtle bugs. Now, if you were to argue that the _existence_ of these different modes of operation was an issue, then I'd probably agree. But given the existence of the modes (and that's unfortunately a necessity for backwards compatibility reasons) the ability of the application to change the mode to the one it expects is crucial.
It is a good thing in some, limited circumstances (where data integrity is not critical). Where data integrity is critical, this feature means you need to have careful policies of auditing ALL applications that hit the db to make sure they never, under any circumstance, turn off strict mode. This really requires a code audit.
You say I am describing 90% of all database applications. Fair enough, if you are looking at this from the application, rather than the information, perspective. For a single-app db it isn't bad and it scales reasonably well for simple queries. However, where it breaks down is for real enterprise information management. Say what you will, the criteria I mentioned don't apply to that environment.
One of the things we have worked hard to do for the LSMB project is to ensure other applications can safely access the database with appropriate data integrity constraints. Given that we came from the SQL-Ledger codebase, that has been a real headache, and will probably take us another year to make a reality. However, it is a powerful feature if your customer can write add-ins to the db app in a different language without having to worry as much about data integrity issues even where it is an accounting app.
Sometimes problems are remarkably difficult to address, especially in PL/(Pg)?sql environments.
Let me give you an example.
I was doing a rewrite of a bulk processing portion of an application and we were running into performance issues. Eventually we ended up talking to some REAL PostgreSQL experts, reviewed the affected functions, etc. The function had a few warning issues because we had to pass into it really large (5000x5) text arrays into the function.
At one point we all discovered that we could create array creation routines in PostgreSQL that performed really badly. So we thought maybe there was fundamental problem with the interface. So I asked on IRC and got an answer that this was not likely to be the issue with parsed text arrays and that I should look elsewhere. I created tests and we were able to demonstrate that we had all (including the experts) gone down the wrong path in troubleshooting the performance problem.
Eventually we were able to prove that the problem had to do with what was happening inside the array loop and address the issue there (turned out the issue was that it was causing cache misses and that we ended up with something which was entirely inefficient inside PL/PGSQL). Eventually we got it solved and cut the execution time from 45 minutes to 90 sec.
MySQL is a good db for single-app databases, where data integrity is not a tremendous issue or where you are deploying a separate MySQL instance on a different port. It is quite a bit worse than PostgreSQL for anything else.
From your description you are using MySQL for a single-app database where you run a dedicated instance of MySQL for your app. That is not the usage case I was describing, which is a central RDBMS serving out the same data to a myriad of different applications. If you are trying to go beyond ONE app for your data, you should look to PostgreSQL instead of MySQL.
If the client were to insist on handling the MySQL part, and screwed it up, it would cease to be my problem. Or rather, I would point at the instalation and tell them were they fucked up;
Ok, so your point is that this is fine as long as you install MySQL, make sure that Innodb, etc. is installed, etc. Fine. I don't want that responsibility.
About turning off strict-mode. If your applications are turning off strict-mode, then don't be supprised if you break data integrity. If your clients are writing apps that turn off strict-mode and mess up data integrity, that isn't really your problem, is it?
On the other hand, it isn't a support headache I want, since I might be hired to come in and fix it. I would rather be spending my paid development time elsewhere.
However, on that latter point, for inhouse apps where several apps share a db, you have a bigger issue, and that is that you really need to have someone auditing every app to ensure it DOESN'T turn off strict mode. Why bother with that issue? Why not use a db which ALWAYS performs these sorts of checks and where they can't be turned off?
I am not sure. If you write all sorts of things (which can the be run) on your home directory, these are temporary changes and do not last beyond a logout/re-login (if you deny execute access to nohup as well). Combined with sane idle-or-logout policies this can go a long way towards containing damage.
The key issues are 1) How long can a problem persist and 2) what can be accomplished through it. These are the key questions that I think are most important to ask. If you can minimize both of these as well as the impact on the user, that is great. Locking down.profile,.bashrc, etc. files can go a long ways towards limiting a bash script to its own environment and preventing it from spreading influence to other newer shell instances or beyond the next logout and login.
None of this prevents someone from doing something like:
* copy the offending virus code from an email
* open a bash shell
* type: cat | bash
* paste contents.....
Changing bash to check for executable file flags won't fix that either.... If you deny from a pipe, then that doesn't prevent the even simpler workflow:
* copy the offending virus code from an email
* open a bash shell
* paste contents...
Actually, though there are some things that SQL is very, very good at, but you are right that people often do the wrong sorts of things in it. My favorite approach is to use SQL stored procs to do named queries and then put processing the results of those queries into the middleware or thick client level.
It isn't quite that simple, but I suppose one of my earlier (and later abandoned) projects qualifies.
I set up HERMES (a CRM suite written in PHP4) originally on MySQL and eventually discovered that the lack of transactions, etc. were a serious problem (this was back in 1999). I tried to move it over to PostgreSQL and discovered that PostgreSQL was really hard to administer (this was back in 1999). I ended up doing all my prototyping on MySQL, then converting the schemas to PostgreSQL using mysql2pgsql.pl because this was the only way I could get the data protections I needed (back in 1999).
Now, both MySQL and PostgreSQL have come a long way in the nearly-a-decade since then. MySQL has added transactions (for some table types not installed by default), foreign keys (for some table types not installed by default), strict mode (which can be circumvented on the app level), and a the planner has gotten much better. On the other hand, nearly every one of my issues with PostgreSQL has been resolved too. 8.3 has some really impressive new features from a developer perspective, and 8.4 will have even more. I haven't had to do prototyping on MySQL since PostgreSQL 7.3 came out.
I still stand by the statement that "compared to PostgreSQL, MySQL is a toy," and I would expect the gap between them to continue to widen. However what was limited to light content management db's in 1999 (MySQL), has become better able to handle a wider range of single-app dbs. MySQL is still no reasonable choice for an enterprise-wide database management solution especially where critical data is involved, but there are an increasing number of special cases where it is an option, in particular when compared to Firebird's embedded version, SQLite, and stuff like Sybase's SQL Anywhere. Comparing MySQL to MS SQL though only comes out favorably for MySQL where MS SQL is quite a bit more than is needed. PostgreSQL OTOH can in most cases compare favorably to Oracle, DB2, and MS SQL.
So the other half of the statement needs to be "but there are some cool things you can do with a toy db...."
Actually I agree with you. One of the big wins on the LedgerSMB project was the approach of moving the all main queries into user defined functions (and then using them as named queries). One of the nice things about this approach is that dba-types (like myself) can address performance when it crops up rather than dealing with the ABOLUTELY horrendous approaches found in the SQL-Ledger codebase..... (Assembling queries as little bits of text strings, throwing them all together, and doing REALLY braindead things like simulating HAVING clauses in the middleware...)
For example, we had an issue where one large user (thousands of invoices per week) was having issues paying them without spending 8 hours waiting for the page to load. We were able to get this down to something like 10 minutes across 5 pages. No added hardware, just reviewing why the old code sucked, moving in new code, and then optimizing it when its performance sucked.
Well... I have been using Postgresql since back WHEN MySQL didn't do transactions.... I still don't trust MySQL's transactions or the new strict mode. At the same time, I have watched PostgreSQL do an absolutely terrific job of running horrendously written queries optimally. Here are two criticisms I have about using MySQL for real application work, especially when you are distributing that application (and thus have little control over how users set up their db's):
1) MySQL transactions are built into the table engines, and by default (last I checked, and meaning you don't install innodb, etc), the tables will not be transactional. This means that if you are building an inhouse app, you can trust it more than you can if you are distributing your software. In short, if you are distributing software you can't guarantee that it is running on a system with transactions without a great deal of headache........ The same goes for referential integrity enforcement.
2) Strict mode can be turned off by any application. This means that the more recent data integrity checks cannot be relied upon. This is an issue on both inhouse and distributed software because it adds quite a bit of overhead to the QA process internally, and can add support headaches in software for distribution.
MySQL is a good db for single-app databases, where data integrity is not a tremendous issue or where you are deploying a separate MySQL instance on a different port. It is quite a bit worse than PostgreSQL for anything else.
You don't have to give the user permission to write to.bashrc, etc. Generally speaking I would probably take the risk of letting most users write to it who specifically ask for it. But there is no reason to do this by default.
In fact, nearly every important aspect of the settings can be locked down this way.
Now, if you want to restrict the ability to run botnets, etc, you could lock down each machine's iptables rulesets properly, etc.
The point here is that you can arbitrarily limit the damage done to the machine in this way. This doesn't preclude exploiting security oversights to get privilege escellation, and although SELinux can help with that the fundamental math shows that you can't count on IT to be free of such exploits either.
Finally the only point of drawing comparisons to Windows is because that is what the original article suggested. You are right, it is a rediculously low bar, but if we are pointing out the flaws that Linux has in this regard without the comparison, it gives the wrong impression to someone who IS trying to lock down Linux systems at least to the point that they are locked down with Windows.
You have a point about Bash running non-executable shell scripts. However, in this case there are two things to consider:
1) Damage from such a script is likely to be quite contained (to the user's account) and 2) At least with Linux you have to take the gun out of the holster AND load it AND turn the safety off before you can shoot yourself in the foot. With Windows you can do this in one graceful motion....
A third point is that while it is quite possible to write a fork bomb/local file virus in bash, I am not entirely sure how you could write something much more dangerous without problematic permission issues as well.
Similarly, I have NEVER found Windows to be able to prevent me from running programs like Putty regardless of how locked down they are... You can get at least that far in Linux.....
However bottom line: In Linux and UNIX, Solutions come in re-arrangable pieces. At first this seems awkward for Windows admins who are used to PRODUCTS that solve their problems. However once you get used to it the power of the system becomes apparent: you can determine what you need and do it your way rather than MS's.
Those tools don't exist because Linux allows plenty of better ways of accomplishing the same things. It is hard to build a GPO replacement when you can do pretty much all the stuff faster and easier without it provided you spend some time actually DESIGNING your network first.....
I think the point is that to do this you have to stop thinking like a Windows admin. There are all sorts of things you can do to ensure consistent configs across an organization. For example, you could make all user shares AFS mounts, and mount them with a noexec option, lock down the box appropriately, add IDS software, and manage all config files with a nightly svn revert and svn up, followed by rebuilding the tripwire db.
When adding Kerberos, SSH, and the like, pretty much everything can be automated easily and without human interaction.
All sorts of stuff is quite possible, but it doesn't require a separate product or feature. It just requires a knowledge of the system.
However, the fact is that the solutions to these problems are just fundamentally different on Linux than they are on Windows.
You want an equivalent to AD GPO management? There isn't one and there probably will never be.
Why?
Because the UNIX solutions (which are the basis for the ideas behind the Linux solutions) are just different. They require a different way of thinking.
Instead of thinking about managing and locking down desktops using Windows tools, you need to start by evaluating what exactly you are trying to accomplish. From here, you need to investigate the following technologies:
1) Kerberos 2) OpenAFS 3) NFS 4) X11 5) SSH 6) Kerberized Telnet (though this is starting to die now that OpenSSH supports GSSAPI) 7) LDAP
With these sorts of technologies, you can actually control the desktops as tightly (or even more tightly) than you can on Windows. The solution and interface is quite different and it requires understanding the technology at a lower level, but it isn't that hard.
And if you can't figure it out, hire me to do the consulting!
And I know that I would not be where I am without the public domain.
The image for the cover of my book came from a digitized 17th century manuscript, courtesy of wikipedia, for example.
A great deal of my discussion did center around translations of rune poems I used with the translator's permission (in exchange for advertising his work). I looked at public domain versions but decided I didn't like them. (In the second edition, I will be doing my own translations, not for reasons of copyright but because I want to make some minor contributions to the area.)
My comments were mostly on the book store end. You are right that the costs are lower on long offset runs. However, for many books (including most of the ones I read) the runs are not particularly long. Also POD doesnt work well on color books and there are some other limitations of the process.
One of my hopes is that it might become feasible to resurrect the ENTIRE corpus of out of print books on a POD basis. There is no reason why I should have to pay $2000 for a used book just because it was printed on a short run primarily for libraries.....
Slashdot Mirror
Which is change management. When and how do you make needed changes to code? Like it or not, most developers have absolutely NO skills in actually managing a project of this sort, and have none of the related process/management skills. Some do, but most don't.
What most projects REALLY need is a small committee which handles policy changes. Do we want to refactor in the middle of a stable branch? What are the policies involved in releases, etc, and actually enforcing this sort of thing. Then you have a much larger group of people who do development and get pushback from this management committee when they don't play by the rules. The management committee should have the power to grant and revoke commit access to the source repositories. And really that access needs to be earned.
A third, related question is support lifecycle. How many older versions do you support?
If all of the above are well managed the developers can build better products, but you can still properly manage legacy users and general use of the software.
I agree. The only exception ought to be material directly relating to ongoing military operations and only then when Congress authorizes the military operation in a public and transparent way.
On the whole, this is probably a good thing. If the application is under your control, you can use whichever mode you want. If you're relying on somebody else's application, forcing it to use strict mode when it wasn't written for this environment could introduce subtle bugs. Now, if you were to argue that the _existence_ of these different modes of operation was an issue, then I'd probably agree. But given the existence of the modes (and that's unfortunately a necessity for backwards compatibility reasons) the ability of the application to change the mode to the one it expects is crucial.
It is a good thing in some, limited circumstances (where data integrity is not critical). Where data integrity is critical, this feature means you need to have careful policies of auditing ALL applications that hit the db to make sure they never, under any circumstance, turn off strict mode. This really requires a code audit.
You say I am describing 90% of all database applications. Fair enough, if you are looking at this from the application, rather than the information, perspective. For a single-app db it isn't bad and it scales reasonably well for simple queries. However, where it breaks down is for real enterprise information management. Say what you will, the criteria I mentioned don't apply to that environment.
One of the things we have worked hard to do for the LSMB project is to ensure other applications can safely access the database with appropriate data integrity constraints. Given that we came from the SQL-Ledger codebase, that has been a real headache, and will probably take us another year to make a reality. However, it is a powerful feature if your customer can write add-ins to the db app in a different language without having to worry as much about data integrity issues even where it is an accounting app.
"Wild Man" is a passable translation of "Orang Utan."
Do the hard-core keepers get offended because calling one an "Orang" implies it is human?
Just to note the expert that was consulted actually gave us the correct answer at first but then we all went down the wrong path. :-)
Sometimes problems are remarkably difficult to address, especially in PL/(Pg)?sql environments.
Let me give you an example.
I was doing a rewrite of a bulk processing portion of an application and we were running into performance issues. Eventually we ended up talking to some REAL PostgreSQL experts, reviewed the affected functions, etc. The function had a few warning issues because we had to pass into it really large (5000x5) text arrays into the function.
At one point we all discovered that we could create array creation routines in PostgreSQL that performed really badly. So we thought maybe there was fundamental problem with the interface. So I asked on IRC and got an answer that this was not likely to be the issue with parsed text arrays and that I should look elsewhere. I created tests and we were able to demonstrate that we had all (including the experts) gone down the wrong path in troubleshooting the performance problem.
Eventually we were able to prove that the problem had to do with what was happening inside the array loop and address the issue there (turned out the issue was that it was causing cache misses and that we ended up with something which was entirely inefficient inside PL/PGSQL). Eventually we got it solved and cut the execution time from 45 minutes to 90 sec.
Banyak orang orang disini.
MySQL is a good db for single-app databases, where data integrity is not a tremendous issue or where you are deploying a separate MySQL instance on a different port. It is quite a bit worse than PostgreSQL for anything else.
From your description you are using MySQL for a single-app database where you run a dedicated instance of MySQL for your app. That is not the usage case I was describing, which is a central RDBMS serving out the same data to a myriad of different applications. If you are trying to go beyond ONE app for your data, you should look to PostgreSQL instead of MySQL.
you don't say "orangs", as it offends some of the more hard-core keepers
That is really funny because "orang" is a Malay (and Indonesian) word for "person."
"Orang utan" literally means "forest person" (the languages put the adjective after the noun).
If the client were to insist on handling the MySQL part, and screwed it up, it would cease to be my problem. Or rather, I would point at the instalation and tell them were they fucked up;
Ok, so your point is that this is fine as long as you install MySQL, make sure that Innodb, etc. is installed, etc. Fine. I don't want that responsibility.
About turning off strict-mode. If your applications are turning off strict-mode, then don't be supprised if you break data integrity. If your clients are writing apps that turn off strict-mode and mess up data integrity, that isn't really your problem, is it?
On the other hand, it isn't a support headache I want, since I might be hired to come in and fix it. I would rather be spending my paid development time elsewhere.
However, on that latter point, for inhouse apps where several apps share a db, you have a bigger issue, and that is that you really need to have someone auditing every app to ensure it DOESN'T turn off strict mode. Why bother with that issue? Why not use a db which ALWAYS performs these sorts of checks and where they can't be turned off?
I am not sure. If you write all sorts of things (which can the be run) on your home directory, these are temporary changes and do not last beyond a logout/re-login (if you deny execute access to nohup as well). Combined with sane idle-or-logout policies this can go a long way towards containing damage.
The key issues are 1) How long can a problem persist and 2) what can be accomplished through it. These are the key questions that I think are most important to ask. If you can minimize both of these as well as the impact on the user, that is great. Locking down .profile, .bashrc, etc. files can go a long ways towards limiting a bash script to its own environment and preventing it from spreading influence to other newer shell instances or beyond the next logout and login.
None of this prevents someone from doing something like:
* copy the offending virus code from an email
* open a bash shell
* type: cat | bash
* paste contents.....
Changing bash to check for executable file flags won't fix that either.... If you deny from a pipe, then that doesn't prevent the even simpler workflow:
* copy the offending virus code from an email
* open a bash shell
* paste contents...
The key issue then becomes acceptable risk.
see http://www.sqlonrails.org/ for why you are wrong. SOR is a great app framework!
Actually, though there are some things that SQL is very, very good at, but you are right that people often do the wrong sorts of things in it. My favorite approach is to use SQL stored procs to do named queries and then put processing the results of those queries into the middleware or thick client level.
It isn't quite that simple, but I suppose one of my earlier (and later abandoned) projects qualifies.
I set up HERMES (a CRM suite written in PHP4) originally on MySQL and eventually discovered that the lack of transactions, etc. were a serious problem (this was back in 1999). I tried to move it over to PostgreSQL and discovered that PostgreSQL was really hard to administer (this was back in 1999). I ended up doing all my prototyping on MySQL, then converting the schemas to PostgreSQL using mysql2pgsql.pl because this was the only way I could get the data protections I needed (back in 1999).
Now, both MySQL and PostgreSQL have come a long way in the nearly-a-decade since then. MySQL has added transactions (for some table types not installed by default), foreign keys (for some table types not installed by default), strict mode (which can be circumvented on the app level), and a the planner has gotten much better. On the other hand, nearly every one of my issues with PostgreSQL has been resolved too. 8.3 has some really impressive new features from a developer perspective, and 8.4 will have even more. I haven't had to do prototyping on MySQL since PostgreSQL 7.3 came out.
I still stand by the statement that "compared to PostgreSQL, MySQL is a toy," and I would expect the gap between them to continue to widen. However what was limited to light content management db's in 1999 (MySQL), has become better able to handle a wider range of single-app dbs. MySQL is still no reasonable choice for an enterprise-wide database management solution especially where critical data is involved, but there are an increasing number of special cases where it is an option, in particular when compared to Firebird's embedded version, SQLite, and stuff like Sybase's SQL Anywhere. Comparing MySQL to MS SQL though only comes out favorably for MySQL where MS SQL is quite a bit more than is needed. PostgreSQL OTOH can in most cases compare favorably to Oracle, DB2, and MS SQL.
So the other half of the statement needs to be "but there are some cool things you can do with a toy db...."
You throw transistors at your developers? ;-)
Actually I agree with you. One of the big wins on the LedgerSMB project was the approach of moving the all main queries into user defined functions (and then using them as named queries). One of the nice things about this approach is that dba-types (like myself) can address performance when it crops up rather than dealing with the ABOLUTELY horrendous approaches found in the SQL-Ledger codebase..... (Assembling queries as little bits of text strings, throwing them all together, and doing REALLY braindead things like simulating HAVING clauses in the middleware...)
For example, we had an issue where one large user (thousands of invoices per week) was having issues paying them without spending 8 hours waiting for the page to load. We were able to get this down to something like 10 minutes across 5 pages. No added hardware, just reviewing why the old code sucked, moving in new code, and then optimizing it when its performance sucked.
I don't know. Are the ideas worth testing on PostgreSQL? I am willing to bet they are.
Well... I have been using Postgresql since back WHEN MySQL didn't do transactions.... I still don't trust MySQL's transactions or the new strict mode. At the same time, I have watched PostgreSQL do an absolutely terrific job of running horrendously written queries optimally. Here are two criticisms I have about using MySQL for real application work, especially when you are distributing that application (and thus have little control over how users set up their db's):
1) MySQL transactions are built into the table engines, and by default (last I checked, and meaning you don't install innodb, etc), the tables will not be transactional. This means that if you are building an inhouse app, you can trust it more than you can if you are distributing your software. In short, if you are distributing software you can't guarantee that it is running on a system with transactions without a great deal of headache........ The same goes for referential integrity enforcement.
2) Strict mode can be turned off by any application. This means that the more recent data integrity checks cannot be relied upon. This is an issue on both inhouse and distributed software because it adds quite a bit of overhead to the QA process internally, and can add support headaches in software for distribution.
MySQL is a good db for single-app databases, where data integrity is not a tremendous issue or where you are deploying a separate MySQL instance on a different port. It is quite a bit worse than PostgreSQL for anything else.
You don't have to give the user permission to write to .bashrc, etc. Generally speaking I would probably take the risk of letting most users write to it who specifically ask for it. But there is no reason to do this by default.
In fact, nearly every important aspect of the settings can be locked down this way.
Now, if you want to restrict the ability to run botnets, etc, you could lock down each machine's iptables rulesets properly, etc.
The point here is that you can arbitrarily limit the damage done to the machine in this way. This doesn't preclude exploiting security oversights to get privilege escellation, and although SELinux can help with that the fundamental math shows that you can't count on IT to be free of such exploits either.
Finally the only point of drawing comparisons to Windows is because that is what the original article suggested. You are right, it is a rediculously low bar, but if we are pointing out the flaws that Linux has in this regard without the comparison, it gives the wrong impression to someone who IS trying to lock down Linux systems at least to the point that they are locked down with Windows.
You have a point about Bash running non-executable shell scripts. However, in this case there are two things to consider:
1) Damage from such a script is likely to be quite contained (to the user's account) and
2) At least with Linux you have to take the gun out of the holster AND load it AND turn the safety off before you can shoot yourself in the foot. With Windows you can do this in one graceful motion....
A third point is that while it is quite possible to write a fork bomb/local file virus in bash, I am not entirely sure how you could write something much more dangerous without problematic permission issues as well.
Similarly, I have NEVER found Windows to be able to prevent me from running programs like Putty regardless of how locked down they are... You can get at least that far in Linux.....
SELinux could easily be a piece of a solution.
However bottom line: In Linux and UNIX, Solutions come in re-arrangable pieces. At first this seems awkward for Windows admins who are used to PRODUCTS that solve their problems. However once you get used to it the power of the system becomes apparent: you can determine what you need and do it your way rather than MS's.
Those tools don't exist because Linux allows plenty of better ways of accomplishing the same things. It is hard to build a GPO replacement when you can do pretty much all the stuff faster and easier without it provided you spend some time actually DESIGNING your network first.....
I think the point is that to do this you have to stop thinking like a Windows admin. There are all sorts of things you can do to ensure consistent configs across an organization. For example, you could make all user shares AFS mounts, and mount them with a noexec option, lock down the box appropriately, add IDS software, and manage all config files with a nightly svn revert and svn up, followed by rebuilding the tripwire db.
When adding Kerberos, SSH, and the like, pretty much everything can be automated easily and without human interaction.
All sorts of stuff is quite possible, but it doesn't require a separate product or feature. It just requires a knowledge of the system.
However, the fact is that the solutions to these problems are just fundamentally different on Linux than they are on Windows.
You want an equivalent to AD GPO management? There isn't one and there probably will never be.
Why?
Because the UNIX solutions (which are the basis for the ideas behind the Linux solutions) are just different. They require a different way of thinking.
Instead of thinking about managing and locking down desktops using Windows tools, you need to start by evaluating what exactly you are trying to accomplish. From here, you need to investigate the following technologies:
1) Kerberos
2) OpenAFS
3) NFS
4) X11
5) SSH
6) Kerberized Telnet (though this is starting to die now that OpenSSH supports GSSAPI)
7) LDAP
With these sorts of technologies, you can actually control the desktops as tightly (or even more tightly) than you can on Windows. The solution and interface is quite different and it requires understanding the technology at a lower level, but it isn't that hard.
And if you can't figure it out, hire me to do the consulting!
Yeah, well there are the share of Welsh roadsign issues.
"No lorries this way" in English, "I am sorry but I am out of the office at the moment, please send text to be translated" in Welsh.....
And I know that I would not be where I am without the public domain.
The image for the cover of my book came from a digitized 17th century manuscript, courtesy of wikipedia, for example.
A great deal of my discussion did center around translations of rune poems I used with the translator's permission (in exchange for advertising his work). I looked at public domain versions but decided I didn't like them. (In the second edition, I will be doing my own translations, not for reasons of copyright but because I want to make some minor contributions to the area.)
My comments were mostly on the book store end. You are right that the costs are lower on long offset runs. However, for many books (including most of the ones I read) the runs are not particularly long. Also POD doesnt work well on color books and there are some other limitations of the process.
One of my hopes is that it might become feasible to resurrect the ENTIRE corpus of out of print books on a POD basis. There is no reason why I should have to pay $2000 for a used book just because it was printed on a short run primarily for libraries.....