Perl for System Administration 106
| Perl for System Administrators | |
| author | David N. Blank-Edelman |
| pages | 430 |
| publisher | O'Reilly and Associates |
| rating | 9 |
| reviewer | chromatic |
| ISBN | 1-56592-609-9 |
| summary | A royal buffet of ideas to stimulate system administrators |
The Scoop
Despite being what some call 'the purest distillation of Unix thought,' Perl has earned a place on many Windows and Macintosh machines for its power and flexibility. Unix administrators have developed and honed small scripts for decades, but their brethren elsewhere have had no such luck until recently. Enter ActiveState, IndigoPerl, and MacPerl, to provide the tools, this book the knowledge. Floating subtle suggestions between pragmatic tips and tricks, David N. Blank-Edelman weaves nets, strong and sophisticated, for the perpetual battle against encroaching entropy.What's to Like?
Anything that saves a beleagured sysadmin time is very good. Any one chapter read in isolation will yield at least one new idiom, if not many ideas on improving efficiency and accuracy. The central theme of the book ('make things better by using a database to store all of your information') is an excellent and timely idea. It's not essential to the presented examples, but has the potential to simplify your work dramatically. Besides maintaining a central repository for usernames, accounts, network information, and passwords, it allows automated configuration file building. Imagine never hand-editing DNS records again, or having to enter user data only once.The sample code is clean and understandable, taking full advantage of many CPAN modules. When competing modules exist, Blank-Edelman demonstrates each, with an eye to advantages and disadvantages. This pragmatic analysis governs other discussions, especially concerning cross-platform and Pure Perl versus glue-code isses. Realizing that most networks combine many different clients (Unix flavors, the Windows cousins, and Apple machines), the author provides solutions to the same problem on all applicable platforms.
Though pushing the envelope on certain technologies (at the expense of others), the Appendices provide adequate introduction. The LDAP and SNMP sections stand out in particular. The author provides enough background, whether on Active Directory, TCP packet construction, or e-mail headers, to flesh out his examples. A table at the end of each chapter lists all modules covered, authors and versions, CPAN ids, and alternate download sites. In addition, the book provides many links to further information on techniques, RFCs, references, and vendors. If you're left wondering where to go to learn more, it will be your own fault.
What's to Consider?
The book assumes a working knowledge of Perl. Anyone who's made it through 'Learning Perl' or 'Elements of Programming With Perl' should have no trouble -- complex idioms and module peculiarities receive sufficient explanation. Beware, though, that the sample code does not enable warnings or run under strict mode. (Production programs need error checking, which, the author explains, could easily double the size of his examples.)Not all sections apply to all OSs. The Macintosh, for example, has no concept of multiple users (OS X not being covered). These differences could hinder the text, but are clearly marked and can be skipped with no ill effects. Besides, few networks are homogenous, and astute readers will learn more about the system in general from the similarities and differences.
Some common administrative tasks have been left out in favor of emerging or more complex technologies. There's nothing on managing printers or backups. A sysadmin of reasonable experience who makes it through the book will have gained a proper mental framework to tackle other tasks, though.
The Summary
Perl for System Administrators is packed with useful tips, making the most of Perl's ecological niche. Whether you're a junior administrator venturing out into the wild world for the first time, or a seasoned BOFH, you'll find something to digest here. You might even get some free time out of it.Table of Contents
- Introduction
- Filesystems
- User Accounts
- User Activity
- TCP/IP Name Services
- Directory Services
- SQL Database Administration
- Electronic Mail
- Log Files
- Security and Network Monitoring
- The Five-Minute RCS Tutorial
- The Ten-Minute LDAP Tutorial
- The Eight-Minute XML Tutorial
- The Fifteen-Minute SQL Tutorial
- The Twenty-Minute SNMP Tutorial
You can purchase this book at ThinkGeek.
Correct Title (Score:2)
Re:Get a clue timothy (s'possed to be funny?) (Score:4)
First off, the biggest idea I take issue with is that web development isn't programming. Web applications can match other applications in their scale and the engineering effort required. You come up with requirements, you spec, you code, you test. The fact that the UI comes through a browser through a web server doesn't change this. And boy, I *long* for the wasted months of youth that could have been saved if I had only used Perl for some of these projects instead of C.
OK, some line by line responses:
Object orientation - Perl's oop features are available, but not enforced. Real programming languages like java and pascal try to enforce good programming methodologies. This is a good thing, and the reason we don't code in assembly anymore.
People still code in assembly sometimes. Why? When it gives them an advantage they're looking for. Ditto for Perl. Except Perl arguably has a larger set of advantages. OK, most people really do a lot of the things we think of as for assembly in C. But wait. C's object orientation features aren't enforced -- they're nearly non-existent (though you can and should learn to do OO in plain ol' C). Alright, C++. Which has a dozen workarounds for its OO features and doesn't enforce their use. Still pretty popular for all sorts of things. I assume some people find its feature set useful somehow.
Readability - I know that it's possible to write readable perl, but nobody does it. Go search cpan, look at how many people bother to explain their line noise looking regexes. If programmers are allowed to be lazy, they will.
Been said before, will be said again (at least by me): bad code can be (and is) written in ANY language. Especially C and/or C++. Which are still widely used by developer for their advantages.
(That said, Perl programmers really do seem to gloat sometimes over their terseness and cleverness. Great, guys... just don't put it in code someone else has to maintain. Same goes for you clever C programmers).
Standardization - Perl isn't standardized. There's no guarantee that ANY language feature will work in future releases. Do you want to stake your buisness on that?
Well, for one thing, I don't have a problem staking my business on that because any version of Perl is pretty much freely available.
And furthermore, in practice, I find that Perl is as portable as anything I've written in C or Java or Pascal. Maybe more. The problems with all the latter languages are usually with libraries and class frameworks and proprietary extensions, but they're still there. The only problem I've ever had with Perl portability has to do with certain features not being available on *nix but not DOS/win32. And so I put some extra effort in and wrote cross-platform Perl.
Maintainability - Perl is damned near impossible to maintain bin the real world. Combine terseness with "there's more than one way to do it" and you have a recipe for disaster. Competent programmers can maintain another competent programmers perl code, but when was the last time you were assigned to maintain good code?
When was the last time your were assigned to maintain good code in any language?
This is practically the same argument as readability above. All the same responses apply.
When was the last time someone competent was hired to maintain yours?
Three weeks ago.
There's a reason why COBOL and VB are so popular in buisness, and that's that any idiot can write and maintain them.
This is a virtue? COBOL and VB have virtues that Perl has not? Ahhhh... ok.
Re:I Really Wish (Score:2)
Pissing off mac loyalists is the best though. I dropped 25 karma in a day that way.
--Shoeboy
Assumes a working knowledge of Perl? (Score:3)
A real review (Score:3)
------------
a funny comment: 1 karma
an insightful comment: 1 karma
a good old-fashioned flame: priceless
Get it right! (Score:1)
It's rather frustrating trying to search for a book that doesn't exist!
Re:wrong-o (Score:1)
gee... that sounds rigid...
(10 lines of code)
# woohoo!!
(10 more lines)
# wee!!! i'm a comment
(yet another 10 lines)
# kiss my ass! i ain't commenting shit!
even easier to circumvent than the lameness filter.
Get a clue shoeboy... (Score:1)
Object orientation: is this the truly the end all, be all idea that if it doesn't force a programmer to do oop then it's a bad language? I don't think so - there are plenty of languages that don't force oop and are considered excellent. C anyone? or how about VB? They don't force anyone to oop.
Readability: I've yet to see any program that is not in a book that could be deciphered. It's not perl fault if people can't devine regex's.
Standardization: What language is truly standardized across all versions? And how many companies based their business on other languages only to have features disappear? Alot, this isn't a problem with the language but with the process of standardizing anything.
Maintainability: How much code is easy to maintain? Not much, doesn't matter if it's VB (eech!) or COBOL (double eech!). If programmers don't document their program then it isn't easy to maintain.
Overall, everything you mentioned in Perl has already happened to every other language and will continue to happen. Why? Well, that is evolution of a language. To fault one is to fault them all. Nothing is perfect but it's nice to have a language that will forgive you of your trespasses and allow you to complete the work. Large scale or not, Perl always completes it's goals and then some.
Don't like it - Don't use it! But Perl is so that you don't have to be a great programmer to complete great projects. How many languages can do that?
Re:Get a clue timothy... (Score:1)
As we java developers say: program to the interface. You can't do that in perl.
Huh? Then what the heck is CPAN? A big archive of interfaces, with documentation and conventions startlingly similar to javadoc.
Properly-written perl modules work exactly like properly-written classes, with the exception of not enforcing types, for obvious reasons. Oh, and not having to type 80 characters to get to your function. ;)
Java can stop some idiot coming and screwing up your code by ignoring the APIs
Ahh, so idiot programmers are perl's fault. I see.
All of your arguments seem to be against any large-scale coding project. Improper interface documentation and infrequent or non-existant code reviews will screw you up regardless of the programming language used. It seems like you've been screwed by some idiot programmer in the past. If this perl programmer is screwing up your project, you should be talking to your manager, plain and simple.
1st Law Of Networking: Loose ends are bad, termination is good.
Bridging gap between sys admin and programmer? (Score:1)
Re:What Next? (Score:1)
Unix (3-4 flavors)
WinNT
Novell
Cisco and Motorola routers
And also need to be proficient in 4-5 programming/scripting languages, that no one else on staff knows, you need help.
This book (I own it) has examples that you can apply to your own systems with minimal modification. Why re-invent the wheel?
-nme!
Re:Get a clue timothy... (Score:1)
Lots of people have mentioned that you are wrong. I would like to cite an example.
Tivoli's TME10 Enterprise Management Framework, and the associated products which tie into it, employ a significant number of perl-based CORBA methods.
This is not a large application entirely written in perl, but it is a large application which contains a significant quantity of perl. Perl has a number of significant advantages, in that it's cross-platform (as long as you take into account what kind of system you're running on) and easy to work with. If you treat perl more or less like an uncompiled C which is loosely typed, it's not difficult for multiple people to work with.
Arguably, since the people most interested in flash tend to be artists... well, I'll let you draw your own inferences.
It's a good 'bridging' book. (Score:3)
If you want to learn perl -- buy Learning Perl. If you want to learn system adminstration, get the Unix Systems Administration Handbook. They're both good entry level books in their field.
Perl for System Administrators was to me, more like the Cookbook -- it tells you about lots of things that you can do with the language, as 90% of the perl books out there seem to focus on text processing [eg, HTTP interfaces] Personally, I got it as a reference for work I'm doing with HTTP interfaces to LDAP. Most of the rest of the book either I don't need to worry about right now, or I've already done before, so is only useful if I want to find out why the way I did it was wrong.
This is a _very_ niche book, as you need to know both system administration and perl, and actually care about one of the chapters in the book. If you fit into that category, it'll probably be of immense help. I know it was to me.
Re:An impassioned plea for negative reviews (Score:1)
if the scale is from 1 to 10 you cant give a 0 to a book. The least you can give is a 1.
Re:Bridging gap between sys admin and programmer? (Score:2)
[and yes, I do crimp my own cables... at home at least, because I'm cheap. But it's a bitch finding places that'll sell cat5 stranded and stranded ends, as everyone seems to only stock solid cable in this area, and expect you to pay out the ass for pre-made patch cables]
Re:An impassioned plea for negative reviews (Score:2)
That was my point. There are some things that deserve to be off the bottom of the scale. There are movies that should not be watched and books that should not be read because they are such a waste of precious hours.
Re:Sigh, I must disagree with your perl criticism. (Score:1)
Er, this might have something to do with the fact that C has existed rather longer than has Perl. In fact, I suspect that the Obfuscated C contest itself is older than the entire Perl language. :-)
Other than that, interesting points. :-)
Re:Perl will be the downfall... (Score:1)
domc
Re:Ummmmmm....excuse me? (Score:1)
I've heard the difference summed up this way: Systems administrators know how to do things, and programmers know what to do. Both useful, but ultimately divergent, skills.
I bought it (Score:1)
--
Re:Assumes a working knowledge of Perl? (Score:1)
Re:Great Book (Score:3)
--
Re:I Really Wish (Score:1)
Re:Ummmmmm....excuse me? (Score:1)
Re:Tasty and delicious. (Score:1)
An impassioned plea for negative reviews (Score:5)
In part this is because the reviewers here mostly review books they've taken the time to read all the way through. Those books tend to have several qualities:
These add up to scores above 5 on a scale from 1 to 10. Perhaps what Slashdot needs is for a few of us to admit some of our book-buying mistakes and review the real dogs. And for any of you out there who have ever been given a really bad book, this is an opportunity:
Review the 3 out of 10 books! Hey, consider it a challenge. Find a book in a subject area that should be reviewed on Slashdot, but that richly deserves a 0 on a scale from 1 to 10. There has to be at least one. Warn us all before we waste our money!
Re:Losing Karma (Score:2)
Re:Get a clue timothy... (Score:1)
Of course perl doesn't actually prevent this in any literal way. However, the practical result of perl code is that once it gets above a certain size, the whole tends to glue together into one creaking mass. Perl simply doesn't support advanced language features such as reflection in java, which allows you to ensure that your code is cleanly separated.
As we java developers say: program to the interface. You can't do that in perl. Java can stop some idiot coming and screwing up your code by ignoring the APIs, in perl you're forced to rely on trust. A trust-based coding system simply doesn't work once you've got more than just a couple of coders working together. Bondage can be good for you.
wrong-o (Score:1)
The vast majority of programmers do not have the skills or the discipline to produce maintainable, readable code. This is why, for large-scale development projects, teams either insist on rigid coding standards (i.e. if you don't comment every ten lines, you can't check your code in), or languages which enforce their own standards. As an example, the US Ministry of Defence has long insisted that all defence-related software be written in Ada, solely because it is a safe language with enforced coding standards. My organisation, on the other hand, insists on Java and Eiffel.
I'd really like to see someone substantiate these claims that people write maintainable, readable perl. Anecdotal evidence would seem to sharply discredit this view, as would looking at most major large perl projects [slashcode.com]. Perhaps this code exists in on the hard-drives of these virtuoso perl bigots, who shield it from the masses as the Israelites shielded the Ark of the Covenant from the rabble. Who knows?
Re:Get a clue timothy... (Score:2)
You forget functional and logic programming, you bastard
> From the Jargon file "Real Programmers Don't Document: If it was hard to write, it should be hard to read"
Most of the time, Perl isn't hard to write, so it shouldn't need to be hard to read. Except for the regexps, of course, which are _allways_ harder to write than to read (despite what newbies seing a regexp for the first tim e thinks).
> It's easy to obfuscate any language
Of course. But most languages doesn't come with _auto_obfuscation_...
Trolls are what makes
What Next? (Score:1)
How many of these Perl for Increasingly-Small-Demographic books do we need? Can't system administrators just get Programming Perl and figure it out? It's not rocket science.
Nearly any computer owner is a sysadmin (Score:2)
But what I'm finding is that any computer owner has to be a sysadmin for their own system. The tasks are different and vary in depth and patience required from platform to platform, but they're all there. Linux raises the bar -- in order to run your own Linux box, you have to become a *nix sysadmin.
The only situations I can think of where I haven't had to be a sysadmin is when I worked for places large enough to hire their own.
Re:Tasty and delicious. (Score:1)
Which is it?
Re:Get a clue timothy... (Score:1)
(Only meant as a joke, I'm not blindly bashing.)
Re:Get a clue timothy... (Score:1)
Of course. But most languages doesn't come with _auto_obfuscation_...
Two words for you...
LISP
APL
Re:Great Book (Score:1)
Re:Get a clue timothy... (Score:1)
The Good, The Bad, The Ugly... (Score:1)
Maybe back 10 years ago, the venerable sysadmins were ripping the O'Reily books you were reading. I haven't read the book...but I am a sysadmin with 5 yrs in the biz. I'm not a perl guru, and I've really never had time to learn it. Perhaps I should...perhaps I shouldn't. But it seems that if you know everything there is to know about being a sysadmin, you shouldn't need this book. So why are so many of you complaining about wasting your money?
Re:Assumes a working knowledge of Perl? (Score:1)
Ummm, I wouldn't. Perl is the first word in the title. Mayhap if the title was "System Administration for Perl", I would assume you didn't need previous knowledge of Perl. Besides, I have "Learning Perl" (among other O'Reilly Perl books), and I wouldn't want this book to duplicate the information in "Learning Perl".
Re:Get a clue timothy... (Score:1)
Re: computer owners do system administration (Score:2)
Yet I don't think it's incorrect to say that every computer owner -- who doesn't have someone to do it for them -- has to do system administration tasks. And that (from what I've read) is what the folks at Nautilus (the Eazel folks) figured out: that most often, it's not a matter of mastering UI that makes computers hard to use for people. Most folks can learn to navigate a GUI or use a CLI just fine. They just aren't sysadmins, but they're called on to do system administration anytime they install software or change a setting from what it was out of the box.
Re:Assumes a working knowledge of Perl? (Score:1)
Re:nah (Score:1)
Re:Get a clue timothy (s'possed to be funny?) (Score:1)
you start working on your resume, because...
no.
Re:light handed on the criticism? (Score:1)
I haven't worked all the way through Linux Programming Unleashed... if there's a review there, it won't be smiley happy. Look back to the second or third of the Learning Linux articles for some harsh comments about a book that got stuff wrong.
I don't take the scores too seriously, though. I take off points for stuff that's obviously wrong, stuff that's hard to read, and stuff that doesn't fit the focus of the book. Beyond that, you're just reading a summary based on my opinions. They're free, non-fattening, and if Hemos sends me a copy of Teach Yourself and Other Assorted Idiots Perl 6 in 24 Minutes, I'll rip it up. Just for you.
--
Ummmmmm....excuse me? (Score:1)
----
Re:Nearly any computer owner is a sysadmin (Score:1)
Re:Assumes a working knowledge of Perl? (Score:1)
Great Book (Score:2)
Re:indefatigueable... (Score:1)
Or just ineptitude at grammar. 8?)
Let the person without sin cast the first stone...
Re:Ummmmmm....excuse me? (Score:1)
I receive many question and I have to decide
it is a user-error, a system-error or a
software-error. If it a software-error I will
request ( demand ) a patch from the programmer.
This task is only possible if you knows a lot
about programming and the system. Else it is
not possible to decide if it needs a patch.
SysAdm are smarter.
Someone really likes perl here (Score:1)
Re:Ummmmmm....excuse me? (Score:3)
Yeah, right. Developers are the ones who like to assign null passwords and "chmod 777" everything so that annoying little things like system security and permissions don't get in the way of their code-monkeying. Of course, once they get root'ed, or someone recursively deletes an entire code tree that was mode 777, who do they turn to for salvation? The sysadmin.
Re:Ummmmmm....excuse me? (Score:1)
Losing Karma (Score:2)
blah blah blah Perl blah blah Python blah blah (Score:2)
Could we have a single Perl-related article on slashdot where the comments actually deal with the article at hand, and don't degenerate in to a general discusion of 1) Perl, 2) the readability and maintainability thereof, or 3) the inferiority or superiority of Perl as compared with Python or any number of other languages?
Uninformed generalizations are a dime a dozen.
--Bruce Fields
Re:Tasty and delicious. (Score:1)
While all of these O'Reilly books are pretty good, they lack the programming focus that I think this book should fill nicely.
If you want "programming focus," don't use Perl. You'll end up needing Bi-focals and magnifying glass just to get a smidgen of clarity from it.
If you want real programming focus, take a couple of intro classes at your local University. Use Lisp.
Juicy cranberries grandma!
Sigh, I must disagree with your perl criticism. (Score:2)
I have a pretty strong suspicion that you're just trolling but on the off-hand chance you're not I'll try to make a somewhat educated rebuttal. Note that I'm not a CS major (computational chemistry), but that I do program a lot and I have done so for money. In other words, I tend to have a very pragmatic outlook on computer science.
Object Orientation -- Leaving aside the large and very valid debate about whether or not OO is a panacea (it's not IMHO, grotty OO code is still grotty, as is grotty functional lang code, et al.), bondage-and-discipline languages that try to force developers into doing something are not a good thing. Why? People get pissed off about the restrictions and find ways around them. Example: #define private public in a C++ header file. If you subscribe to the ``efficient market'' theory (lots of smart people looking at the same problem will arrive at roughly the same answer (c.f. the stock market and share valuation)), and believe that strict programming languages are a good thing, then why isn't everything being written in Ada today? (Oh, and the ``Real programming languages'' bit is really idiotic. I guess Linus was just using those toy languages C and asm when he coded linux's kernel...)
Readabilty -- is a function of the programmer, not the language. Regexps are line noise but they are the most effective way of transmitting meta-lingual patterns, so it's just a sub-language like any other proigramming language (you're programming matches on text instead of bits on a chip). It's just as easy to write bad Java as it is bad perl, and it's _really_ easy to write bad C (don't forget the obfuscated C contest has been around longer than the obfuscated perl one).
Standardization -- Nothing is constant in the IT industry. Just ask the guys who wrote the DB code for the airlines back in the 60's before the whole relational db / SQL revolution. Standards for a langugae are of overblown importance anyway, just go and try to tell me that advanced (read: uses all the advantages of the environment) C++ code for VC++6 and g++ are the same, even if you use "Standard C++". :-) To use one of your examples against you (of a "real" programming langugae), Java isn't standardized. Sun could decide tomorrow that "well, we never did like the + operator so we're deprecating it in favor of $%$(*@ as the addition operator". Secondly, since when do businesses recode everything as soon as a new release of somethig comes out? 4 of the last 5 places I've done contract work for were still using RH 6.0 and perl 5.005. (The other place was using 6.2 and 5.005) Thirdly, the language is communaly designed so it is highly unlikely core language features are going to change night-and-day in one or even two releases.
Maintainability -- so in essence you're saying every programmer before and after you is a Forrest Gump? Uh, yeah. Basically this boils down to the same thing listed under readabilty: to get good code you need good (disciplined and technically proficient) coders. Try arriving on a consensus in your coding dept as to code standards (<-- this will be much more effective if the coders themselves come up with it that a dictate from on high), and make sure you hire good (see de above) people. The rest will work out. COBOL and VB are popular in business becuase they just want something that will get the job done, and since both of the langugaes were designed to fit into the "problem space" of business, they are a path of least resistance. (They are the "good enough" solutions, although I think and hope that Java is beginning to replace them.)
As to your original thesis that perl isn't used by real programmers, well, I have about 200Kb of genome analysis code that ties into some hefty vis libs written in OpenGL that proves it wrong. :-) I.e. I think that's outside of the realm of webdev and sysadmin (which perl is very good for but is hardly it's sole strong point)
This is not to say that everything should be done in perl. All true masters of their trades[1] realize that no one tool is the perfect one for all tasks, so each should be used in accordance with its strengths. I.e. I'm not going to be writing any kernel modules in perl any time soon, kOrbit notwithstanding.
[1] I'm not claiming I am one, just noting a fact. Michaelangelo used more than one brush painting the Cistine Chapel. (I think that's the guy, but even if I'm forgetting the name the point stands.)
--
Dirty little secret (Score:1)
Re:Get a clue timothy... (Score:1)
Anyone that believes that needs shooting, IMO. It's the programming equivalent of saying "i have a proof that this works, but it is too large to fit in this margin" (sorry if that quote isn't spot on there).
Re:Get a clue timothy... (Score:1)
--
Slashdot didn't accept your submission? hackerheaven.org [hackerheaven.org] will!
Re:Ummmmmm....excuse me? (Score:2)
Developers changing IP settings at will for test purposes, causing quite a few duplicate IP addresses.
Public storage areas losing 300MB or more overnight, due to someone installing pirated software on their project data area.
Backing up entire workstations to the same project area during the day, slowing down our filesserver to a crawl whilst at the same time consuming all of that segments LAN utilisation.
Hardware breaking due to one developer believing he knew what to do with a screwdriver. Also during one training course *EVERY* PC in our training room had it's memory tinkered with in some way.
Complete disregard for file permissions. Chmod everything to 777 recursivly, as it works.
Borrowing AUI to UTP transceivers from important equipment, believing them to be network cards.
Installing a demo network for an important client whilst using Parrallel port NICs, then wondering why the demo ran slowly. (I was out of the office that week).
'Installing' Windows based software to the network, eating bandwidth when executing the code. Very common in our office. My boss (a developer) did this with a 30-40 user roll-out of an Office suite at an important client. I had to fly out there on a weekend to fix it.
Re:Another? (Score:1)
Unix admins, maybe... NT/W2K sys admins need this book. Every one I've been acquainted with has been surprised when I told them how much you can do with Perl.
---
Re:I Really Wish (Score:1)
all ya had to say was...
python!!!
python!!!
python!!!
python!!!
see?
Re : Programmer v.s/like SysAdmin ? (Score:1)
Well, I have both side represented in my resume, and since I did spend a lot of time on the programming side, I'm now looking the other one.
If you want to venture in analogies, I will try to take more close examples, even the mechanic one is very good. If you leave the programmer alone, I think that the people doing whole system/integration test are close to sysadmins :
They know the system on the whole, with a more a global point of view than of any particular areas.
The same way, they learn to look at the system in a more organic fashion : a programmer will go for the log files, a tester will know right way something is wrong because that operation is taking too long...
they have to go deeper into details (code) when something is wrong, so they might end up criticizing/commenting on the design
they have to be anal-retentive, to make sure that every dark corner is covered
even if this is less obvious for tester, since they have some good troubleshooting knowledge on the system, they well might end up answering customer questions, even if that's not their daily job.
This is obviously looking at the same system from a different point of view : the builder and the maintainer.
However, one of the great advantage of having sysadmin do developpment and developper doing sysadmin is on the requirements gathering. Since getting relevants requirements is one of the thorniest problems into software developpment, having both roles allow to much more communication.
troubleshooting/sysadmin people are complaining because soft X has no log files to troubleshoot
the design team create log files
after a panic caused by a full disk, the troubleshooting/sysadmin people are complaining again
th desing team add circular logging.
This is a typical examples where overlapping is not only desirable, but should be required, because a lot of reverse story exists as well.
Re:Another? (Score:1)
Although PERLs syntax is fairly easy to learn, and syntacticly clean, much of the advanced functionality availible is implemented through hundreds of external modules. How is every sysadmin supposed to just instantly know what modules are availible for what purposes, or to another extent, which ones are the best.
You also mentioned man pages for PERL? Have you ever seen the monster? Even the FAQ is split between some 9 different man pages? All of the functions are on the same page, and even though they are split up into usefull categories they man page is less than intuitive.
Perhaps this book may not be well suited to _you_, however, I'm certain there are a whole host of sa's who have at least a strong foundation of PERL, but would like to extend that knowledge to allow for more advanced scripts to be written.
Re:indefatigueable... (Score:2)
They must keep forgetting how to spell dictionary.com :D
"Free your mind and your ass will follow"
Re:Assumes a working knowledge of Perl? (Score:1)
nah (Score:1)
LISP isn't auto-obfuscated, you just hate parentheses.
Register, goddammit!! (Score:1)
It'll take 5 minutes. Register!
Re:nah (Score:1)
Re:wrong-o (Score:1)
perl -p -i -e 'BEGIN { $a = [ "A" .. "Z", "a" .. "z" ]; } $i++ % 11 == 10 and print "# Very important comment: ", map($a->[rand @$a] => 1 .. 50), "\n" ' src/*
Reply to legit concerns (Score:1)
I have seen the book become an invaluable aid for Windoze admins who had no idea that such power could be had for free. There are more in-depth books (most notably Dave Roth's excellent Perl on Win32 books), but this book does a good job of saying "Hey, look what you can do with this!".
And remember, Perl's role on Windoze (as I see it) is mostly subversive. It's a great way to introduce more computer professionals to Open Source software in an environment they're familiar with.
Re:Ummmmmm....excuse me? (Score:1)
Yeah, right. If you honestly believe that you are either a terrible programmer giving all programmers a bad name or a terrible sysadmin who never realized how important the job is. Personally I've been doing both for a while and the job sets are so completely different they're not even comparable. Any programmer couldn't do the sysadmin job and the reverse is also true. The job descriptions cross paths but that's all.
The important question.. (Score:2)
I would say an oyster, but that's to obvious.
Re: computer owners do system administration (Score:2)
MySQL books (Score:1)
Despite myself, I have some emotional loyalty to O'Reilly and I really want them to stop printing trash. Or maybe use a different cover theme for books that are garbage. In this case, George Reese's name on the cover was a good indicator of the quality. Remember his anti-perl flames on usenet?
Idiot-proof? (Score:1)
What I think you're really saying is that it's human nature to bypass the API and access a private variable if convenient, but it's also human nature to respect a minimal access barrier.
But Perl already has a minimal access barrier that's understood by Perl programmers - I've read lots of good and horrible Perl, but I've never seen a programmer getting/setting a variable in an object rather than use the API.
In any event, the whole thing is a tempest in a teapot. Object-orientation solves a lot of imaginary problems but has little linkage to the real problems programmers encounter.
Another? (Score:1)
hard-drives of these virtuoso perl bigots (Score:1)
Of course the biggest collection of Perl is CPAN [cpan.org]. I disagree with the previous assertion that modules on CPAN are sloppy. The one's I've bothered reading are really clean and nice.
You cite slashdot as an example of sloppy Perl. Please realize that it tracks a moving target. Code that powers web sites tends to be sloppy because web sites change in unpredictable ways. Want to see clean code? Look at Net::Ping for example.
I guess we live in two different worlds. The kind of projects you work on are the ones I avoid like the plague. I would never work with idiots or work under strict arbitrary rules, not when there are so many great places to work. Maybe your workplace has a vicious cycle - the barriers you've erected to keep the 'sad wankers' at bay scare off the more talented programmers.
Tasty and delicious. (Score:1)
Penguins postulate Perl programming. The Linux Pimp [thelinuxpimp.com]
Re:Assumes a working knowledge of Perl? (Score:1)
Re:Get a clue timothy... (Score:2)
Ummm... "impossible" to do large-scale development, meaning Perl actually prevents this?
So C's not a real programming language, then?
Yeah, that's Perl's fault. Impossible.
Yeah, Java never deprecates any features. Nothing in the C or C++ standards ever changed or broke existing code. And Pascal (the real programming language you mentioned, still used for so many groundbreaking large-scale projects) certainly is standardized -- who cares that none of the popular Pascal implementations came anywhere near the standards?
And any idiot will, which is where the fun begins. But then, I thought we were talking about Serious Professional Programmers.
What's next, Slashdot for Illogical, Ill-Informed Posters?
-paullight handed on the criticism? (Score:3)
but every book that gets reviewed on slashdot get an 8 or a 9. use a scale of 1 to 3 if your spread is 3 points!
i'm not saying i've never found slashdot's reviews helpful, just optimistic. (and positive reviews of the two mysql books [o'reillys and new riders] tricked me into buying books significantly weaker then the online docs)
thanks kellan
ps. if your getting sick of o'reilly, manning is has put out a number of truly quality offerings lately.
Re:Get a clue timothy... (Score:3)
Why does everybody seem to think that since OOP was created there is no longer a need for procedural programming?!
Readability
From the Jargon file "Real Programmers Don't Document: If it was hard to write, it should be hard to read"
Standardization
Every try to build a Visual C++ project with gcc?
Maintainability
It's easy to obfuscate any language
Now get back under your bridge, troll.
Re:Great Book (Score:1)
Re:Get a clue timothy... (Score:2)
Re:Ummmmmm....excuse me? (Score:1)
A mechanic knows how to fix a car. Partially from books and "cookbook recipies", but more likely from tinkering with them and figuring them out. A good mechanic will not only know how to fix a broken engine, but what to replace, modify etc to make it run better.... just like a good sysadmin.
A good mechanic can probably, and might ocasionally, machine a custom part now and again.
Now an engineer tends to spend more time designing things and testing them than tinkering with existing things. They know how it works and why. However, ocasionally will build things and have to tinker with them to find out why it didn't translate as well from paper to reality and will adjust and fix it.
They are very much overlapping skillsets. Just like I find that a good admin can program, a good programmer knows enough about being an admin to work in the "real world" too.
Of course, I have also heard Admins refered to as "Janitors" which, while true...I much prefer "Computer Systems Sanitational Engineer" - course janitors just clean up messes, admins often make them too
-Steve
Re:Another? (Score:1)
Mac OS and multiple users (Score:2)
Before any other Mac users rush in to flame the reviewer by pointing out that Mac OS 9 in fact does [apple.com] support multiple users, I would like to point out that it, in fact, does suck rocks and is incredibly brain-damaged compared to even Windows 9x's multiple-user capabilities. About the only thing it's good for is putting up a login password at startup (which can quite easily be circumvented) and for impressing your easily-impressed friends by using the voiceprint verification password thingy, which never works unless you:
a) are in a silent room
b) are speaking into a wired microphone
c) are setting it up for the first time (always fails after then)
Can't wait for OS X.....
--
This book is great! (Score:1)
The only thing of any use in this book was the Appendix, it provided a good intro to RCS (useful for training operators or non-admin staff) and a decent explanation of LDAP and SNMP.
Otherwise, it is a complete and total waste of time and money.
Re:An impassioned plea for negative reviews (Score:1)
Re:Get a clue timothy (s'possed to be funny?) (Score:1)
Just think, if you have to write a little COM component that all it does is get something from an Access database and return it and it also has to be maintainable by the manager's teenage son/daughter.
Do VB's virtues become apparent now?
Re:Get a clue timothy (s'possed to be funny?) (Score:2)
1) MS products have the virtue of being more highly integrated with other MS products. In some cases, this is an advantage
2) If you're writing something for someone with an investment (knowledge or technical) in a certain system, it's to their advantage for you to make that investment work best.
#2 is not necessarily a virtue of VB
Re:blah blah blah Perl blah blah Python blah blah (Score:1)
'scuse me, I have an axe to grind and I need to go post.....
How did you circumvent the lameness filter? (Score:2)
Re:Nearly any computer owner is a sysadmin (Score:2)
difference between a programmer administering his computer(s), and someone who's a professional, fulltime sysadmin. Calling yourself a sysadmin because you can add users and compile a linux kernel just isn't the same thing.
Re:Ummmmmm....excuse me? (Score:2)
That's nice, little boy. Run along and play now.
With an attitude like that, I already know what I think of his programming skills.
Re:wrong-o (Score:1)
PERL is excellent for this type of task. For any size organization there are always gaps between systems, or small scale systems that can use this type of interface.
Your toolbox really needs to have more than one tool in it. This is not as true for programmers as it is for sysadmins who have to put it all together and make it work.
Re:Ummmmmm....excuse me? (Score:2)
I myself, hate programing. Dispise it. I can deal with scripting up to a couple of hundred lines say, when its for making my life easier - like say automating sysadmin tasks.
Being able to program a IP stack is one thing. Being able to set up and configure a computer on a IP network is another.
The trades are as diffent as a profesional mechanic and a profesional driver. Mechanics can usaly drive, and drivers might have a mechanical backgroud, but there sure as hell not the same job.