So probably only a few thousands of people will lose their eyes while this fact is tested and learned (i.e., by the criminal class)? Doesn't sound like a worthwhile tradeoff to me...
I ask you, why has there not been a single American civilian death on our own soil since 9/11?
A very good question. Perhaps because that is not their goal. Rather, perhaps their end is best served by drawing us into a war on their territory, a war we cannot possibly win, and in which we will likely, unintentionally, kill a great many bystanders, thus furthering their cause.
Instead of assuming they're crazy, you can also try assuming that they're shrewd, subtle, and wiping the floor with us in a game we don't even understand.
I beg to disagree. Computer scientists (i.e., skilled computer programmers, etc.) and biologists both have substantial domain knowledge that they're bringing to the table. A practitioner from either camp that fails to make use of the skills of a partner from the other is likely to leave a trail of serious messes in their wake. I see this a lot, and I think it really slows science down.
An alternative benchmark to consider: With old-fashioned direct attached SCSI, you can pretty much only screw up the disks one host at a time. With FC (and iSCSI I suppose), you can completely fuck up your hundred-million-dollar site with one mouse click. Now that's power!
To answer your question, it all depends. If your admin is good, not a misanthrope, and is basically interested in seeing the website succeed, you don't really need root. If not, you're probably going to fail anyway, as, even if you have the root password, he has more power to make you fail than you have to succeed.
Almost every job I've ever had has featured at least one technically incompetent, obstructive co-worker. You can try to point this out to the higher ups, but your main options are to deal with the person via diplomacy or to find a new job.
I once suffered, without root, under an admin who gave everyone the same home directory path, where the actual directory on each machine was owned by the user on whose desk the machine sat. So, if I logged into joe's machine, I'd be running his.login/etc rather than mine. (The admin claimed that this scheme simplified backups.) There were lots of other problems of a similar scale with this project, and no one with both technical skill and power to correct them. In a case like this, all you can really do is leave.
If you're new, I'd give it at least six months. You may not even have figured out yet who the true problem people are on your job. Maybe this admin will turn out to be your best friend or mentor (or vice versa).
My advice would be to consider that you're starting the project from scratch. The dumpster full of stuff you inherited from the previous project can (and probably should) be mined for requirements and possible implementation ideas, but as a working base for further development, it's worse than worthless. Certainly not something you'd want to put into CVS.
Management types usually seem to think that source code per se is a precious commodity. You read hysterical quotes in the trade rags all the time about the dire effect of source code being stolen, etc. Serious practitioners know that source code by itself is virtually worthless--you need access to, and the good will of, the people that designed and implemented it. That's what's precious.
(Aside from being stupid and evil, software patents are pointless for this very reason. Even source code copyright is barely worthwhile.)
Another note: If you're wanting to become a consultant because the idea of someone else making money off of your labor burns you, I think that's a bad reason. What matters is how much you are getting paid for a certain amount of your labor. (Since I'm not a good salesman, I discovered I could make a lot more money at a salaried job myself.)
So, you're saying that I can now enjoy the speed of an interpreted language and the beautiful lyric clarity of C++, both at the same time? Be still my heart!
(Yeah, I know, there are a few good uses for a C++ interpreter. Not many, though.)
Here's an obligatory link to Matrioshka Brains (a conceivable explanation for dark matter). If you haven't already seen this, you'll probably find it interesting.
Let me program how I want as opposed to enforcing some arbitrary pet style of your own.
The wisdom of a converged, aesthetic style is probably more obvious after one has (a) tried it for a few months, and (b) maintained code written "how I want" for a few years.
This problem has a trivial solution, based on the fact that users generally don't want to receive text messages from unknown strangers. Providers can just allow users to choose a password, and then drop all messages that don't include the password somewhere in the text. This stops the problem in its tracks. (Some kind of whitelisting could be added to allow traffic from services, or alternatively, the services could also arrange to send a password.)
I use emacs, so moving blocks around with proper indentation is quite trivial. Even if I had to edit with Notepad, though, it'd be a small price to pay for the readability.
Like probably most people, I hated Python's blocking-by-indentation syntax for the first few weeks. The column restrictions kind of reminded me of FORTRAN.
But after the adjustment, I've truly grown to love its spartan clarity and simplicity. I can hardly stand to look at the redundant brace-littered syntax of Java, C or Perl now.
---Perl 5 is already conceptually too large to use.
--Then how on earth did I ever manage to use it?
I'm not asserting that it's impossible to write programs in Perl. That would be silly, of course.
The question I'm talking about is the relative difficulty of writing well-engineered software in some problem space--i.e., relative to the other languages available.
(I programmed in Perl for a number of years, and I think it was a great step forward in its day and that we owe Larry Wall a great debt. But, I also think Perl's day is (and should be) done, unless a great deal of accreted junk can be jettisoned.) My opinion, of course.
I agree that debugging with a good debugger in a language like Lisp or Prolog is a lot easier than with a language like C or C++, but my thinking is mostly orthogonal to that question. I've done a fair amount of Lisp programming in the past and I mostly use Python (which you might call "Lisp in drag") these days. I find, though, that even though Python has a nice debugger, I hardly ever need to use it. For the few errors I encounter, a handful of print statements does the job just fine.
Probably the place where debuggers are most useful to me lately is when I have to track down bug in a huge blob of poorly written, undocumented code. This is really a reverse-engineering task, and for sufficiently inscrutable code, a debugger can be a (relatively) efficient way to go.
I agree--regression tests are a great method to help avoid debugging. Not so useful once you have a bug report, but very useful to avoid getting them in the first place.
Mike
The best programmer I've met once told me that once you've dropped into the debugger, you've lost, which over time I've found to be quite true. The best debugging practice is to learn how not to use a debugger. (e.g., Are you using threads when they're not absolutely required? Say hello to debugging hell...)
When you must debug, print statements cover 97% of the cases perfectly. They allow you to formulate a hypothesis and test it experimentally as efficiently as possible.
Differential debugging is a nifty idea, but most of the time it'd be better to just use it with your print statements as above (e.g., print to logs and then diff them). For the one time per year (or five or ten years?) that having a true differential debugger might pay off, it's probably a loss anyway because of the cost and learning curve of the tool. (I thought about adding this to SUBTERFUGUE, but realized that no one would likely ever productively use this feature.)
If you need another reason to avoid this tool in particular, these guys have a (software) patent on it. Blech!
This is exactly why I didn't buy one (or two or three), even though I'd have been a prime candidate. I don't want to pay a monthly fee, and Tivo screwed the pooch by not selling people like me what they have and we want.
--Mike
Slashdot Mirror
Mike
A very good question. Perhaps because that is not their goal. Rather, perhaps their end is best served by drawing us into a war on their territory, a war we cannot possibly win, and in which we will likely, unintentionally, kill a great many bystanders, thus furthering their cause.
Instead of assuming they're crazy, you can also try assuming that they're shrewd, subtle, and wiping the floor with us in a game we don't even understand.
Mike
That's good, because Giraldo Rivera ain't cutting it.
Mike
(cf. Windows ain't done 'til Lotus won't run...)
Mike
Mike
Almost every job I've ever had has featured at least one technically incompetent, obstructive co-worker. You can try to point this out to the higher ups, but your main options are to deal with the person via diplomacy or to find a new job.
I once suffered, without root, under an admin who gave everyone the same home directory path, where the actual directory on each machine was owned by the user on whose desk the machine sat. So, if I logged into joe's machine, I'd be running his .login/etc rather than mine. (The admin claimed that this scheme simplified backups.) There were lots of other problems of a similar scale with this project, and no one with both technical skill and power to correct them. In a case like this, all you can really do is leave.
If you're new, I'd give it at least six months. You may not even have figured out yet who the true problem people are on your job. Maybe this admin will turn out to be your best friend or mentor (or vice versa).
Mike
Management types usually seem to think that source code per se is a precious commodity. You read hysterical quotes in the trade rags all the time about the dire effect of source code being stolen, etc. Serious practitioners know that source code by itself is virtually worthless--you need access to, and the good will of, the people that designed and implemented it. That's what's precious.
(Aside from being stupid and evil, software patents are pointless for this very reason. Even source code copyright is barely worthwhile.)
Mike
Mike
Another note: If you're wanting to become a consultant because the idea of someone else making money off of your labor burns you, I think that's a bad reason. What matters is how much you are getting paid for a certain amount of your labor. (Since I'm not a good salesman, I discovered I could make a lot more money at a salaried job myself.)
Mike
(Yeah, I know, there are a few good uses for a C++ interpreter. Not many, though.)
Mike
Mike
The wisdom of a converged, aesthetic style is probably more obvious after one has (a) tried it for a few months, and (b) maintained code written "how I want" for a few years.
Mike
Mike
Mike
But after the adjustment, I've truly grown to love its spartan clarity and simplicity. I can hardly stand to look at the redundant brace-littered syntax of Java, C or Perl now.
Mike
Mike
--Then how on earth did I ever manage to use it?
I'm not asserting that it's impossible to write programs in Perl. That would be silly, of course.
The question I'm talking about is the relative difficulty of writing well-engineered software in some problem space--i.e., relative to the other languages available.
(I programmed in Perl for a number of years, and I think it was a great step forward in its day and that we owe Larry Wall a great debt. But, I also think Perl's day is (and should be) done, unless a great deal of accreted junk can be jettisoned.) My opinion, of course.
Mike
Unfortunately, you still have know these operators in order to READ Perl code written by other programmers.
Perl 5 is already conceptually too large to use. Perl 6 just takes things completely over the top.
Mike
Probably the place where debuggers are most useful to me lately is when I have to track down bug in a huge blob of poorly written, undocumented code. This is really a reverse-engineering task, and for sufficiently inscrutable code, a debugger can be a (relatively) efficient way to go.
Mike
If you just want a stack trace, there's a nifty utility catchsegv that probably already exists on your system. (I only recently discovered it.)
Mike
I agree--regression tests are a great method to help avoid debugging. Not so useful once you have a bug report, but very useful to avoid getting them in the first place.
Mike
- The best programmer I've met once told me that once you've dropped into the debugger, you've lost, which over time I've found to be quite true. The best debugging practice is to learn how not to use a debugger. (e.g., Are you using threads when they're not absolutely required? Say hello to debugging hell...)
- When you must debug, print statements cover 97% of the cases perfectly. They allow you to formulate a hypothesis and test it experimentally as efficiently as possible.
- Differential debugging is a nifty idea, but most of the time it'd be better to just use it with your print statements as above (e.g., print to logs and then diff them). For the one time per year (or five or ten years?) that having a true differential debugger might pay off, it's probably a loss anyway because of the cost and learning curve of the tool. (I thought about adding this to SUBTERFUGUE, but realized that no one would likely ever productively use this feature.)
- If you need another reason to avoid this tool in particular, these guys have a (software) patent on it. Blech!
--MikeThis is exactly why I didn't buy one (or two or three), even though I'd have been a prime candidate. I don't want to pay a monthly fee, and Tivo screwed the pooch by not selling people like me what they have and we want.
--Mike
I thought it you said "down *to* $1.22"
Mike