Comment Re:the cause was bitrot... (Score 1) 156
So it was you who left that on my doorstep this morning!!!
So it was you who left that on my doorstep this morning!!!
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
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
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.
No one could figure out what was wrong with the kid, even as far as making the kid take more of it. The kid died. That's how you accidentally overdose.
[citation needed]
Actually, that's interesting. Who is America's worst historical figure?
James Buchanan
And that will be the end... when we stay home because we prefer a machine. We'll give up on loving our own kind not because it is superior, but just because it is less "work".
How many men in the world will *need* a robot girlfriend, given the skewing of the male/female birth ratios towards boys. Too many men, not enough women...that doesn't bode well for social stability. Perhaps some sex bots can fill the gap...so to speak.
I've never met a Solaris cultist either. I'm counting myself lucky.
That's because they are SunOS cultists!
I meant SMS as in, the end user will see it as simply an SMS. The implementation on the network level of course will be a fair bit different I'm sure.
Even if they did sign up they might be hundreds of miles away where the alert is not relevant.
That isn't necessarily true, as you may have family/friends/property etc in that region as well, all things that alerts could be relevant for as well...
Long story short - why do they want a separate chip, exactly?
Nowhere on the fcc.gov site linked in the story does it say anything about phones requiring any sort of chip. Basically the important part of the system is the secure interface between government and the wireless providers. In short this is more like the EAS system, but for mobile phones. Chances are most network carriers *will* implement this over SMS.
I tell them to turn to the study of mathematics, for it is only there that they might escape the lusts of the flesh. -- Thomas Mann, "The Magic Mountain"