> How exactly do you buy a larger house on a smaller salary?
Buy it where real-estate values are lower. This is pretty basic. The cost of living difference between Galion, where I live, and Columbus, one hour to the south, is at least an order of magnitude overall, and the difference is larger for real estate than some other things. (New cars, for instance, are basically the same cost here as there.)
> You lose the conveniences and diversity of a big city.
Diversity I'll give you, but convenience? If there's anything less convenient than living in a big city, I'm sure I don't know what it is.
And yeah, being asked to relocate by your employer is a bummer, but it's not a _new_ bummer; employers have been asking employees to relocate for decades; it's just that previously they mostly moved people *toward* the bigger cities.
Write your own mail server software, preferably in an unpleasantly horrible language, such as Threaded Intercal. Make sure it keeps all the mail and account information in something inherntly tied to the implementation language, such as stored procedures, disk-based monads, persistent lexical closures, or the like.
Did I mention the part about not supporting POP3 or IMAP, but rolling your own protocol and client? You wouldn't want some hotshot hiree coming along, extracting all the mail that easily, and moving the company over to Exim or Postfix.
Oh, and you want there to be a lot of resistence to moving away from your solution, so make it do something executives will like, such as have the server authenticate clients by MAC address so they don't have to have passwords.
Also, just to raise the bar for potential replacement systems, roll in some features that have nothing whatsoever to do with mail. For instance, you could tie the mail server into the company accounting system and put user interface in the client for viewing up-to-the-minute charts showing revenues, remaining fund levels in various funds, and so forth. Arrange it so that users can send each other these charts (actually just magic tokens that pull them up) by email.
> "Perl is not a niche community! We just publish most of our projects at our > own special place with features that cater to our own special needs."
Well, only (most of) the open-source ones, obviously. But the CPAN is a fairly large network. The list of mirrors is about 145K. Describing the CPAN as "our own special place" is about like describing the Atlantic Ocean as "the pond out back".
> The FBI might be willing to wade through the volume at the Google level.
No, you don't get it: they don't have anything like the resources for that. The sheer volume is totally overwhelming. Google sees more traffic in an hour than the FBI has the resources to "wade through", as you put it, in a decade, much less in real time.
Like I said, if they could narrow it down to a very tiny percentage of the traffic (say, all the packets to or from a certain narrow IP address range, or more likely all the accounts known to be connected to a certain individual who is under investigation), then it becomes feasible -- to stake out individual people. But blanket-monitoring everybody is completely out of the question. It's not a question of motivation (you *know* they've thought about it); it's a question of magnitude and finite resources. The job is entirely too enormous.
> Your point is that NT 3.51 was alpha quality in itself? ; )
Well, that's a decent first-order approximation of my point.
My exact point was more to the effect that it was an NT 3.51 box, not really a server in any meaningful, production-oriented sense of the word "server", but actually the way you say it is less verbose and more to the point. In fact, I think I like the way you put it better.
> Correct me if I'm wrong, but IM services *generally* connect directly > peer-to-peer, unless the user is not online in which case messages may > be queued up (ICQ, Yahoo IM) for when the user comes back online. > Otherwise, if the user is online, the TCP packet is sent directly to > the user's system.
Not sure. Maybe.
> With Email, you have numerous connections, the overhead of speaking > both SMTP and POP3 protocols to store/send and retrieve Email, and > each message hops from one server to the other and waits for the user's > client software to retrieve the message. How exactly does that speed > things up?
I haven't looked under the hood of IM, so I'm guessing, but my first off-the-cuff suspicion is that while email protocols like SMTP and POP3 are old, lightweight, well-understood, and on the whole decently implemented, the IM protocols may not be those things. My second guess is that all the extra _stuff_ IM clients do (constantly checking the generally-very-overtaxed server to see if various people are online or not, among other things) slows them down. Frankly, just having an IM client running on the system can significantly slow down web browsing; on diaup, this can be VERY noticeable. Getting your mail doesn't do that. When email was designed, 300 baud was considered reasonable, and the design of the system reflects that. There are probably a *lot* fewer packets. With either POP3 or SMTP, *most* of the bytes that are echanged are part of the actual message (err, counting the headers). I am pretty sure that a typical IM client uses several K per second even when no messages are being exchanged. What exactly it's doing with all that bandwidth, I don't precisely know.
And maybe on broadband it's no big deal. But it sure is slow on dialup.
> Come over to me, get immediate response; Use IM, get a response in less > than an hour; Use email, get a response in half-a-day, or a day; Give me > a paper: I respond within a week.
Mine's more like this: Walk over to where I am, get an immediate response. Send email with a clear subject line, so it gets sorted right, get a response within a day. Give me paper, I add it to the stack on my desk, which I go through when I run out of other things to do (usually round about June). And if you try to send me IM, there's no telling _when_ or even _if_ I'll ever get it.
> Is there an awareness campaign dedicated to teaching webmasters about > accessability?
Several of them, but the only webmasters who pay any attention are the same ones who also care about making the site work in different browsers, at different screen resolutions, with Javascript turned off, and so forth -- in other words, the 10% (or so) of the web that is actually well-designed.
Re:Okay, I know I'm going to feel like an idiot, b
on
Defeating Captcha
·
· Score: 1
> Is "Belgium" just a funny word?
Well, say it a few times. Does it _sound_ funny? Think about whether it sounds funny, while you're saing it, repeatedly. *Now* does it sound funny?
(This trick works with most words, BTW.)
Actually, the real issue with the word "Belgium" is that Douglas Adams wrote things about it that could be interpreted as disparaging, so all real geeks have to think it's a bit off, or they lose their geek card.
> Exactly! Google will now have a reocrd of: 1. Your web searches 2. Your > email 3. You im conversations If google were the government would you be > afraid?
Frankly? No.
Do you have any idea how *many* users there are, and how *much* the volume of web searches, email, usenet (you forgot that one), and IM conversations adds up to? The very idea of monitoring it all is, frankly, utterly preposterous. The sheer amount of material is prohibitive.
Now, if you were someone they have a specific interest in monitoring (say, a suspect in a major FBI case), then that would be another matter. But, frankly, in that case they could just bug your house, plant a couple of cameras, and have done; they wouldn't need to tap in to your communication at the Google level.
> I don't see how email could beat IM for speed of quick conversations
By having shorter delivery times.
> Most email clients separate each message, making you click or take some > action to view a new message
Yeah, but there are keyboard shortcuts.
> Email clients also have no support for multiple concurent conversations
Now you're smoking crack. It is email clients (and also usenet clients) that support proper threading; IM has no decent UI for this at all. At best IM clients offer separate tabs, like you describe, so that to even see if you've got a reply in the other conversations you have to go over to the other tab. Threading is a vastly better way to handle this, and email clients have had threading since the seventies.
> (By "email clients" I mean things like pine, elm, mutt, evolution, > outlook, eudora, sylpheed, gnustep mail.app, balsa, kmail, and probably > more clients I have used, and I think they all suck for reasons I won't > bore you with at the moment.)
Most of those do suck pretty bad, yes. Eudora is the only vaguely decent one you list, and I've always hated it. Try Pegasus Mail. For handling serious *bulk* mail, Gnus is better than Pegasus, but Gnus is no good for instant back-and-forth; whereas, Pegasus handles that like a champ, assuming the mail service is decent. (Don't try instant back-and-forth conversations with a super-cheap POP3 service a la Yahoo mail's, though. Ugh.) Granted, I have not tried this in a recent version of Pegasus (I think version 3.1 was new when I switched away from Windows...), but I suspect it should still work. Pegasus also has pretty decent new-mail notification options.
It will not, however, do things like track other users' online state, or automatically open the message when it arrives.
> I'd very much like to see an email client that doesn't suck, and see no > reason why that can't also be an IM client with both email and IM using > only a single protocol.
In fact, if the IM service would just use your email address as your ID for the service, instead of making up some number or handle, the user interface could smooth over protocol differences.
> I think it has more to do with bad scripting practises.
Agreed. There are several steps in that chain where scripts are blindly executing a command line with some variable interpolated blindly, without bothering to do any sanity checks on the values. That would be bad enough with commands that do things like make copies, but that sort of carelessness with recursive deletion is just plain dumb.
> This problem could have been avoided by adding two dashes to the command: > rm -f -- *
I hope you realize this is just treating one symptom. It's the general carelessness and lack of sanity checks that is the real problem.
> I hold one of those much admired positions within my small workplace, > that of the "guy know knows what a computer is". As a result I look after > our server, all the desktops, database application, etc, etc
That pretty well describes my job. I like to use the initials TCG to describe my job position. It stand for "The Computer Guy". Everything from unsticking printers to database administration, from hardware purchase decisions to cgi authoring, from desktop publishing to setting up a backup-tape rotation, that's my job. I wanted "The Computer Guy" on my business cards, but they insisted on printing something inane like "Technology Coordinator" on there. (Worse, the card says "E-mail:" next to my email address... makes me look like some kind of clue-impaired suit or something. I try to avoid giving them out.)
> Gmail is almost IM.. With the threading of the messages and the speed of > it, I've had very rapid conversations going back and forth.
IM has never been about having rapid conversations back and forth. email, assuming you have a decent mail service, has always been capable of more rapid back-and-forth conversations than most current IM services can manage on a good day. We did this all the time when I was in college, using Pegasus Mail (still one of the best clients available) over a campus-wide Novell network. (There was a connection to the rest of the world too, for off-campus mail.)
And there has also always been IRC, since before IM was ever devised.
What is IM, then? What makes IM what it is? IM is about various kinds of notification: tracking the other user's online-ness (or not), hearing a sound when someone comes online, being interrupted (with a window popping to the front and stealing focus from whatever you were in the process of doing) whenever you receive a message, that sort of thing. These are features POP3 and SMTP don't really support (though they could have been extended to support it, but that's another matter).
> It seems it would be best for MS to just try to make their software > better and spend a small fraction on FUD to work against Linux than > to make their own Linux that they would have to sell for less than > MS Windows and could also possibly cost them sales of other products.
It's entirely possible they've already started developing MS Linux (or just picked an extant distro that they would standardize on if it came to that) as a contingency, but are keeping it tightly bottled up in-house, with only a small group of developers and execs knowing about it; presumably they have already begun porting over the major cash-cow apps to it (e.g., Office, SQL Server) and are carefully retaining compatibility.
They would only ever *release* any of this if revenues from Windows tank to the point where there's more to gain from selling Office for Linux than there is from selling Windows, which will certainly not happen in the next couple of years, possibly never (hard to predict, the future is: Windows and Linux might both be so much bathwater in fifteen years). But they'd be dumb not to explore the possibility as a contingency plan.
We know they have a Linux lab, where they do all kinds of experimenting, as well as compatibility work. That's what they publically admit. Read between the lines, and it's *very* likely that the compatibility work includes a certain amount of thinking along the lines of "What would it take to run Office on this, in the event we should ever decide we wanted for any reason to do that?" You know they've at least analyzed what it would take to make that happen; they *may* have already started doing it, or preparing to do it. In secret, of course.
Apple successfully kept Mac OS X86 pretty much under wraps like that for 5+ years, until they decided to go with it. Sure, there were rumors and speculation, but there are *always* rumors and speculation; nobody outside of Apple really *knew* about this until Apple started getting ready to release it.
> Most clusters have a PSU per one or two processors, shouldn't fewer, > larger supplies actually be more efficient?
Maybe, but which would you rather have, more efficient, or more robust? Bear in mind that this is a cluster, so while performance and efficiency scale linearly, the mean time between failures is inversely geometrically proportional to the number of nodes, unless there is some kind of protective redundancy built into the clustering method, in which case, efficiency goes out the window anyway.
> Often lower end power supplies don't correct for the power factor when > rating the power of the supply so you won't actually get the rated power.
Umm, power factor correction doesn't have anything to do with what power the thing supplies to the load. It has to do with what it does (or doesn't do, really) to the mains in the process. A regular uncorrected supply draws its power out of sync with the incoming power curve, so it screws up the circuit, makes the power company's equipment work harder, and messes up the sine wave for other things on the circuit, but it can still deliver the power it's rated to deliver, or if it can't, lack of power correction isn't the reason.
Yeah, I use that for the servers (yes, we have Windows servers; no, it was not my decision; it was the application vendor's decision; no, I could not, realistically, have just chosen to go with another app vendor), to avoid the need to crawl back into the network closet where they're located and set up a monitor.
For the workstations, I generally just go to them; walking about is pretty much the only exercise I get; otherwise I'd be completely sedentary -- oh, and it's not a very large building anyway. Also, going to the workstation allows me to ask questions of the user more easily, if need be.
Slashdot Mirror
> How exactly do you buy a larger house on a smaller salary?
Buy it where real-estate values are lower. This is pretty basic. The cost of living difference between Galion, where I live, and Columbus, one hour to the south, is at least an order of magnitude overall, and the difference is larger for real estate than some other things. (New cars, for instance, are basically the same cost here as there.)
> You lose the conveniences and diversity of a big city.
Diversity I'll give you, but convenience? If there's anything less convenient than living in a big city, I'm sure I don't know what it is.
And yeah, being asked to relocate by your employer is a bummer, but it's not a _new_ bummer; employers have been asking employees to relocate for decades; it's just that previously they mostly moved people *toward* the bigger cities.
Hey, you want job security, right?
Write your own mail server software, preferably in an unpleasantly horrible language, such as Threaded Intercal. Make sure it keeps all the mail and account information in something inherntly tied to the implementation language, such as stored procedures, disk-based monads, persistent lexical closures, or the like.
Did I mention the part about not supporting POP3 or IMAP, but rolling your own protocol and client? You wouldn't want some hotshot hiree coming along, extracting all the mail that easily, and moving the company over to Exim or Postfix.
Oh, and you want there to be a lot of resistence to moving away from your solution, so make it do something executives will like, such as have the server authenticate clients by MAC address so they don't have to have passwords.
Also, just to raise the bar for potential replacement systems, roll in some features that have nothing whatsoever to do with mail. For instance, you could tie the mail server into the company accounting system and put user interface in the client for viewing up-to-the-minute charts showing revenues, remaining fund levels in various funds, and so forth. Arrange it so that users can send each other these charts (actually just magic tokens that pull them up) by email.
> The question which determines whether CPAN is a niche community is
> not whether it is *small*, but whether it is *special*.
Oh, so what you've been saying all along is that Perl is *special*. Right.
> "Perl is not a niche community! We just publish most of our projects at our
> own special place with features that cater to our own special needs."
Well, only (most of) the open-source ones, obviously. But the CPAN is a fairly large network. The list of mirrors is about 145K. Describing the CPAN as "our own special place" is about like describing the Atlantic Ocean as "the pond out back".
> The FBI might be willing to wade through the volume at the Google level.
No, you don't get it: they don't have anything like the resources for that. The sheer volume is totally overwhelming. Google sees more traffic in an hour than the FBI has the resources to "wade through", as you put it, in a decade, much less in real time.
Like I said, if they could narrow it down to a very tiny percentage of the traffic (say, all the packets to or from a certain narrow IP address range, or more likely all the accounts known to be connected to a certain individual who is under investigation), then it becomes feasible -- to stake out individual people. But blanket-monitoring everybody is completely out of the question. It's not a question of motivation (you *know* they've thought about it); it's a question of magnitude and finite resources. The job is entirely too enormous.
> Your point is that NT 3.51 was alpha quality in itself? ; )
Well, that's a decent first-order approximation of my point.
My exact point was more to the effect that it was an NT 3.51 box, not really a server in any meaningful, production-oriented sense of the word "server", but actually the way you say it is less verbose and more to the point. In fact, I think I like the way you put it better.
> Correct me if I'm wrong, but IM services *generally* connect directly
> peer-to-peer, unless the user is not online in which case messages may
> be queued up (ICQ, Yahoo IM) for when the user comes back online.
> Otherwise, if the user is online, the TCP packet is sent directly to
> the user's system.
Not sure. Maybe.
> With Email, you have numerous connections, the overhead of speaking
> both SMTP and POP3 protocols to store/send and retrieve Email, and
> each message hops from one server to the other and waits for the user's
> client software to retrieve the message. How exactly does that speed
> things up?
I haven't looked under the hood of IM, so I'm guessing, but my first
off-the-cuff suspicion is that while email protocols like SMTP and POP3
are old, lightweight, well-understood, and on the whole decently
implemented, the IM protocols may not be those things. My second guess
is that all the extra _stuff_ IM clients do (constantly checking the
generally-very-overtaxed server to see if various people are online or
not, among other things) slows them down. Frankly, just having an IM
client running on the system can significantly slow down web browsing;
on diaup, this can be VERY noticeable. Getting your mail doesn't do
that. When email was designed, 300 baud was considered reasonable,
and the design of the system reflects that. There are probably a *lot*
fewer packets. With either POP3 or SMTP, *most* of the bytes that are
echanged are part of the actual message (err, counting the headers).
I am pretty sure that a typical IM client uses several K per second
even when no messages are being exchanged. What exactly it's doing
with all that bandwidth, I don't precisely know.
And maybe on broadband it's no big deal. But it sure is slow on dialup.
> Come over to me, get immediate response; Use IM, get a response in less
> than an hour; Use email, get a response in half-a-day, or a day; Give me
> a paper: I respond within a week.
Mine's more like this: Walk over to where I am, get an immediate response. Send email with a clear subject line, so it gets sorted right, get a response within a day. Give me paper, I add it to the stack on my desk, which I go through when I run out of other things to do (usually round about June). And if you try to send me IM, there's no telling _when_ or even _if_ I'll ever get it.
> Putting conspiracy theories aside, what does MS have to gain by switching
> to Linux?
Currently? Nothing.
> Is there an awareness campaign dedicated to teaching webmasters about
> accessability?
Several of them, but the only webmasters who pay any attention are the same ones who also care about making the site work in different browsers, at different screen resolutions, with Javascript turned off, and so forth -- in other words, the 10% (or so) of the web that is actually well-designed.
> Is "Belgium" just a funny word?
Well, say it a few times. Does it _sound_ funny? Think about whether it sounds funny, while you're saing it, repeatedly. *Now* does it sound funny?
(This trick works with most words, BTW.)
Actually, the real issue with the word "Belgium" is that Douglas Adams wrote things about it that could be interpreted as disparaging, so all real geeks have to think it's a bit off, or they lose their geek card.
> The Chinese government scares the hell out of me and I'm hoping
> for a revolution of some sort
They already had that. This is what they ended up with.
> Exactly! Google will now have a reocrd of: 1. Your web searches 2. Your
> email 3. You im conversations If google were the government would you be
> afraid?
Frankly? No.
Do you have any idea how *many* users there are, and how *much* the volume of web searches, email, usenet (you forgot that one), and IM conversations adds up to? The very idea of monitoring it all is, frankly, utterly preposterous. The sheer amount of material is prohibitive.
Now, if you were someone they have a specific interest in monitoring (say, a suspect in a major FBI case), then that would be another matter. But, frankly, in that case they could just bug your house, plant a couple of cameras, and have done; they wouldn't need to tap in to your communication at the Google level.
> I don't see how email could beat IM for speed of quick conversations
By having shorter delivery times.
> Most email clients separate each message, making you click or take some
> action to view a new message
Yeah, but there are keyboard shortcuts.
> Email clients also have no support for multiple concurent conversations
Now you're smoking crack. It is email clients (and also usenet clients) that support proper threading; IM has no decent UI for this at all. At best IM clients offer separate tabs, like you describe, so that to even see if you've got a reply in the other conversations you have to go over to the other tab. Threading is a vastly better way to handle this, and email clients have had threading since the seventies.
> (By "email clients" I mean things like pine, elm, mutt, evolution,
> outlook, eudora, sylpheed, gnustep mail.app, balsa, kmail, and probably
> more clients I have used, and I think they all suck for reasons I won't
> bore you with at the moment.)
Most of those do suck pretty bad, yes. Eudora is the only vaguely decent one you list, and I've always hated it. Try Pegasus Mail. For handling serious *bulk* mail, Gnus is better than Pegasus, but Gnus is no good for instant back-and-forth; whereas, Pegasus handles that like a champ, assuming the mail service is decent. (Don't try instant back-and-forth conversations with a super-cheap POP3 service a la Yahoo mail's, though. Ugh.) Granted, I have not tried this in a recent version of Pegasus (I think version 3.1 was new when I switched away from Windows...), but I suspect it should still work. Pegasus also has pretty decent new-mail notification options.
It will not, however, do things like track other users' online state, or automatically open the message when it arrives.
> I'd very much like to see an email client that doesn't suck, and see no
> reason why that can't also be an IM client with both email and IM using
> only a single protocol.
In fact, if the IM service would just use your email address as your ID for the service, instead of making up some number or handle, the user interface could smooth over protocol differences.
> Then maybe I'm missing the part where IM stands explicity for
> Instant Messenging
A lot of things are misnamed. Welcome to the world of natural language.
> I think it has more to do with bad scripting practises.
Agreed. There are several steps in that chain where scripts are blindly executing a command line with some variable interpolated blindly, without bothering to do any sanity checks on the values. That would be bad enough with commands that do things like make copies, but that sort of carelessness with recursive deletion is just plain dumb.
> This problem could have been avoided by adding two dashes to the command:
> rm -f -- *
I hope you realize this is just treating one symptom. It's the general carelessness and lack of sanity checks that is the real problem.
> I hold one of those much admired positions within my small workplace,
> that of the "guy know knows what a computer is". As a result I look after
> our server, all the desktops, database application, etc, etc
That pretty well describes my job. I like to use the initials TCG to describe my job position. It stand for "The Computer Guy". Everything from unsticking printers to database administration, from hardware purchase decisions to cgi authoring, from desktop publishing to setting up a backup-tape rotation, that's my job. I wanted "The Computer Guy" on my business cards, but they insisted on printing something inane like "Technology Coordinator" on there. (Worse, the card says "E-mail:" next to my email address... makes me look like some kind of clue-impaired suit or something. I try to avoid giving them out.)
> What are you doing installing what you beleive to be an alpha quality
> driver on a server?
Dude, read the post again. It was an NT 3.51 box.
> Gmail is almost IM .. With the threading of the messages and the speed of
> it, I've had very rapid conversations going back and forth.
IM has never been about having rapid conversations back and forth. email, assuming you have a decent mail service, has always been capable of more rapid back-and-forth conversations than most current IM services can manage on a good day. We did this all the time when I was in college, using Pegasus Mail (still one of the best clients available) over a campus-wide Novell network. (There was a connection to the rest of the world too, for off-campus mail.)
And there has also always been IRC, since before IM was ever devised.
What is IM, then? What makes IM what it is? IM is about various kinds of notification: tracking the other user's online-ness (or not), hearing a sound when someone comes online, being interrupted (with a window popping to the front and stealing focus from whatever you were in the process of doing) whenever you receive a message, that sort of thing. These are features POP3 and SMTP don't really support (though they could have been extended to support it, but that's another matter).
> It seems it would be best for MS to just try to make their software
> better and spend a small fraction on FUD to work against Linux than
> to make their own Linux that they would have to sell for less than
> MS Windows and could also possibly cost them sales of other products.
It's entirely possible they've already started developing MS Linux (or just picked an extant distro that they would standardize on if it came to that) as a contingency, but are keeping it tightly bottled up in-house, with only a small group of developers and execs knowing about it; presumably they have already begun porting over the major cash-cow apps to it (e.g., Office, SQL Server) and are carefully retaining compatibility.
They would only ever *release* any of this if revenues from Windows tank to the point where there's more to gain from selling Office for Linux than there is from selling Windows, which will certainly not happen in the next couple of years, possibly never (hard to predict, the future is: Windows and Linux might both be so much bathwater in fifteen years). But they'd be dumb not to explore the possibility as a contingency plan.
We know they have a Linux lab, where they do all kinds of experimenting, as well as compatibility work. That's what they publically admit. Read between the lines, and it's *very* likely that the compatibility work includes a certain amount of thinking along the lines of "What would it take to run Office on this, in the event we should ever decide we wanted for any reason to do that?" You know they've at least analyzed what it would take to make that happen; they *may* have already started doing it, or preparing to do it. In secret, of course.
Apple successfully kept Mac OS X86 pretty much under wraps like that for 5+ years, until they decided to go with it. Sure, there were rumors and speculation, but there are *always* rumors and speculation; nobody outside of Apple really *knew* about this until Apple started getting ready to release it.
> 300 employees @ $130,000 per employee = $39,000,000
> That's a little more than "nearly 10M dollars". Just saying.
To a first approximation, that's the same amount on Microsoft's budget.
> Most clusters have a PSU per one or two processors, shouldn't fewer,
> larger supplies actually be more efficient?
Maybe, but which would you rather have, more efficient, or more robust? Bear in mind that this is a cluster, so while performance and efficiency scale linearly, the mean time between failures is inversely geometrically proportional to the number of nodes, unless there is some kind of protective redundancy built into the clustering method, in which case, efficiency goes out the window anyway.
> Often lower end power supplies don't correct for the power factor when
> rating the power of the supply so you won't actually get the rated power.
Umm, power factor correction doesn't have anything to do with what power the thing supplies to the load. It has to do with what it does (or doesn't do, really) to the mains in the process. A regular uncorrected supply draws its power out of sync with the incoming power curve, so it screws up the circuit, makes the power company's equipment work harder, and messes up the sine wave for other things on the circuit, but it can still deliver the power it's rated to deliver, or if it can't, lack of power correction isn't the reason.
> The tool I use the most for this is "rdesktop".
Yeah, I use that for the servers (yes, we have Windows servers; no, it was
not my decision; it was the application vendor's decision; no, I could not,
realistically, have just chosen to go with another app vendor), to avoid
the need to crawl back into the network closet where they're located and
set up a monitor.
For the workstations, I generally just go to them; walking about is pretty
much the only exercise I get; otherwise I'd be completely sedentary -- oh,
and it's not a very large building anyway. Also, going to the workstation
allows me to ask questions of the user more easily, if need be.
> Much of California drives right next to cliffs every day.
> Some of them die from it.
Umm, Don't Do That Then.