I'll second this. It's one of the best IT "best practices" books I've seen, and the authors are hang out on the SAGE (http://www.sage.org) mailing list - which is a group you should be involved with if you're interested in IT management issues.
I've been in a hiring position and seen resumes that do that. I'm also very active in the *local* FOSS community.
So when somebody listed a "active in the FOSS community" line and I don't recognize them (and can't find any posts from them on any of the local LUG lists achives), it makes the rest of their resume suspect.
Of course, if they'd said "participating in a FOSS project based in Brazil", I'd pretty much have to call him to get the details;-)
I think you're confusing protocol with policy. An admin that only wants to support 10 simultaneous users on their FTP server (perhaps because that's a reasonable number for their equipment or bandwidth) isn't making a comment on the ability of the FTP protocol to support more.
You have heard of Kerberos and the -x option for the client programs, right?
FTP and Telnet aren't the problem. The problem is clear-text authentication (and, depending on the situation, data streams). Other than that, they're perfectly useful protocols. Using versions that solve the clear-text issue while bringing in a whole bunch of other useful features is a viable option for a lot of situations.
Get a copy of _The Practice of System and Network Administration_ by Thomas A. Limoncelli and Christine Hogan. Read chapter 15 (Help Desks) and implement it faithfully. For real-world system and network administration topics, this is the best book I've run across. There's a FreshMeat review available.
There's also a website at www.sysadminfocus.com, but get a dead-tree copy as there's not much on the website.
Then, get involved in SAGE and USENIX. These are common problems, and talking about them with a body of folks who know how to solve them is going to much more productive than posting to Slashdot;-)
In case anyone was/seriously/ curious about this...
http://www-cs-faculty.stanford.edu/~knuth/musing s. html http://www.kohala.com/start/ http://www.tux edo.org/~esr/faqs/loginataka.html http://www.cano nical.org/~kragen/tao-of-programmin g.html http://www.cryptonomicon.com/beginning.htm l http://cm.bell-labs.com/cm/cs/who/dmr/cacm.html http://docs.freebsd.org/44doc/ http://cm.bell-l abs.com/cm/cs/who/dmr/mdmpipe.html http://www.tuxedo.org/~esr/jargon/ http://www.c onceptlabs.co.uk/alicebob.html
I snarfed most of these from one of my web pages (http://www.rospa.ca/folklore/). If there's other great Unix culture documents out there, please send me the link:-)
I like to measure my tools by their/usefulness/, not their ease of use. I prefer using a ripsaw rather than a safety razor to make large rough cuts to lumber even though I have to be a bit more careful with my fingers. (I'd also rather shave with a safety razor).
This focus on ease-of-use as the only "real" metric is a dead-end IMO.
I'd love to switch one of my networks over to AFS and ditch the current Samba/NFS-combo setup[1]. Unfortunately, the OpenAFS site has this to say about the FreeBSD port: "Server ported. Cache manager support is not yet complete."
Has anyone tried a different client (arla, maybe?) against an OpenAFS server on FreeBSD? I'd/love/ to get pointers on how to make the OpenAFS server on FreeBSD work:-)
1. I love Samba, and NFS is a nice standard. But for heterogenous networks the seperate administration required to configure tools that access the same data is a drag.
The SAGE Code of Ethics seems useful for this situation.
Canon 2, "A system administrator shall not unnecessarily infringe upon the rights of users", seems to apply to this particular case. The relevent portion is:
"System administrators will not exercise their special powers to access any private information other than when necessary to their role as system managers, and then only to the degree necessary to perform that role, while remaining within established site policies. Regardless of how it was obtained, system administrators will maintain the confidentiality of all private information."
I read that to mean that if there is a site policy regardign email, the ethical thing to do is to follow the policy. Failing the existence of a policy, the ethical thing to do is to not infringe on the rights of the users.
The book the cluetrain manifesto has something to say about this. Here's my take on it:
Traditionally, markets use the language of conflict. Battles over mindshare, control of a critical market segment, etc. These sorts of internal conflicts still occurred, but they were not makde public.
The open source community makes it's internal conversation public. To me, this is a strength, not a weakness.
Doc Searls explaisn this much better than I do, for those that are interested:-)
There's also BSDI, which seems to be doing well in their niche. The model of working with a closely-related open source Unix seems to be working for them - I've seen lots of products based on BSDI (like proprietary IDSen and firewalls).
The part that spooks me is that it's supposed to be delivered by the end of the year. That's an awfully short timeline... I hope the contractors aren't setting themselves for failure, which could give the open source solution a bad rep.
I'd say that his manager needs to read items 1 through 95 of the Clue Train Manifesto. He seems to be under the mistaken assumption that preventing conversations maintains the secrecy of the Guy Behind the Curtain, when in fact all it does is point out that he has no clothes on.
... that OpenOffice 1.0 has been used as a file format for widespread distribution in two recent stories (including this one). It may not be widespread among the wider herd, but it's easy to tell someone they can read the report with a *legal* free download.
Though I'd still prefer that LaTeX was the standard document distribution format, but then I'm a die-hard;-)
"current conditions notwithstanding" my ass. Current conditions/always/ matter - and setting aside the whole paper vs. experience thing, right nwo the best thing to do is go to college.
It doesn't really matter what you take, just get some fancy papers. When there's a market upswing, *then* you can decide whether to stay in college or to start a career because you'll have that option then. Right now your options are college or a crappy start to a career with little job security.
I'm not saying that there aren't good jobs otu there (I have one myself), but with neither experience nor papers and facing the competition of all those hungry experienced and paper'd unemployed SysAdmins, you'll fare much better 9and eat more regularily) in college.
Doesn't address failover for incoming traffic. Neither do DNS tricks or other such kludgery: this is a layer 3 problem. The solution is to use IP as it was intended -- true end to end connectivity and routing issues handled by, of all things, routing protocols.
BGP with aggressive route aggregation works well. Something better running on top of IPv6 would go a long ways towards getting rid of the convulated "solutions" that a lot of organizations are setting up.
Blatant karma plug: http://www.nanog.org/ -- anyone interested in these sorts of routing issues should join the mailing list and lurk
The whole point is errata, bug fixes and security updates. Upgrades come every months in the form of a new version of RedHat (says the guy running 7.1 instead of 7.2. Heh.)
Are there any plans for an official RedHat 7.1 KDE RPM set? I'm currently running with the Red Hat Inc. KDE 2.2 set, and I'd rather not completely upgrade to 7.2 (I've done spot-updates of some of the system).
If not, what dependencies would have to be fulfilled to run the 7.2 RPMS on a 7.1 system?
Slashdot Mirror
Like NT ACL support?
Just because it's broken on Linux doesn't mean that:
* it's not better on other platforms
* the other tools aren't worse
Elizabeth Zwicky's classic Torture-testing Backup and Archive Programs will give a whole list of reasons why you should be suspicious of tar or cpio.
Heck, the FreeBSD Handbook answers the question "Which backup program is best?" by saying "dump(8). Period."
I'll second this. It's one of the best IT "best practices" books I've seen, and the authors are hang out on the SAGE (http://www.sage.org) mailing list - which is a group you should be involved with if you're interested in IT management issues.
I've been in a hiring position and seen resumes that do that. I'm also very active in the *local* FOSS community.
;-)
So when somebody listed a "active in the FOSS community" line and I don't recognize them (and can't find any posts from them on any of the local LUG lists achives), it makes the rest of their resume suspect.
Of course, if they'd said "participating in a FOSS project based in Brazil", I'd pretty much have to call him to get the details
Moral? Wording is important.
I think you're confusing protocol with policy. An admin that only wants to support 10 simultaneous users on their FTP server (perhaps because that's a reasonable number for their equipment or bandwidth) isn't making a comment on the ability of the FTP protocol to support more.
You have heard of Kerberos and the -x option for the client programs, right?
FTP and Telnet aren't the problem. The problem is clear-text authentication (and, depending on the situation, data streams). Other than that, they're perfectly useful protocols. Using versions that solve the clear-text issue while bringing in a whole bunch of other useful features is a viable option for a lot of situations.
Get a copy of _The Practice of System and Network Administration_ by Thomas A. Limoncelli and Christine Hogan. Read chapter 15 (Help Desks) and implement it faithfully. For real-world system and network administration topics, this is the best book I've run across. There's a FreshMeat review available.
;-)
There's also a website at www.sysadminfocus.com, but get a dead-tree copy as there's not much on the website.
Then, get involved in SAGE and USENIX. These are common problems, and talking about them with a body of folks who know how to solve them is going to much more productive than posting to Slashdot
In case anyone was /seriously/ curious about this ...
g s. htmlx edo.org/~esr/faqs/loginataka.htmlo nical.org/~kragen/tao-of-programmin g.htmlm ll l abs.com/cm/cs/who/dmr/mdmpipe.html c onceptlabs.co.uk/alicebob.html
:-)
http://www-cs-faculty.stanford.edu/~knuth/musin
http://www.kohala.com/start/
http://www.tu
http://www.can
http://www.cryptonomicon.com/beginning.ht
http://cm.bell-labs.com/cm/cs/who/dmr/cacm.htm
http://docs.freebsd.org/44doc/
http://cm.bell-
http://www.tuxedo.org/~esr/jargon/
http://www.
I snarfed most of these from one of my web pages (http://www.rospa.ca/folklore/). If there's other great Unix culture documents out there, please send me the link
I like to measure my tools by their /usefulness/, not their ease of use. I prefer using a ripsaw rather than a safety razor to make large rough cuts to lumber even though I have to be a bit more careful with my fingers. (I'd also rather shave with a safety razor).
This focus on ease-of-use as the only "real" metric is a dead-end IMO.
I'd love to switch one of my networks over to AFS and ditch the current Samba/NFS-combo setup[1]. Unfortunately, the OpenAFS site has this to say about the FreeBSD port: "Server ported. Cache manager support is not yet complete."
/love/ to get pointers on how to make the OpenAFS server on FreeBSD work :-)
Has anyone tried a different client (arla, maybe?) against an OpenAFS server on FreeBSD? I'd
1. I love Samba, and NFS is a nice standard. But for heterogenous networks the seperate administration required to configure tools that access the same data is a drag.
In IT, it tends to called a "contingency fee", which I think is a pretty honest way of describing it :-)
The SAGE Code of Ethics seems useful for this situation.
Canon 2, "A system administrator shall not unnecessarily infringe upon the rights of users", seems to apply to this particular case. The relevent portion is:
"System administrators will not exercise their special powers to access any private information other than when necessary to their role as system managers, and then only to the degree necessary to perform that role, while remaining within established site policies. Regardless of how it was obtained, system administrators will maintain the confidentiality of all private information."
I read that to mean that if there is a site policy regardign email, the ethical thing to do is to follow the policy. Failing the existence of a policy, the ethical thing to do is to not infringe on the rights of the users.
The book the cluetrain manifesto has something to say about this. Here's my take on it:
:-)
Traditionally, markets use the language of conflict. Battles over mindshare, control of a critical market segment, etc. These sorts of internal conflicts still occurred, but they were not makde public.
The open source community makes it's internal conversation public. To me, this is a strength, not a weakness.
Doc Searls explaisn this much better than I do, for those that are interested
There's also BSDI, which seems to be doing well in their niche. The model of working with a closely-related open source Unix seems to be working for them - I've seen lots of products based on BSDI (like proprietary IDSen and firewalls).
The part that spooks me is that it's supposed to be delivered by the end of the year. That's an awfully short timeline ... I hope the contractors aren't setting themselves for failure, which could give the open source solution a bad rep.
Where can you get the Familiar (iPaq) port? It sounds like the *perfect* time-waster!
I'd say that his manager needs to read items 1 through 95 of the Clue Train Manifesto. He seems to be under the mistaken assumption that preventing conversations maintains the secrecy of the Guy Behind the Curtain, when in fact all it does is point out that he has no clothes on.
(Woohoo, a new low in mixed metaphors! *grin*)
... that OpenOffice 1.0 has been used as a file format for widespread distribution in two recent stories (including this one). It may not be widespread among the wider herd, but it's easy to tell someone they can read the report with a *legal* free download.
;-)
Though I'd still prefer that LaTeX was the standard document distribution format, but then I'm a die-hard
So let's not go and explore. Let's go and /stay/. Robots don't make good colonists, and telescopes are just dreamin' of it.
:-)
We've got to get off this planet
"current conditions notwithstanding" my ass. Current conditions /always/ matter - and setting aside the whole paper vs. experience thing, right nwo the best thing to do is go to college.
It doesn't really matter what you take, just get some fancy papers. When there's a market upswing, *then* you can decide whether to stay in college or to start a career because you'll have that option then. Right now your options are college or a crappy start to a career with little job security.
I'm not saying that there aren't good jobs otu there (I have one myself), but with neither experience nor papers and facing the competition of all those hungry experienced and paper'd unemployed SysAdmins, you'll fare much better 9and eat more regularily) in college.
> A Unix machine without a C compiler? Can you name a few popular systems that have this problem?
...
My OpenBSD firewall. No use locking a system down if a user can build their own tools
I needed to add snort to the firewall and binary packages made that painless.
I never understood why the extra stuff (calendaring and file storage, mostly) was in the *mail client* in the first place.
But then, I never understood using Word as a mail editor either.
Doesn't address failover for incoming traffic. Neither do DNS tricks or other such kludgery: this is a layer 3 problem. The solution is to use IP as it was intended -- true end to end connectivity and routing issues handled by, of all things, routing protocols.
BGP with aggressive route aggregation works well. Something better running on top of IPv6 would go a long ways towards getting rid of the convulated "solutions" that a lot of organizations are setting up.
Blatant karma plug: http://www.nanog.org/ -- anyone interested in these sorts of routing issues should join the mailing list and lurk
You don't have an updated system, you say?
;-)
And you're announcing that fact on *SlashDot*?
Wow.
The whole point is errata, bug fixes and security updates. Upgrades come every months in the form of a new version of RedHat (says the guy running 7.1 instead of 7.2. Heh.)
Are there any plans for an official RedHat 7.1 KDE RPM set? I'm currently running with the Red Hat Inc. KDE 2.2 set, and I'd rather not completely upgrade to 7.2 (I've done spot-updates of some of the system).
If not, what dependencies would have to be fulfilled to run the 7.2 RPMS on a 7.1 system?