Why wouldn't you just be able to play a video back to it of the subject making the required facial expression?

We do the same with alcohol as well, it's called "denatured" alcohol aka poisoned with methyl alcohol or something equally as toxic. We do it for even a more sinister purpose than abuse control, tax revenue.

I second this..debootstrap is your friend. We don't need no stinking installers! :D

See here's the thing, I don't have problems with ads, per-se, I have problem with ads being served by third parties that also serve ads on thousands of other sites as well and track me from site to site. Serve up your ads from your own servers, under your own domain, then I'll see your ads just fine. But if you expect to show me ads that track me, you can go get bent.

it would be a new age of food healthfulness, it would also be a new age of food blandness.

ranch flavored algea soup or garlic flavored algea soup for lunch today?

FWIW I hope i am long dead and buried before food has to suck that bad.

Soylent Green is people!

So it was you who left that on my doorstep this morning!!! :D

1 hour? Give me a fucking break. Doing it in public is as good as launching the attack yourself.

EFnet was fixed within an hour or two for the most part. More importantly the hub servers were not impacted which helped with getting things working sooner.

The patch could have been discussed behind closed doors. If you wanted to get someones attention about the real threat, you could have popped a single server ONCE without making it public.

Indeed the patch could have been discussed behind closed doors, but sometimes zero day things happen. The real question is how do you deal with it when it happens.

Do you have any idea what its like running a network like EFNet and coordinating upgrades across all servers? Do you think there are admins awake and ready to be your bitch and patch their servers on your command in all time zones? Currently showing 44 servers linked ... Yea, an hour was plenty of time to deal with the issue ...
You're a douche for even saying what you're saying.

I personally fixed 4 or 5 efnet servers directly and got patches out to the efnet admin community pretty quickly. Neonlod also had patches out pretty quickly as well, sooner than I did actually.

TBH I'm surprised that it didn't happen sooner seeing that the bug had been there since 2004. The bug itself was a combination of errors. First was a code change that was supposed to do parameter count checking for the called function, however zero was put in for the parameter count that was required.

This didn't matter for a while though as the rest of the code didn't rely on that parameter count checking code. However when some additional code was added, it wasn't protected by the old code that didn't care about parameter count, but it expected that the new parameter count code was working(which it wasn't) thus a command with an empty parameter caused the core dump. Fail.

I don't see any reason to hide from bugs like this, people make mistake, code suffers from bitrot, etc. It's sure as shit embarrassing when a mistake in your code ends up on /. though.

This is a good case of bitrot here, code that had made assumptions about what the other parts of the code were doing..and fail. Brown paper bag day for me on EFnet :P

Can we get internet speeds in terms of Library of Congresses per second?

It's getting really hard to ignore RIM. Their products are just too damn good.

Mr Balsillie? Is that you?

You have your root filesystem mounted read only and then run xfs_repair on it. Sometimes getting your root filesystem remounted read-only can be tricky, however. Sometimes this requires passing init=/bin/sh to the kernel, so you start with no other processes running. However you go about getting your root filesystem mounted read only, after you run xfs_repair(or e2fsck for that matter really) you reboot immediately.

Stop trying to oversimply things you don't understand.

Perhaps you don't understand things as well as you think you do. See the section below regarding the -d option to xfs_repair and the context in which you'd use it.

-d Repair dangerously. Allow xfs_repair to repair an XFS filesystem mounted read only. This is typically done on a root fileystem from single user mode, immediately followed by a reboot.

Same on a properly configured Linux system, really. If you get to the point where you are running into the Linux out of memory killer, you probably need more memory for what you are trying to do anyways. For a desktop I think the default Linux out of memory killer is okay, but for servers...disable that crap.

You can disable the oom killer on Linux and just panic on oom, if you want it to act more like FreeBSD. There is a sysctl setting called vm.panic_on_oom. Setting sysctl vm.panic_on_oom=2, will cause the kernel to panic on OOM regardless. That will give you a well defined behavior and not have to deal with the random process...errr..OOM killer.