r00ty

You don't prevent it. You add exceptions for their Web crawler in robots.txt and pretty much all the current Web crawlers respect that.

No no no. You need to at least let someone post about getting up 2 hours before they went to bed, licking the tar off the road and whatever else it was. THEN you say the last line.

You closed this off for the rest of us to join in!

Kids of t'day.

This was normal back in the days of CS 1.5/1.6. People would play at 640x480 on a monitor that could handle 1280x960 because they could drive 640x480 at like 150+hz.

I would have thought the plastic screwdriver was more likely to be able to adjust variable inductors/capacitors with minimal interference? Using a metal screwdriver you have to adjust, move it away check result since the presence of the screwdriver adjusts the result too.

Yeah, I have a problem too! No, wait. It's because I don't have an X/Twitter/whatever account.

Take control of that line from independence day, with a slight change. "In the words of YOUR generation. UP YOURS!"

Thanks. That explains a lot of what I didn't think was right regarding the almost simultaneous failures.

I don't write kernel code at all for a living. But, I do understand the rationale behind it, and it seems to me this doesn't fit that expectation. Now, it's a lot of hypothetical. But if I were writing this software, any processing of these files would happen in userspace. This would mean that any rejection of bad/badly formatted data, or indeed if it managed to crash the processor it would just be an app crash.

The general rule I've always heard is that you want to keep the minimum required work in the kernel code. So I think processing/rejection should have been happening in userspace (and perhaps even using code written in a higher level language with better memory protections etc) and then a parsed and validated set of data would be passed to the kernel code for actioning.

But, I admit I'm observing from the outside, and it could be nothing like this. But, on the face of it, it does seem to me like they were processing too much in the kernel code.

That's interesting. We use crowdstrike, but I'm not in IT so don't know about the configuration. Is a channel file, somehow similar to AV definitions? That would make sense, and I guess means this was a bug in the crowdstrike code in parsing the file somehow?

I think it's most likely a little of both. It seems like the fact most systems failed at around the same time suggests that this was the default automatic upgrade /deployment option.

So, for sure the default option should have had upgrades staggered within an organisation. But at the same time organisations should have been ensuring they aren't upgrading everything at once.

As it is, the way the upgrade was deployed made the software a single point of failure that completely negated redundancies and in many cases hobbled disaster recovery plans.

I think there's a good argument for bitlocker on laptops.

It's much less of a sell for servers and workstations in what should be secure locations.

Having said that, where I work they just enabled enforced windows hello pin with only numeric pins with minimum 6 digits. Seems like a pretty good way to entirely negate the protection bitlocker provides. But hey ho.

My favourite thing has been watching sky news (UK) operate without graphics, trailers, adverts or autocue. Back to basics.

It might not even be that. A lot of places have many servers (and even more virtual servers) running crowdstrike. Some places also seem to have it on endpoints too.

That's a lot of machines to manually fix.