Visitors can check out the Forum FAQ by clicking this link. You have to register before you can post: click the REGISTER link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. View our Forum Privacy Policy.
Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!
You are not logged in or you do not have permission to access this page. This could be due to one of several reasons:
You are not logged in. If you are already registered, fill in the form below to log in, or follow the "Sign Up" link to register a new account.
You may not have sufficient privileges to access this page. Are you trying to edit someone else's post, access administrative features or some other privileged system?
If you are trying to post, the administrator may have disabled your account, or it may be awaiting activation.
An update to a product from infosec vendor CrowdStrike is bricking computers running Windows.
The Register has found numerous accounts of Windows 10 PCs crashing, displaying the Blue Screen of Death, then being unable to reboot.
“We're seeing BSOD Org wide that are being caused by csagent.sys, and it's taking down critical services. I'll open a ticket, but this is a big deal,” wrote one user.
Forums report that Crowdstrike has issued an advisory with a URL that includes the text "Tech-Alert-Windows-crashes-related-to-Falcon-Sensor-2024-07-19" – but it's behind a regwall that only customers can access.
An apparent screenshot of that article reads "CrowdStrike is aware of reports of crashes on Windows hosts related to the Falcon Sensor. Symptoms include hosts experiencing a bugcheck\blue screen error related to the Falcon Sensor."
CrowdStrike's engineers are working on the issue.
Falcon Sensor is an agent that CrowdStrike claims "blocks attacks on your systems while capturing and recording activity as it happens to detect threats fast."
Right now, however, the sensor appears to be the threat.
Presumably that table was already enormous from day 1 of the new version going live? And I'm guessing it must have taken a fair few hours for the upgrade to create it.
The table's not missing any indexes is it?
I suppose deleting very old stuff might be one way to improve matters.
Can't remember exactly how long it took, but it was getting on for an hour, I think.
Lots of indexes, but it's simply too big. There's no efficient way of handling it for this use case; things need to be in their own tables.
If you go way back, you can still see the posts that were copied across from the pre-vBulletin forum, down in the low thousands IIRC. No old stuff gets deleted round here
And TBH deleting old stuff wouldn't be any more than a stopgap. Eventually it would grow again and the same problem would reappear. And given the quality of the software, I wouldn't trust it to cope well with things vanishing from underneath it.
And the database's Nodes table has millions of rows in it: a row for every subforum, and a row every thread, and one for every post, and every PM, and loads of other things, all in one table.
Presumably that table was already enormous from day 1 of the new version going live? And I'm guessing it must have taken a fair few hours for the upgrade to create it.
The table's not missing any indexes is it?
I suppose deleting very old stuff might be one way to improve matters.
Is it possible to revert to an earlier version, or is the "upgrade" irrevocable?
No going back - they don't really support the older version any more, and it would involve reverting all the changes made to the DB to shovel everything into the new schema
Switching to Xenforo, there's a conversion script, but it would need some additional work to account for things that are done by plugins (nice URLs, Thanks/Likes, various things I did to make it behave more like the old forum). Not a huge task TBH, and the processes involved are either well-documented or relate to bits that I understand because I wrote them
Not going to happen tomorrow though, unfortunately - there's a bit more to it than just installing the new software and running an import script
The previous iteration was a good collection of html links. The new version is a rubbish implementation of javascript and is borked. It's better to have a simple forum that works reliably than something over complex rubbish that doesn't even allow mod functions to work correctly and reliably.
That's an additional problem - as well as their OOP/ORM fetish, they also jumped on the Javascript-driven web app bandwagon, even though the entire SPA concept is a terrible fit for something like a forum. And they weren't very good at it either
The rather depressing thought is that a replacement will be worse: that's been the case for yonks.
We all hated the previous iteration until we met this one.
The previous iteration was a good collection of html links. The new version is a rubbish implementation of javascript and is borked. It's better to have a simple forum that works reliably than something over complex rubbish that doesn't even allow mod functions to work correctly and reliably.
Having just setup a BBS for my Narrowboat syndicate, I decided to go with phpBBS, not least of which because it had a vBulletin import plugin (the old forum being vB).
Still generated the post even with the 500, but edits don't post if you get the 500.
The fundamental problem is that a good few years ago now, vBulletin's developers learned about "Object Oriented Programming" along with the concept of "Object-Relational Mapping". Enthused by this new knowledge, they embarked on a ground-up rewrite of the perfectly adequate vBulletin forum software.
Now, there are various kinds of thing that can be considered as "objects" in forum software: a thread, a post, a subforum, a private message, a user profile, and so on. Put various instances of these things together, and you get a forum. And if you're in the early days of understanding the benefits of abstraction, you get carried away, and decide that all these things that have the property of being "puttable together" must all, in some deep and meaningful way, be of the same kind. So you create a superclass, which all these things' classes will descend from, and you call this abstract thing that everything is a kind of, a "Node".
And because you don't realise that implementing an Object-Relational Mapping does not, in fact, imply a one-to-one correspondence between classes in the software and tables in the database, you take all those things that used to be in separate database tables - one for subforums, and one for private messages, and one for threads, and one for posts, and others for all the other things - and you put them all in one table, which contains all the Nodes, because they're all a bit different from each other but in a way, you feel they're all the same.
While you are doing this, the business is sold, and the new owners decide that the way to make the product stand out in the market is to add a load of other features (articles, and blogs, and events, and various other things) and guess what? They're all Nodes too!
But then the new owners decide this rewrite is taking too long, and experienced developers are too expensive. So they get rid of the experienced developers, and they tell the ones that are left that time's up, so "Ship it!"
It turns out that many of the forums that use the software are quite small, without many users or many threads or many posts, and they also quite like being able to write articles and start blogs, so a lot of people carry on using the software, even though it's fundamentally flawed by the terrible decision that everything is a Node.
But along comes CUK, with lots of threads, and lots of posts, and lots of private messages.
And when a CUK user goes to look at the forum home page to see what people are talking about, or goes to a thread to see what they're saying about it, the forum software goes to the database and asks for the relevant Nodes.
And the database's Nodes table has millions of rows in it: a row for every subforum, and a row every thread, and one for every post, and every PM, and loads of other things, all in one table.
And the database has to load the entire contents of the table into memory, and hunt through it to find the ten threads to show on the forum page, or the ten posts to show on the thread page. Or if you go to look at your PMs, it has to load the millions of rows into memory to search through them all for the PMs that are addressed to you.
And it has to do this for everything: millions of rows, with the database constantly loading them from disk and scanning back and forth to find the stuff it needs to show you a page.
There's cacheing to make things a bit quicker. But that doesn't help much: every time somebody posts, the cache for that thread gets invalidated and guess what? Yes, millions of rows to search again!
And that's why the forum software sucks
That's why I always say "feck classes" or actually I should say "feck turning everything to a class".
Leave a comment: