/* This is hairy. We need to compute where the XEmacs binary was invoked
          from because temacs initialization requires it to find the lisp
          directories. The code that recomputes the path is guarded by the
          restarted flag. There are three possible paths I've found so far
          through this:

          temacs -- When running temacs for basic build stuff, the first main_1
            will be the only one invoked. It must compute the path else there
            will be a very ugly bomb in startup.el (can't find obvious location
            for doc-directory data-directory, etc.).

          temacs w/ run-temacs on the command line -- This is run to bytecompile
            all the out of date dumped lisp. It will execute both of the main_1
            calls and the second one must not touch the first computation because
            argc/argv are hosed the second time through.

          xemacs -- Only the second main_1 is executed. The invocation path must
            computed but this only matters when running in place or when running
            as a login shell.

          As a bonus for straightening this out, XEmacs can now be run in place
          as a login shell. This never used to work.

          As another bonus, we can now guarantee that
          (concat invocation-directory invocation-name) contains the filename
          of the XEmacs binary we are running. This can now be used in a
          definite test for out of date dumped files. -slb */

OK. So now everyone knows how Lisp programs written with a core in C initialize themselves, right?

And as much as people may joke about it, XEmacs was tested to ensure that it worked as a login shell prior to release.

I think the worst mistake I made as Mr. XEmacs was attempting to unify our graphics support to call ImageMagick libraries instead of the custom stuff we were using (and later restored when ImageMagick was backed out).

Does it work any better now? The last time I looked at display(1) a couple of years ago, it still wasn't close to long lost and patent challenged xv(1) that got shut down by the GIF patent war.

Terry Farrell.

The only Star Trek cast member I've ever met was James Doohan at a book signing.

But about the old series, the only criteria that women on the cast had to meet was to sleep with Roddenberry (he was married to Nurse Chapel. Uhura, Janice Rand, etc. were mistresses). How did the men get casted?

I did. Color me unimpressed. This isn't the first time that this botnet's servers have had their numbers reduced.

I didn't see any analysis of what is going on server side and that is where all the interesting code is.

Their client/server protocol is self-repairing in that servers can propagate new IP lists of servers to clients. According to the various articles, (some of) the servers have been taken down before.

Apparently nothing is known about what is going on server side.

This botnet puts a high priority on not being detected (according to TFAs).

All that is happening now is a reconfiguration. Lay low, infect new servers, then it's business as usual.

Oh and my threat estimate of this botnet is very high. It's MS Windows only at the moment, of course, but the analysis seems to indicate that with not much additional work, could function in a heterogeneous network.

Not in this case. This botnet apparently can spread other client side malware, but doesn't attempt to infect new servers.

That's a very hard problem and I guess that's good.

New servers can be added manually though. Part of their protocol involves the client receiving updated lists of servers. That's why even though this was first detected in 2007, had the servers attacked repeatedly over the years as in this article, the botnet is still around.

The associated articles only discuss how the client side works. All the fascinating code is on the server side and apparently has not been broken.

True. The loss of 2/3 is a minor setback and one that's happened before. This isn't the Black Knight. Servers can be added to this botnet, while limbs cannot be regrown.

In case it isn't obvious by now, this botnet was done by someone who has some experience in (Soviet) military network programming (C3I). What will happen when (laid off, down on their luck, etc. etc.) US C3I experts turn to the dark side?

Grats, but why did that hypocritical Stallman allow Glibc to keep the G in identical circumstances to the XEmacs situation and demonized us?

They already have. Only a tiny fraction of the player base posts on the forums.

Something like this has already happened, though the genders were reversed. Two people had their characters get "married" in game and ended up sharing account info. After they broke up, she got her revenge by logging into his account and deleting all his stuff and characters, or something like that.

I suppose the moral of the story (besides never sharing account info with anyone) is that even virtual divorce is ugly.

(Edit: That may not have been WoW. I think it may have been a different Japanese-only game)

One green poster has already pointed out that many of the trolls are posting openly in favor of the new system as they don't pay by credit card and don't have a true real name attached to their account any way.

There's a reason why I've never put an armory link to one of my 80s in my /. profile - I want my WoW life completely separate from real life. It's non-negotiable.

Don't have a 6k GS? Don't bother applying. And about those gems and enchants you have ...

Anything on Blizzard forums goes on Google and comes up at the top in search results.

Fixed that for you based on googling my own character's names.

I've been on the internet since before you were born.

Now, get off my lawn.

Yes, we do have an approximate idea of how much a human spirit weighs. The answer is 8e-23 g, or eighty trillionths of a trillionth of a gram.

The weight of a human spirit could be tested in a lab with a sensitive enough scale. Put a dying person on a scale and watch what happens when they die.

I recall reading that someone had actually done this, but that was many years ago and from a dubious source. Has it been tried?

Hawking radiation is a very special occurence of this pair production. Supposedly, close to a black hole, it is possible that when a pair of virtual particles is created, one is eaten up by the black hole before they have a chance to anihilate one another, and the second particle manages to get away.

Actually, I thought Hawking radiation was due to the Heisenberg uncertainty principle making the event horizon fuzzy so that one particle could be created inside the event horizon (and stuck inside the black hole) and the other outside (and free to escape).

What a bunch of self-righteous wankers. There's a reason that anyone with at least half a brain treats Wikipedia as an unreliable source. This is one of them.