The book takes 6 chapters to get to mod_perl handlers. In that span, Stein and Eachern have already:
1) shown you how to fit the pieces of Apache together, 2) written sample code for 3 of the 7 standard phases of the Apache request cycle, and 3) actually given you some insight into how to extend Apache for other purposes.
Lincoln used to write CGI scripts. He wrote CGI.pm, in fact. Don't you think the fact that he wrote his most notable programming book on mod_perl is a telltale sign of what I find wrong with this book AND the review?
And that witty riposte -- my god! I've never in my entire life heard that one before! Quick, somebody get Jerry Seinfeld's agent on the phone.
I can be 'arsed' to read an article and (gasp!) form an opinion about it based on my own experience... 7 solid years of it, in this field. And looking back (with the current toolset) I would not want to see ANYONE start off re-inventing the wheel with Perl CGI scripts. Hell, if you're going to re-invent the wheel, at least make it round. CGI is, was, and will always be a kludge. Apache::Registry is a kludge to shoehorn CGI kludgers into the Better Way. Personally, I'd rather see people start out with PHP, because even if their code looks like trash, at least I can write a parser to fix it.
In the long run, though, you'll find that Apache::Registry is not the Better Way to do it... either.pm modules with tiny bits of front-end code for the handlers, or (IMHO) PHP with the same approach (class libraries or.so extensions in C). I chose PHP after a protracted battle and some development in both. PHP is slower than mod_perl for execution, but faster than either for development (assuming you push any nasty complex code into either C, classes, or classes calling C). Even with Inline.pm, and even after 4 years of writing Perl for web apps, I've finally sworn I'll never write another line of interface code in Perl. Backend? Sure. And reading the Eagle Book is a great way to get comfortable with how Apache actually works. But I've had enough of Perl on the front end, and if you look around, so have most other people.
Not a flame, just an observation. Apache::Registry is not a panacea.
This is a little late in the game for a book that discusses ways to fork off a separate process for each hit on your dynamic pages. I'm sure the authors are studs and all, but if you're programming web applications in Perl, how about using mod_perl, and if you're going to do that, why not bite the bullet and buy Lincoln Stein and Doug Eachern's book from O'Reilly? It is a classic.
Speaking of classics, the old "Writing Web Clients with Perl" is being superseded this month by Sean Burke's "Perl and LWP". Now speaking of Perl studs, they don't get much studlier than Sean, and LWP is (IMHO) the Killer App for Perl programmers. Another fine O'Reilly title (too bad "fine O'Reilly title" is not redundant anymore).
Also from O'Reilly (yawn) is Rasmus Lerdorf's "Programming PHP". I was *very* pleasantly surprised by his book, it is MUCH better than it has any right to be, discussing everything from PEAR DB abstraction classes to speeding up your site with a Squid reverse cache and profiling.
Anyways, that's just my shelf's worth. I use Perl and PHP every day (or at least every day I wear my programmer hat) to get things done fast. I know other people prefer Python and Ruby, hey, more power to them. But I figured I would point out some Fine O'Reilly Titles (note, once again, that phrase is now said more like "Honest Senator" rather than "Stupid Microsoft Security Hole") which have made me some money lately.
Yes, but even a master carpenter can't build a house out of rotten wood.
This has been my mantra over the past couple of weeks as I've been forced to try to get low level hardware and software working with Windows.
Fair enough. I've been in that exact situation with Windoze before (trapped into it, in fact) and you just have to trudge through as best you can. I hate Microsoft server OSes (and attempts to use their client OSes, or more pointedly, crippled versions of the same thing they sell as server OSes, to do anything reliably).
The upside to this (IMHO again) is that most shops which run everything on Windows are such amateurs that they won't notice downtime until it is on the order of "one nine" (eg. vs. "five nines"):-)
Doing anything interesting with Windows and hardware that needs to run reliably... well, best wishes, my heart goes out to you.;-)
If it helps you debug the whole get-up (eg. if you need it to run in lock-step across multiple sites) there is one piece of good news -- NTP runs on Windows and is documented (both in an O'Reilly book and elsewhere on the Web). Just something that came to mind after an earlier poster brought up NTP. Good luck.
You ARE off base. Not every line of source code in (for example) the ports and packages can be audited by the development team, let alone all by Theo himself. The OpenBSD developers do a terrific job, and I trust it above any other OSes for my "hardened" public servers, but it simply is not possible for the degree of hardening and auditing you describe to be done by such a small group. The auditing is done to the kernel, the base utilities, and other aspects of the default install. Outside of that, you're on your own.
Furthermore, several of the services that run by default on a raw install of OpenBSD have been shown over time to have local root exploits possible. Not remote root, mind you, and not without a swift and comprehensive patch being released, but the moral is, No One Is Perfect.
That said, I have never had a compromise of any sort on my OpenBSD systems. I buy each and every release on CD direct from them to support the project, and have donated a little bit, too. If anyone who just runs Linux says "so what, it doesn't affect us" I request that you look at what version of SSH you're running. OpenSSH? Hmm, guess which dev team wrote that? Yeah, that's right. *BSD will be dead around the same time we see the paperless office (and the paperless restroom, and flying pigs, and...). OpenBSD is good stuff when you just can't take chances!
I did not mean to imply that SELinux actually offers a greater level of security than the alternatives, nor to imply that it was blessed by the NSA (or for use in NSA projects, for that matter).
Rather, my experience has been that other three-letter agencies find it helpful in the decision-making process if a solution based on Linux also has the imprimatur of the NSA (eg., "we can do this on NSA SELinux if it suits you better") so that it need not be seen as a rogue deployment of something outside the norm.
I am sorry if anyone got the idea that SELinux is Orange Book or NSA approved or in any other way superior to a properly-implemented kernel MAC implementation. What I was commenting on is the "aura", if you will, of offering a product that is Linux-based, but NSA-Linux-based. It makes life easier. I had trouble the first time I explained this to my boss, so clearly I need to work on my presentation of the issues some more;-).
It is complicated as hell because the whole issue of clock synchronization across a medium with varying latencies (differing both along the axes of time and location, though without any linear dependence across those two axes) is horrifically complex.
Still, a working NTP infrastructure is a requirement not just for NDS, but (IMHO) for ANY scalable deployment of service that is meant to be reliable. How can you get anything interesting from your logfiles (on a correlation-across-the-site basis) without a standardized meaning for the timestamp?
Complicated, yes, but also valuable. I have had the misfortune of trying to read the RFC. I even read the source for ntpd and xntpd (v4). The complexity arises (and damned if this isn't going to sound familiar) as a result of multiple people in multiple locations trying to coordinate their metrics for timekeeping. LDAP and NIS complexity also arises from social interactions (upkeep) and scaling (emergent behavior of a system). NTP is a great tool for minimizing the chaos created by bugs in authentication schemes like LDAP, btw.
Aside: If you want to get really sick, try running a Coda or AFS deployment (with IPSec or SSH tunnels to link nodes) across multiple timezones. Woo Hah!
All of my servers run NTP, from the routers, which in turn pull from tick and tock at the Naval Academy (or NRC, can't remember offhand which).
Most federal agencies seem to evaluate Windows against proprietary Unix solutions and (duh) find that Windows is cheaper. If they *really* care about security they almost always have their own solution (often in hardware) that you will be asked to code to / talk with / work in conjunction with. Short of that, offering to use NSA SELinux (because of the NSA's "approved" cachet) really seems to open a lot of doors for Linux.
En Garde may be better, for all I know. But I'll be using SELinux for gov't clients wanting high security, and OpenBSD for my need-to-be-hardened services, because I know they are excellent tools for those applications. (sorry folks...)
The above are just my experiences. For all I know it could be a vast conspiracy to provide disinformation:-). But, the odds are against it.
and I am a professional sysadmin. I get paid a lot to do my job and I don't feel like there is anything mystical about it (that sort of nonsense is for university admins that have to deal with incompetent bosses -- more power to 'em, but I don't). What I feel adds value is not mere understanding of the protocols (relatively easy) but rather, the ability to choose the correct tool (protocol, framing, hardware, software) for the job, and make it work so that the rest of the people involved can do their jobs without noticing (or if they do, saying, "hey, that's really cool and easier than before!"). Needless to say I do a good deal of development to make this happen, and again, that is more challenging than administering boxes (IF you start with a sane rollout and upkeep process -- yes, RPM/apt/pkg_add is your friend; yes, CVS/CVSup/Rsync is your friend; no, ad-hoc changes are not the Better Way to proceed).
When you rattle off NNTP and crap like NIS/LDAP as if they were equivalent in complexity to full BGP4/MBGP routing, I think you belie a superficial understanding of the situation. Even something as nastily complicated as BGP route maps is not nearly as challenging as dealing with people, professionally and personally, in a fast-paced environment that values results over process or the latest fad technologies. In that respect I do not believe it is significantly harder to earn one's keep as a sysadmin than to do so as a VP Sales or a Comptroller. It's just a totally different set of technical skills used to do the job.
I don't doubt that you meant well, but really, choosing the right tool for the job (and then using it well) is not so difficult in most cases. 'Tis a poor craftsman who blames his tools!
Probably not the result you wanted, definitely not a useful result, and points out why you need to understand syntax (operator precedence) as well as structure...
I feel like Paul Graham's "ANSI Common Lisp" is more fun to work through (and makes my brain hurt somewhat less) than SICP. SICP is a really stiff book -- using that text for a class is a sure way to weed most people out. Graham's book, while very very intelligent and deep, is also a lot easier to grasp in many respects. Not a bad choice for 'SICP Lite' although that doesn't give it enough credit for what it teaches you about programming in the real world (vs. the computer-linguistics and mental gymnastics that SICP teaches you).
(Read the articles on Graham's site. They're friggin' amazing distillations of experience. If you've been programming (successfully) for long enough, you'll not only be pleasantly surprised, but will find yourself nodding in agreement whilst learning about new topics. Anyways, the book is an implementation of much of what he writes about, into his 'Mother Tongue' of Common Lisp. Hell, this is one of the few good writers who can correctly answer the question:
"If you're so damn smart, why aren't you rich?"
The answer, for anyone whose opinions you'd want to trust, is "I am", and it's BECAUSE of his opinions.:-))
kind of like 'SICP for nonprogrammers' (\me ducks).
I liked the chapter differentiating generative recursion from structural recursion. That's a really insightful distinction in terms of the mechanics of grasping a problem and a good solution for the problem.
Definitely worth a read, although I think SICP is the cleverest (most intellectually satisfying) exposition of these little gems ever written.
I am reading (and doing) Paul Graham's 'ANSI Common Lisp' book for amusement and it's really sharpened my thinking. Macros are a great example of meta-generative-recursion, if you can call it that. Whatever you call it, it's raw power.
You conveniently omitted the one outlier that the pattern converges upon. Anyone who understands quicksort could tell you that;-)
1 + 99 = 100 2 + 98 = 100 ... 50 + 0 = 50
sum (1..100, step=1) { x } = 5050 because of that.
Come to think of it, patterns like this (eg. all the multiples of 9 x a single digit N have the first digit as N-1 and the second as the difference 9-(N-1)) are probably why I hated calculus and used Taylor series in place of integrals every chance I got in college.
Integration still seems like voodoo to me. Sequences, now there's something *REAL*.
(even in job choices -- computational chemistry, database work, etc. -- I ended up with discrete rather than continuous bases for solving most problems... odd)
and I've implemented reasonably correct versions of almost all the others, so I am not just 'guessing' but offering observations from someone who's built several systems like yours.
You want accounts and you want them managed separately from billing. Physical security is what should realistically protect the private payment and identification information that relates to those accounts (eg. the substance to their metadata) so that day-to-day manipulations of orders are separate from month-to-month billing updates.
You simply must keep private info private and enforce it via legal and policy measures. No amount of technology will easily prevent misuse of your data. You could, however, experiment with CryptFS or StegFS to make it much more difficult for a physical security breach (eg. stealing the machine) to result in information leakage.
When I went back and reviewed the submitter's question I decided that I had focused on the wrong aspect of his question. One-way encryption (outside-to-inside) is important, and it can be keyed to the same database as customer account identifiers, without divulging useful information on a public interface. However, the primary measures for his company to take are still going to be policy (dissociating private customer data from public/unimportant customer identification data) and legal (physical security, pressing charges when anyone tries to circumvent).
Again, every measure I'm discussing above is something I've had to deal with in my job, and I am merely offering opinions as to what has worked best for us. I design my systems (at least at this point in my career) so that, for the most part, someone could steal them outright without greatly affecting our day-to-day operations.
PGP-encrypted SMTP relayed on an internal VLAN to a machine with the 'recipient' key, decrypt ONLY on the destination machine, encrypt ONLY on the Internet-facing machine. Perl classes for this exist and implementing it is therefore a question of writing the appropriate 'glue' for your site.
Internal access and usage is a policy issue. There is no way to engineer a usable solution whereby a user cannot write down a credit card number and expiry date and begin using it to buy stuff short of policy, enforcement, and legal action. You'll come up with some real Rube Goldberg schemes if you try, but fundamentally, if you must have human contact with the billing authorizations, you have a policy issue, not something you can ironclad by technology.
You will simply have to ensure that only trusted staff (eg. have a vested interest in the company's success) have enough access to do any damage. Technological solutions to social problems are a very poor fit and a very large time sink.
Sorry. We segregate authorization and billing where I work so that I don't have to jump through these hoops anymore. Small-order authentication is farmed out (and with it, the liability) so that our major customers are charge accounts with whom we deal personally in case of a problem.
My entire staff uses PuTTY and I've fixed site problems from halfway around the globe (in Cambodia and Laos, no less) using it. It is a godsend like none other. Even on machines where I cannot save items to local disk, the 'run from current location' feature on Windows lets it work fine, and then I leapfrog in with an RSA key...
The forcible-keying and cipher selection options in 0.52 play nicely with OpenSSH 3.0+, which in my opinion elevates PuTTY above ttssh. The only competition is the Mac version, 'Nifty Telnet-SSH'.
Of course, nothing is as convenient as my ssh-agent process that spawns my X sessions at home. Since all my machines are RSA-keyed, and most are ONLY RSA-key accessible, access is transparent for me and damn near impossible for Bad Guys. (I allow an internally-usable backdoor for staff at the office without using RSA keys, but only on a couple machines necessary for their work... it's funny that now, if I screw up an OpenBSD upgrade, I get complaints about mutt not working. Everyone assumes Outlook is a POS, but they know I'm responsible if they can't use Mutt from a PuTTY session at some Kinko's or DoD machine!)
Yes. And it is 12 characters long. But the idea is not to let people get a hold of your private key in the first place. Furthermore, brute forcing an RSA key is slower than brute forcing a weak login password.
would accept a paycheck while senior management is still pulling down. It's one thing if you really are a small company (mine is) and you agree to put off cashing expense checks, etc. but a pay cut? That just means the company doesn't think you're worth much. And if you accept it, that means you agree. Pretty pathetic, unless it's true.
My boss draws a salary of $0. I pull down considerably more than that. We have had some arguments through the lean times, but in the end, he's discovered the fundamental truth that I charge people what I am worth, and if you've got a solid business plan, I *will* make it happen for you.
If you don't, I'll be hitting the road.
Pay cuts are for chumps. Next time, ask for what you're worth, no more, no less, and stand firm.
The quest to win the lottery is a poor business model, and not the way to support multiple people. Most actresses start out (and end up!) as waitresses, most football players get a real job after they fail to make it to the NFL. And most dot-commers got a wake-up call when the money ran out.
Slashdot Mirror
The book takes 6 chapters to get to mod_perl handlers. In that span, Stein and Eachern have already:
1) shown you how to fit the pieces of Apache together,
2) written sample code for 3 of the 7 standard phases of the Apache request cycle, and
3) actually given you some insight into how to extend Apache for other purposes.
Lincoln used to write CGI scripts. He wrote CGI.pm, in fact. Don't you think the fact that he wrote his most notable programming book on mod_perl is a telltale sign of what I find wrong with this book AND the review?
And that witty riposte -- my god! I've never in my entire life heard that one before! Quick, somebody get Jerry Seinfeld's agent on the phone.
I can be 'arsed' to read an article and (gasp!) form an opinion about it based on my own experience... 7 solid years of it, in this field. And looking back (with the current toolset) I would not want to see ANYONE start off re-inventing the wheel with Perl CGI scripts. Hell, if you're going to re-invent the wheel, at least make it round. CGI is, was, and will always be a kludge. Apache::Registry is a kludge to shoehorn CGI kludgers into the Better Way. Personally, I'd rather see people start out with PHP, because even if their code looks like trash, at least I can write a parser to fix it.
End of rant.
In the long run, though, you'll find that Apache::Registry is not the Better Way to do it... either .pm modules with tiny bits of front-end code for the handlers, or (IMHO) PHP with the same approach (class libraries or .so extensions in C). I chose PHP after a protracted battle and some development in both. PHP is slower than mod_perl for execution, but faster than either for development (assuming you push any nasty complex code into either C, classes, or classes calling C). Even with Inline.pm, and even after 4 years of writing Perl for web apps, I've finally sworn I'll never write another line of interface code in Perl. Backend? Sure. And reading the Eagle Book is a great way to get comfortable with how Apache actually works. But I've had enough of Perl on the front end, and if you look around, so have most other people.
Not a flame, just an observation. Apache::Registry is not a panacea.
This is a little late in the game for a book that discusses ways to fork off a separate process for each hit on your dynamic pages. I'm sure the authors are studs and all, but if you're programming web applications in Perl, how about using mod_perl, and if you're going to do that, why not bite the bullet and buy Lincoln Stein and Doug Eachern's book from O'Reilly? It is a classic.
Speaking of classics, the old "Writing Web Clients with Perl" is being superseded this month by Sean Burke's "Perl and LWP". Now speaking of Perl studs, they don't get much studlier than Sean, and LWP is (IMHO) the Killer App for Perl programmers. Another fine O'Reilly title (too bad "fine O'Reilly title" is not redundant anymore).
Also from O'Reilly (yawn) is Rasmus Lerdorf's "Programming PHP". I was *very* pleasantly surprised by his book, it is MUCH better than it has any right to be, discussing everything from PEAR DB abstraction classes to speeding up your site with a Squid reverse cache and profiling.
Anyways, that's just my shelf's worth. I use Perl and PHP every day (or at least every day I wear my programmer hat) to get things done fast. I know other people prefer Python and Ruby, hey, more power to them. But I figured I would point out some Fine O'Reilly Titles (note, once again, that phrase is now said more like "Honest Senator" rather than "Stupid Microsoft Security Hole") which have made me some money lately.
YMMV...
Yes, but even a master carpenter can't build a house out of rotten wood.
This has been my mantra over the past couple of weeks as I've been forced to try to get low level hardware and software working with Windows.
Fair enough. I've been in that exact situation with Windoze before (trapped into it, in fact) and you just have to trudge through as best you can. I hate Microsoft server OSes (and attempts to use their client OSes, or more pointedly, crippled versions of the same thing they sell as server OSes, to do anything reliably).
The upside to this (IMHO again) is that most shops which run everything on Windows are such amateurs that they won't notice downtime until it is on the order of "one nine" (eg. vs. "five nines")
Doing anything interesting with Windows and hardware that needs to run reliably... well, best wishes, my heart goes out to you.
If it helps you debug the whole get-up (eg. if you need it to run in lock-step across multiple sites) there is one piece of good news -- NTP runs on Windows and is documented (both in an O'Reilly book and elsewhere on the Web). Just something that came to mind after an earlier poster brought up NTP. Good luck.
You ARE off base. Not every line of source code in (for example) the ports and packages can be audited by the development team, let alone all by Theo himself. The OpenBSD developers do a terrific job, and I trust it above any other OSes for my "hardened" public servers, but it simply is not possible for the degree of hardening and auditing you describe to be done by such a small group. The auditing is done to the kernel, the base utilities, and other aspects of the default install. Outside of that, you're on your own.
Furthermore, several of the services that run by default on a raw install of OpenBSD have been shown over time to have local root exploits possible. Not remote root, mind you, and not without a swift and comprehensive patch being released, but the moral is, No One Is Perfect.
That said, I have never had a compromise of any sort on my OpenBSD systems. I buy each and every release on CD direct from them to support the project, and have donated a little bit, too. If anyone who just runs Linux says "so what, it doesn't affect us" I request that you look at what version of SSH you're running. OpenSSH? Hmm, guess which dev team wrote that? Yeah, that's right. *BSD will be dead around the same time we see the paperless office (and the paperless restroom, and flying pigs, and...). OpenBSD is good stuff when you just can't take chances!
I did not mean to imply that SELinux actually offers a greater level of security than the alternatives, nor to imply that it was blessed by the NSA (or for use in NSA projects, for that matter).
;-).
Rather, my experience has been that other three-letter agencies find it helpful in the decision-making process if a solution based on Linux also has the imprimatur of the NSA (eg., "we can do this on NSA SELinux if it suits you better") so that it need not be seen as a rogue deployment of something outside the norm.
I am sorry if anyone got the idea that SELinux is Orange Book or NSA approved or in any other way superior to a properly-implemented kernel MAC implementation. What I was commenting on is the "aura", if you will, of offering a product that is Linux-based, but NSA-Linux-based. It makes life easier. I had trouble the first time I explained this to my boss, so clearly I need to work on my presentation of the issues some more
YMMV...
It is complicated as hell because the whole issue of clock synchronization across a medium with varying latencies (differing both along the axes of time and location, though without any linear dependence across those two axes) is horrifically complex.
Still, a working NTP infrastructure is a requirement not just for NDS, but (IMHO) for ANY scalable deployment of service that is meant to be reliable. How can you get anything interesting from your logfiles (on a correlation-across-the-site basis) without a standardized meaning for the timestamp?
Complicated, yes, but also valuable. I have had the misfortune of trying to read the RFC. I even read the source for ntpd and xntpd (v4). The complexity arises (and damned if this isn't going to sound familiar) as a result of multiple people in multiple locations trying to coordinate their metrics for timekeeping. LDAP and NIS complexity also arises from social interactions (upkeep) and scaling (emergent behavior of a system). NTP is a great tool for minimizing the chaos created by bugs in authentication schemes like LDAP, btw.
Aside:
If you want to get really sick, try running a Coda or AFS deployment (with IPSec or SSH tunnels to link nodes) across multiple timezones. Woo Hah!
All of my servers run NTP, from the routers, which in turn pull from tick and tock at the Naval Academy (or NRC, can't remember offhand which).
Most federal agencies seem to evaluate Windows against proprietary Unix solutions and (duh) find that Windows is cheaper. If they *really* care about security they almost always have their own solution (often in hardware) that you will be asked to code to / talk with / work in conjunction with. Short of that, offering to use NSA SELinux (because of the NSA's "approved" cachet) really seems to open a lot of doors for Linux.
:-). But, the odds are against it.
En Garde may be better, for all I know. But I'll be using SELinux for gov't clients wanting high security, and OpenBSD for my need-to-be-hardened services, because I know they are excellent tools for those applications. (sorry folks...)
The above are just my experiences. For all I know it could be a vast conspiracy to provide disinformation
and I am a professional sysadmin. I get paid a lot to do my job and I don't feel like there is anything mystical about it (that sort of nonsense is for university admins that have to deal with incompetent bosses -- more power to 'em, but I don't). What I feel adds value is not mere understanding of the protocols (relatively easy) but rather, the ability to choose the correct tool (protocol, framing, hardware, software) for the job, and make it work so that the rest of the people involved can do their jobs without noticing (or if they do, saying, "hey, that's really cool and easier than before!"). Needless to say I do a good deal of development to make this happen, and again, that is more challenging than administering boxes (IF you start with a sane rollout and upkeep process -- yes, RPM/apt/pkg_add is your friend; yes, CVS/CVSup/Rsync is your friend; no, ad-hoc changes are not the Better Way to proceed).
When you rattle off NNTP and crap like NIS/LDAP as if they were equivalent in complexity to full BGP4/MBGP routing, I think you belie a superficial understanding of the situation. Even something as nastily complicated as BGP route maps is not nearly as challenging as dealing with people, professionally and personally, in a fast-paced environment that values results over process or the latest fad technologies. In that respect I do not believe it is significantly harder to earn one's keep as a sysadmin than to do so as a VP Sales or a Comptroller. It's just a totally different set of technical skills used to do the job.
I don't doubt that you meant well, but really, choosing the right tool for the job (and then using it well) is not so difficult in most cases. 'Tis a poor craftsman who blames his tools!
Or use this one, if you must
SICP online (my god that background is ugly)
Not to be confused with the Society for Invasive Cardiovascular Professionals, mind you.
In the words of a programmer noted for both correctness AND efficiency,
Premature optimization is the root of all evil
:-)
$ perl -e 'foreach $i (1..100) { $sum += $i; }; print $sum . "\n";'
Why waste all the CPU cycles:
$ perl -e 'print (100+101)/2;'
mmm,
$ perl -e 'print (100+101)/2;'
201$
Probably not the result you wanted, definitely not a useful result, and points out why you need to understand syntax (operator precedence) as well as structure...
I feel like Paul Graham's "ANSI Common Lisp" is more fun to work through (and makes my brain hurt somewhat less) than SICP. SICP is a really stiff book -- using that text for a class is a sure way to weed most people out. Graham's book, while very very intelligent and deep, is also a lot easier to grasp in many respects. Not a bad choice for 'SICP Lite' although that doesn't give it enough credit for what it teaches you about programming in the real world (vs. the computer-linguistics and mental gymnastics that SICP teaches you).
:-))
(Read the articles on Graham's site. They're friggin' amazing distillations of experience. If you've been programming (successfully) for long enough, you'll not only be pleasantly surprised, but will find yourself nodding in agreement whilst learning about new topics. Anyways, the book is an implementation of much of what he writes about, into his 'Mother Tongue' of Common Lisp. Hell, this is one of the few good writers who can correctly answer the question:
"If you're so damn smart, why aren't you rich?"
The answer, for anyone whose opinions you'd want to trust, is "I am", and it's BECAUSE of his opinions.
kind of like 'SICP for nonprogrammers' (\me ducks).
I liked the chapter differentiating generative recursion from structural recursion. That's a really insightful distinction in terms of the mechanics of grasping a problem and a good solution for the problem.
Definitely worth a read, although I think SICP is the cleverest (most intellectually satisfying) exposition of these little gems ever written.
I am reading (and doing) Paul Graham's 'ANSI Common Lisp' book for amusement and it's really sharpened my thinking. Macros are a great example of meta-generative-recursion, if you can call it that. Whatever you call it, it's raw power.
You conveniently omitted the one outlier that the pattern converges upon. Anyone who understands quicksort could tell you that ;-)
1 + 99 = 100
2 + 98 = 100
...
50 + 0 = 50
sum (1..100, step=1) { x } = 5050 because of that.
Come to think of it, patterns like this (eg. all the multiples of 9 x a single digit N have the first digit as N-1 and the second as the difference 9-(N-1)) are probably why I hated calculus and used Taylor series in place of integrals every chance I got in college.
Integration still seems like voodoo to me. Sequences, now there's something *REAL*.
(even in job choices -- computational chemistry, database work, etc. -- I ended up with discrete rather than continuous bases for solving most problems... odd)
> How many people can add up all the numbers from 1 to a hundred quickly?
;-)
I can...
$ perl -e 'foreach $i (1..100) { $sum += $i; }; print $sum . "\n";'
5050
Probably should have done this recursively for brain calisthenics, though
and I've implemented reasonably correct versions of almost all the others, so I am not just 'guessing' but offering observations from someone who's built several systems like yours.
You want accounts and you want them managed separately from billing. Physical security is what should realistically protect the private payment and identification information that relates to those accounts (eg. the substance to their metadata) so that day-to-day manipulations of orders are separate from month-to-month billing updates.
You simply must keep private info private and enforce it via legal and policy measures. No amount of technology will easily prevent misuse of your data. You could, however, experiment with CryptFS or StegFS to make it much more difficult for a physical security breach (eg. stealing the machine) to result in information leakage.
When I went back and reviewed the submitter's question I decided that I had focused on the wrong aspect of his question. One-way encryption (outside-to-inside) is important, and it can be keyed to the same database as customer account identifiers, without divulging useful information on a public interface. However, the primary measures for his company to take are still going to be policy (dissociating private customer data from public/unimportant customer identification data) and legal (physical security, pressing charges when anyone tries to circumvent).
Again, every measure I'm discussing above is something I've had to deal with in my job, and I am merely offering opinions as to what has worked best for us. I design my systems (at least at this point in my career) so that, for the most part, someone could steal them outright without greatly affecting our day-to-day operations.
PGP-encrypted SMTP relayed on an internal VLAN to a machine with the 'recipient' key, decrypt ONLY on the destination machine, encrypt ONLY on the Internet-facing machine. Perl classes for this exist and implementing it is therefore a question of writing the appropriate 'glue' for your site.
Internal access and usage is a policy issue. There is no way to engineer a usable solution whereby a user cannot write down a credit card number and expiry date and begin using it to buy stuff short of policy, enforcement, and legal action. You'll come up with some real Rube Goldberg schemes if you try, but fundamentally, if you must have human contact with the billing authorizations, you have a policy issue, not something you can ironclad by technology.
You will simply have to ensure that only trusted staff (eg. have a vested interest in the company's success) have enough access to do any damage. Technological solutions to social problems are a very poor fit and a very large time sink.
Sorry. We segregate authorization and billing where I work so that I don't have to jump through these hoops anymore. Small-order authentication is farmed out (and with it, the liability) so that our major customers are charge accounts with whom we deal personally in case of a problem.
My entire staff uses PuTTY and I've fixed site problems from halfway around the globe (in Cambodia and Laos, no less) using it. It is a godsend like none other. Even on machines where I cannot save items to local disk, the 'run from current location' feature on Windows lets it work fine, and then I leapfrog in with an RSA key...
The forcible-keying and cipher selection options in 0.52 play nicely with OpenSSH 3.0+, which in my opinion elevates PuTTY above ttssh. The only competition is the Mac version, 'Nifty Telnet-SSH'.
Of course, nothing is as convenient as my ssh-agent process that spawns my X sessions at home. Since all my machines are RSA-keyed, and most are ONLY RSA-key accessible, access is transparent for me and damn near impossible for Bad Guys. (I allow an internally-usable backdoor for staff at the office without using RSA keys, but only on a couple machines necessary for their work... it's funny that now, if I screw up an OpenBSD upgrade, I get complaints about mutt not working. Everyone assumes Outlook is a POS, but they know I'm responsible if they can't use Mutt from a PuTTY session at some Kinko's or DoD machine!)
Life With Qmail
Building a Linux Qmail Toaster
Same thing, but with FreeBSD (more scalable, in my experience)
have fun
Yes. And it is 12 characters long. But the idea is not to let people get a hold of your private key in the first place. Furthermore, brute forcing an RSA key is slower than brute forcing a weak login password.
crack this with JTR:
K wa U3KprZ4oidOjSwu UAWW/X1NxdC1Dog2 ra/sUWmNYClJWC0 LOXSfpvL8HgEBMG4 eibA124QIVAMznc 3oJ/BAr7IMDyCBF1 Iidf0ou4PvaeBjm ZyUyMT7zrCZtQC2C 7ZUbow5vPlVSbrV Eb1Uko7F0Z/914Tc 4qx3/wW3eBheNmF RHt/fL/6qgLhInab nXiOn4N8egBuuNR 5p0icOY6L/zaBMqw iGn3gm3LgE9MkKy KAhM5hHU1GyoYUSe +OV6wCFCBN9faK
MIIBuwIBAAKBgQCvUCC9yWCa83yU3Ebjc5su9pFCoENwPEu
J9Q4Or2FqIK9zd/VDvTsbW875/pKe13BN
vHz4JGz6HRSNWyW0KweCNN6oNAiICks87
RJxmFVhZ5gF4/Pt1GHkFSAyHAoGBAJ/7p
VkcsSYMizrbP9O4Gwtt30MdWqUxY21NFA
7RWmzF4P+xN8zZABbHXlv01uDGZvnmK9W
elSArUMLAoGAO4cO0FqefRT6VshGt4T3v
7hBy56BNWMuP7Z/ixROhxv59gCJTsKEFt
Gk8LxtdRBPgpoK0BwmEQhZEAL5pfemW94
BQG08IhGGotd8mBIfO4s
no, of course that is not my private key. But it proves a point. Don't rely on false randomness to enforce security. Do it the right way.
While you're at it, read Schneier's book(s) and subscribe to Crypto-Gram. I force-feed it to my network users every time it comes out...
Umm, first of all, it's EE Times. Second of all, the quote is from the VP of R&D at TI. Get your facts straight, knucklehead.
would accept a paycheck while senior management is still pulling down. It's one thing if you really are a small company (mine is) and you agree to put off cashing expense checks, etc. but a pay cut? That just means the company doesn't think you're worth much. And if you accept it, that means you agree. Pretty pathetic, unless it's true.
My boss draws a salary of $0. I pull down considerably more than that. We have had some arguments through the lean times, but in the end, he's discovered the fundamental truth that I charge people what I am worth, and if you've got a solid business plan, I *will* make it happen for you.
If you don't, I'll be hitting the road.
Pay cuts are for chumps. Next time, ask for what you're worth, no more, no less, and stand firm.
The quest to win the lottery is a poor business model, and not the way to support multiple people. Most actresses start out (and end up!) as waitresses, most football players get a real job after they fail to make it to the NFL. And most dot-commers got a wake-up call when the money ran out.