There are a fair number of typos both grammatical and spelling in this first edition. Its somewhat embarassing since some of them could have been caught with a spell checker.
In several cases, there were cases of "doubled" words in a sentence, like "test test" or "and and". Take a look at Appendix D, page 500, "euhemerizing"???
Overall, I enjoyed reading this book very much. Its a great reference and viewpoint on Unix. But I hope they correct these errors in the 2nd edition.
Actually, there is a similar program out there written in Python which is supposed to solve many of the problems with fetchmail and have additional features--getmail.
What would be nice to have is the ability to manage your rules (and sets of rules) at a higher level. I don't have in mind a GUI so much as the ability to manage access lists and groups easily.
For example, say you have a new service. This service uses a combination of TCP and UDP ports. You've got a minimum of 4 rules for outgoing traffic or 6 if you have stateful rules. It would be nice to have these sets of rules pre-defined and just say something like:
enable xyzService from hosta to hostb
VoIP or Real Audio services are good examples of multi-port protocols that require more than a few rules and become fairly complex when routing between multiple hosts.
Take a look at "Linux Security", 2nd Ed. by Bob Toxen. (See p. 462 and following for a critique of iptables vs. ipchains.) A lot of these points ring true from my use of iptables.
I agree with the "clear syntax" criticism vs. BSD. It would be nice to be able to have rules such as the following:
rule telnet from x to y
Instead, you have to get into the nitty gritty of TCP state flags, etc. When what you really want is to just be able to enable or disable services. Something similar to Cisco Pix config would be nice, although this could be written as a front end to iptables or ipchains, maybe.
This single huge machine has worked fairly well in the past. Now that ill-considered regulation has gone into effect, the problem is really how its being operated.
Trying to fix it by throwing a lot of tax payer money at it without taking into account these realities, would be, in effect, making the same mistake again.
SCO is not a very high standard of comparison for anyone. IMHO, deciding to rule out a group of people based on their (pick one) greedy, dishonet, misguided management is not "making a choice based on facts."
Sure, SCO employees have a choice--but it does not mean every one of them is as dispicable as Darl McBride. Personally, I would have to have a better reason to rule out someone from employment.
Slashdot Mirror
Ahhh....you read Showstopper, too.
There are a fair number of typos both grammatical and spelling in this first edition. Its somewhat embarassing since some of them could have been caught with a spell checker.
In several cases, there were cases of "doubled" words in a sentence, like "test test" or "and and". Take a look at Appendix D, page 500, "euhemerizing"???
Overall, I enjoyed reading this book very much. Its a great reference and viewpoint on Unix. But I hope they correct these errors in the 2nd edition.
Actually, there is a similar program out there written in Python which is supposed to solve many of the problems with fetchmail and have additional features--getmail.
0 /
http://www.qcc.ca/~charlesc/software/getmail-3.
The documentation is very good and there are many additional features.
What would be nice to have is the ability to manage your rules (and sets of rules) at a higher level. I don't have in mind a GUI so much as the ability to manage access lists and groups easily.
For example, say you have a new service. This service uses a combination of TCP and UDP ports. You've got a minimum of 4 rules for outgoing traffic or 6 if you have stateful rules. It would be nice to have these sets of rules pre-defined and just say something like:
enable xyzService from hosta to hostb
VoIP or Real Audio services are good examples of multi-port protocols that require more than a few rules and become fairly complex when routing between multiple hosts.
Take a look at "Linux Security", 2nd Ed. by Bob Toxen. (See p. 462 and following for a critique of iptables vs. ipchains.) A lot of these points ring true from my use of iptables.
I agree with the "clear syntax" criticism vs. BSD. It would be nice to be able to have rules such as the following:
rule telnet from x to y
Instead, you have to get into the nitty gritty of TCP state flags, etc. When what you really want is to just be able to enable or disable services. Something similar to Cisco Pix config would be nice, although this could be written as a front end to iptables or ipchains, maybe.
This single huge machine has worked fairly well in the past. Now that ill-considered regulation has gone into effect, the problem is really how its being operated.
Trying to fix it by throwing a lot of tax payer money at it without taking into account these realities, would be, in effect, making the same mistake again.
This statement fits the definition of FUD. The question is, who is behind it? It sounds remarkably Microsoft inspired!!
SCO is not a very high standard of comparison for anyone. IMHO, deciding to rule out a group of people based on their (pick one) greedy, dishonet, misguided management is not "making a choice based on facts."
Sure, SCO employees have a choice--but it does not mean every one of them is as dispicable as Darl McBride. Personally, I would have to have a better reason to rule out someone from employment.