If you're that good of a project manager, you should be able to make serious coin inside a corporation, with a lot less personal accountability (i.e. risk).
Suppose HyperGlobalMegaCorp has tens of thousands of servers in hundreds of sites in dozens of countries.
Suppose HyperGlobalMegaCorp has a service contract with EDS in your country.
Suppose a server dies and Server Ops sees an alert in their monitoring software. They're thousands of miles away, so the only thing they can do is to call EDS. The local EDS guy gets a page and shows up to see what's happening. He discovers that a hard drive has died, so he installs a spare.
Now EDS guy needs an admin account to configure that new hard drive. He calls the 800 number, gets a firecall ID, and does his thing. When he's done working with the server, he calls the 800 number and releases the firecall ID.
> When would you ever, EVER, give someone an admin password so they could do something, then > change it later?
Happens all the time on big networks. There's a seperate admin account, you call server ops and describe why you need admin access, they reset the password and tell you what it is. When you're done your task, you call them back and the reset the password again.
re promotion, the easiest way to get a raise/promotion is to change jobs anyway.
Also, take a closer look at the linked article - it's about producing bad documentation that looks good. The whole idea is to fool your boss.
> In my experience, doing a good job (part of which is > documenting what you do) is the closest thing you'll ever get > to job security. If they want to fire you, they'll always find > a way.
Sure, and they'll have a terrible time re-learning a bunch of things. You can't eat schadenfreude, but it's better than nothing.
People have mentioned many documentation tools in this thread. Any or all of these tools would produce excellent documentation if you have the co-operation of all your IT staff.
The best tool in the world won't save you if your people aren't using it.
Writing good documentation is hard work. I've never had a job where I had time to produce good documentation.
Why should I produce good documentation anyway? So it's easier for you to fire me? What's in it for me?
I document the bare minimum and keep the rest in my head. My crib notes are so cryptic they might as well be Swahili to anyone else.
Oh, but the boss is insisting I write some documentation. No problem.
Theoretically you could use the linked article to help you write good documentation, but I've never seen it happen.
If you really want to capture the state of your IT department, you need to lock everyone in a room with a gigantic whiteboard and start diagraming your systems. Get someone to take notes or digicam pictures or something. Encourage questions and heckling.
Edit those notes into something useable and let everyone criticize them. Once everyone is happy, do it again for the next system.
The above takes way too much time, so no-one ever has a complete picture of what/where/why/when.
> On the other hand, if you're going to have people inexperienced with chainsaws, bring some trauma > dessings. Dead serious. I saw a lot of very close calls and chainsaws are a huge cause of post-storm > injuries. Spend some time up-front and really go over chainsaw safety and technique. A lot of the > close calls came because of someone getting a saw stuck and doing crazy things to try to free it.
Don't even touch one of those babies unless you're wearing chainsaw pants.
> 1) Fill out the form correctly > 2) Fill in ALL the checkboxes > 3) Leave it half filled out or completely blank (arguably overlaps with #1 in some cases) > 4) Stab themselves with the pencil
There's no form, just a little ballot with 5 or six names on it, with little party logos. The little boxes you check are white boxes on a black background.
I know people like making fun of Yanks, but we've no shortage of idiots up here.
> In a way, Slashdot is a pioneer in this area. Posts which are > unacceptable to the mainstream are moderated down, effectively > "disappearing" them to most viewers.
> What the preference engine does is to tailor this to the individual > viewer. Thus groupthink can operate at very refined levels. Provided > that there is sufficient clustering of opinions, isolated > communities-of-opinion form.
Golly, that doesn't sound anything like Usenet killfiles 15 years ago.
I use OpenBSD myself, those guys are hardcore "traditionalists". No ACLs for me.
> Linux does have a severe lack of fine grained permissions, but > that's probably for the same reason as the configuration files not > being in XML.
Damn you, inertia! Damn you!!!
> I'm very surprised no-one has risen to the task yet, it would > certainly make Linux head and shoulders above the rest when it comes > to security, and that's uba kudos.
There was a lot of interest in systrace a couple of years ago. It is supposed to provide very fine-grained control. I haven't played with it myself. I dunno if any mainstream distros have picked it up.
But let's say Apache wants to use some of those features. They don't dare use ACLs because that would orpan several *nix flavours, they don't dare use systrace because that would orphan several other flavours.
One of the advantages of *nix is portability. That unfortunately means coding to the lowest common denominator.
Life is complex. Software is hard. Almost every developer/sysadmin decision is an annoying tradeoff.
> Well, I was using it to remount Program Files in my.wine, but that's > besides the point. What happens when I want to use Japaniese, do I > also have to segv because Japaniese isn't Unix?
Probably. There's a lot to hate about Unix. There are many things people would do differently if they were starting from scratch. But now, they're written in stone.
Why don't we revisit this conversation in a couple of years? The heavily entrenched Unix suckiness will still be there, and XML rcfiles will still be pie in the sky.
If you go way back to my original post, I linked a similar discussion in 2001. XML advocates were making your exact same points. Nothing has changed. XML rcfiles are not going to happen until someone stops preaching and starts coding. A lot of coding. A lot of thankless coding, redoing stuff that [mostly|sorta|almost] works, stuff that people already understand.
> If most existing configuration files are already in POSIX standard > then I would expect that the POSIX standard is nothing more than, > place your name at the top of the file, do what you like with the > rest of it.
POSIX is the standard that defines Unix. (Freely readable, registration required) This standard including annoying stuff like the format of crontab, where fields are separated by spaces, TABs not allowed.
The crontab format is retarded and annoying, but at least it's "official Unix standard" retardation. I'm feeling better already.
I feel your pain, but I guess I've just learned to love the bomb.
I hope you can find a better example for XML rcfiles.
awk '/usr/ {print $1}' </etc/fstab
> Why deny people a standards compliant OS for the sake of some crappy > awk grep scripts...
You need a better argument than "XML is standards compliant". The POSIX standard is full of crufty whitespace delimited rcfiles. You can standardize anything, no matter how dumb.
Why don't we put all our rcfiles in ASN.1? That's a standard.
Slashdot Mirror
Hockey officals use video extensively to assist them, not to replace them.
If a goal is disputed, the goal judge watches the video (usually from several angles) and decides if the goal is valid or not.
Sometimes a ref misses a call and the game goes on, but the player is punished after officials had a chance to review the tapes.
Let us know how it turns out :)
If you're that good of a project manager, you should be able to make serious coin inside a corporation, with a lot less personal accountability (i.e. risk).
Derek Smart is a developer, and he's certainly famous in his own way.
> Btw "p2p users are like drug users" would be a misrepresentation of my view.
Yeah, I can stop downloading anytime I want.
Wow, who knew :)
Although I'd probably describe it as an MTA construction kit rather than a drop-in sendmail replacement.
Probably because it would take a lot of work.
You're totally right, dude.
Let me know when you release your Haskell version of Sendmail, and I'll switch over immediately.
I'm not crazy about this setup either, but when in Rome...
Google for "firecall id" and you'll see several organizations talking about it. I think it's a holdover from mainframe culture.
Suppose HyperGlobalMegaCorp has tens of thousands of servers in hundreds of sites in dozens of countries.
Suppose HyperGlobalMegaCorp has a service contract with EDS in your country.
Suppose a server dies and Server Ops sees an alert in their monitoring software. They're thousands of miles away, so the only thing they can do is to call EDS. The local EDS guy gets a page and shows up to see what's happening. He discovers that a hard drive has died, so he installs a spare.
Now EDS guy needs an admin account to configure that new hard drive. He calls the 800 number, gets a firecall ID, and does his thing. When he's done working with the server, he calls the 800 number and releases the firecall ID.
> When would you ever, EVER, give someone an admin password so they could do something, then
> change it later?
Happens all the time on big networks. There's a seperate admin account, you call server ops and describe why you need admin access, they reset the password and tell you what it is. When you're done your task, you call them back and the reset the password again.
Thanks to his copious logging, you just did.
pwned!
re promotion, the easiest way to get a raise/promotion is to change jobs anyway.
Also, take a closer look at the linked article - it's about producing bad documentation that looks good. The whole idea is to fool your boss.
> In my experience, doing a good job (part of which is
> documenting what you do) is the closest thing you'll ever get
> to job security. If they want to fire you, they'll always find
> a way.
Sure, and they'll have a terrible time re-learning a bunch of things. You can't eat schadenfreude, but it's better than nothing.
The best tool in the world won't save you if your people aren't using it.
Why should I produce good documentation anyway? So it's easier for you to fire me? What's in it for me?
I document the bare minimum and keep the rest in my head. My crib notes are so cryptic they might as well be Swahili to anyone else.
Oh, but the boss is insisting I write some documentation. No problem.
Theoretically you could use the linked article to help you write good documentation, but I've never seen it happen.
If you really want to capture the state of your IT department, you need to lock everyone in a room with a gigantic whiteboard and start diagraming your systems. Get someone to take notes or digicam pictures or something. Encourage questions and heckling.
Edit those notes into something useable and let everyone criticize them. Once everyone is happy, do it again for the next system.
The above takes way too much time, so no-one ever has a complete picture of what/where/why/when.
I'm pretty sure these guys will want safety soles :)
> On the other hand, if you're going to have people inexperienced with chainsaws, bring some trauma
> dessings. Dead serious. I saw a lot of very close calls and chainsaws are a huge cause of post-storm
> injuries. Spend some time up-front and really go over chainsaw safety and technique. A lot of the
> close calls came because of someone getting a saw stuck and doing crazy things to try to free it.
Don't even touch one of those babies unless you're wearing chainsaw pants.
Do combats have safety soles?
> 1) Fill out the form correctly
> 2) Fill in ALL the checkboxes
> 3) Leave it half filled out or completely blank (arguably overlaps with #1 in some cases)
> 4) Stab themselves with the pencil
There's no form, just a little ballot with 5 or six names on it, with little party logos. The little boxes you check are white boxes on a black background.
I know people like making fun of Yanks, but we've no shortage of idiots up here.
Slashcode (or any web board that I've seen) still isn't as flexible as an slrn scorefile.
> In a way, Slashdot is a pioneer in this area. Posts which are
> unacceptable to the mainstream are moderated down, effectively
> "disappearing" them to most viewers.
> What the preference engine does is to tailor this to the individual
> viewer. Thus groupthink can operate at very refined levels. Provided
> that there is sufficient clustering of opinions, isolated
> communities-of-opinion form.
Golly, that doesn't sound anything like Usenet killfiles 15 years ago.
re: ACLs
I use OpenBSD myself, those guys are hardcore "traditionalists". No ACLs for me.
> Linux does have a severe lack of fine grained permissions, but
> that's probably for the same reason as the configuration files not
> being in XML.
Damn you, inertia! Damn you!!!
> I'm very surprised no-one has risen to the task yet, it would
> certainly make Linux head and shoulders above the rest when it comes
> to security, and that's uba kudos.
There was a lot of interest in systrace a couple of years ago. It is supposed to provide very fine-grained control. I haven't played with it myself. I dunno if any mainstream distros have picked it up.
But let's say Apache wants to use some of those features. They don't dare use ACLs because that would orpan several *nix flavours, they don't dare use systrace because that would orphan several other flavours.
One of the advantages of *nix is portability. That unfortunately means coding to the lowest common denominator.
Life is complex. Software is hard. Almost every developer/sysadmin decision is an annoying tradeoff.
> Well, I was using it to remount Program Files in my .wine, but that's
> besides the point. What happens when I want to use Japaniese, do I
> also have to segv because Japaniese isn't Unix?
Probably. There's a lot to hate about Unix. There are many things people would do differently if they were starting from scratch. But now, they're written in stone.
Why don't we revisit this conversation in a couple of years? The heavily entrenched Unix suckiness will still be there, and XML rcfiles will still be pie in the sky.
If you go way back to my original post, I linked a similar discussion in 2001. XML advocates were making your exact same points. Nothing has changed. XML rcfiles are not going to happen until someone stops preaching and starts coding. A lot of coding. A lot of thankless coding, redoing stuff that [mostly|sorta|almost] works, stuff that people already understand.
> If most existing configuration files are already in POSIX standard
> then I would expect that the POSIX standard is nothing more than,
> place your name at the top of the file, do what you like with the
> rest of it.
POSIX is the standard that defines Unix. (Freely readable, registration required) This standard including annoying stuff like the format of crontab, where fields are separated by spaces, TABs not allowed.
The crontab format is retarded and annoying, but at least it's "official Unix standard" retardation. I'm feeling better already.
I feel your pain, but I guess I've just learned to love the bomb.
When you start putting spaces in filenames, it isn't unix anymore.
>> You need a better argument than "XML is standards compliant".
>Do I?
Yes, because the existing mess is standard compliant (POSIX). Standards aren't magic pixie dust.
I hope you can find a better example for XML rcfiles.
/etc/fstab
awk '/usr/ {print $1}' <
> Why deny people a standards compliant OS for the sake of some crappy
> awk grep scripts...
You need a better argument than "XML is standards compliant". The POSIX standard is full of crufty whitespace delimited rcfiles. You can standardize anything, no matter how dumb.
Why don't we put all our rcfiles in ASN.1? That's a standard.