Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Topics - Arantor
346
Off-topic / IE users are dumb
« on July 29th, 2011, 11:44 PM »
No, that's not just some rhetoric from me about IE users being too dumb to use a better browser.
Apparently a study has been done, as reported in http://www.theregister.co.uk/2011/07/29/aptiquant_iq_survey/ showing that the average IQ of IE users is lower than those of other browsers.
Nao, take note: the Opera users, on average, have the highest IQ!
Apparently a study has been done, as reported in http://www.theregister.co.uk/2011/07/29/aptiquant_iq_survey/ showing that the average IQ of IE users is lower than those of other browsers.
Nao, take note: the Opera users, on average, have the highest IQ!
347
Development blog / Banning, and what I want to do with it
« on July 12th, 2011, 12:56 PM »
While I'm still trying to figure out how to incorporate all the feedback from the package manager changes(!), I thought I'd talk about what I want to do with the ban system. Sorry in advance, this is going to be a bit of a novel: it's a big change, it's probably at least as controversial, and something about it is necessary anyway, so let's dive in.
The ban system as implemented is functional, as in it works but it's not overly elegant, it doesn't support IPv6 and I take the view that it doesn't solve the problem at hand, not one bit.
Let me deal with the IPv6 problem first, before I tackle the other stuff. The current system works on IPv4 addresses, which are x.y.z.a addresses, and whatever you put a ban (on IP address) on, it resolves to a range internally for each of the blocks. So a ban on 1.2.*.* becomes a ban internally on 1.2.0-255.0-255. Structurally, that makes sense, but IPv6 is much larger - instead of 4 blocks in the range of 0-255, you have 16 to contend with, though they're not written in decimal, nor written in the same way, but written as aaaa:bbbb:cccc:dddd:eeee:ffff:0000:1111 and similar.
There is one thing to consider, that addresses are divided in half in IPv6, the first half is for a 'network' and the second half for machines in that network, and it sounds that on the surface you could get away with just barring based on the first half only. Whether that will be successful or practical remains to be seen, but something tells me it's not that practical. It's not even that practical from a technical standpoint because if you're keeping that approach, you're not just comparing 4 values against ranges, but doing it for at least 8 - and you need to handle the high/low values, which is what SMF's and Wedge's system does right now.
I didn't implement IPv6 in Wedge in a way that would make this particular easy to implement for, because I took the view that it was the wrong way to be going about it, that any minor change extending the current direction of implementation to fit either 2x or 4x larger scope was an unnecessary performance headache, as well as a logistical one.
So, I sat back and thought about what I'd really like to be able to use in the ban system, and that lead me to my normal approach of trying to figure out what it is the ban system should be needed for, and what it should be able to do.
What is the ban system for? Primarily it's for getting rid of miscreants, and troublemakers. It isn't really a spam-solving solution, and it's not really for keeping users out that you're not interested in - it's for keeping users out that you don't want, which isn't the same thing.
Now before you start, I'm well aware that users do currently use it for keeping users out that they're not interested in, but on a variety of levels, I'm just not sure how viable that is, but we'll get on that in a minute.
So, dealing with troublemakers. The ban system lets you ban a user by name, email, IP or hostname. So you ban them, they come back under a new name through a proxy. Doesn't solve the problem much. For dealing with trolls and so on, there are better ways of dealing with them instead of slamming the door in their face - the tools used by Annoy User for example, to lock off certain features, plus the warning system that allows you to control whether they can post or whether their posts are moderated.
Of course, none of those things will solve the proxy problem, but the ban system wouldn't anyway. No, the solution is to gently turn up the heat so they don't realise that they're being pushed out, or at least discouraged from posting for whatever reason, and without it being obvious - so that they go and do something somewhere else.
If anything, the face-slam of the door is probably worse, not better, at making them go away - because what happens is that they don't have closure, they're not leaving of (kind of!) their own will, so you get all kinds of hassle as a result.
As for banning on email address, what is the hope of that? If you have miscreants who have their own domain, they can create as many emails as they like, so you just restrict the entire domain - it won't prevent them re-registering, though. So you get the extra account, you ban the entire domain, they try to register a third time and they still register - but this time they're banned and will take the hint. The problem is you've still got more accounts than you wanted in the first place.
Instead, then, how about limiting the email addresses up front? Put in the ability to restrict emails based on domain, either whitelisting or blacklisting certain domains as necessary. I know a number of users that restrict signups from mail.ru because of spam - if the domain is blacklisted, they can't even register (which is better than banning it).
There is, interestingly, a performance consideration here - and one for the better. If you ban based on email, the ban has to be evaluated more frequently than just locking it down at registration/change email time. In fact, that's going to be true of all bans - the more bans you have, the more you have to evaluate, and it has even a per-page consequence. By removing that query, you remove the performance hit, especially on long-term sites that have many bans, most of which aren't needed any longer.
Then we have IP addresses. Hello, darkness, my old friend. Putting aside the considerations of above with IPv6 addresses, the simple fact is that IP bans are really not that effective at keeping out miscreants because of proxies. That said, if you apply any of the measures in something like Annoy User, such users will likely notice it when they log out, or if they use another computer after logging out (so you can't even really use cookies on their computer) - not to mention the fact that IP addresses are shot to bits if you use mobile devices on 3G connections and similar. It's not like you can even reliably block proxy connections here.
With all that, IP bans are basically useless, except to the most technically inept of users - and they certainly don't keep out spammers, there are better ways of doing that which don't require tracking IP addresses, which are only going to be more and more useless for tracking in future as IPv6 goes mainstream.
The only salvage then is hostname, but even that... well, it's typically disabled in a lot of cases because of sluggish performance (usually because hosted machines are behind a laggy rDNS) meaning it's not a lot of use to you, and even if it wasn't, most of the time bans are not carried out on hostnames but on IP addresses, when really, hostnames would be more useful.
The solution then, might be to be able to blacklist certain hostnames if lookups are enabled and functioning, but to use it at a deeper level than keeping the conventional bans on it (there are performance considerations too), and then you could use it only if you needed it. What I might do is integrate that into our Bad Behaviour implementation, making it look like (to the user, anyway) as if their computer has a problem rather than anything else.
That wraps it up for the problems with the ban system and how they can be mitigated, but let's go further: dealing with miscreants needn't stop at fixing the current setup.
So, user-level problems, we deal with at the user level, not some global administrative level. I'm thinking we can expand the warning system as a result. Right now users can be watched, moderated or muted. It's trivial to expand that to full-on banned, and it would be useful to expand how the tail-off works. Right now you can set how quickly the warning level drops for all users (in points per day), but making that per user would make more sense, so that users who just need a time-out can be given one, and it can be done per user, rather than something across the board.
I'm also thinking we could influence other permissions, such as losing avatar and signature if the warning is over a certain level.
Just for fun, there's another subsystem I've been thinking about, that will debut in some form. Specifically, it will allow you to add rules to certain parts of the system, e.g. things to do when a post is made - so you can check the contents of a post, and if it contains words you don't like, it gets moderated and the user can be warned automatically.
Too long, didn't read (tl:dr;) summary:
* Removing the ban system as it is
* Making post moderation more prominent, probably even enabled by default (but with performance tweaks to make it run more efficiently)
* Email blacklist/whitelist on registration/change email, instead of the old method of banning
* Add hostnames to the possible rules that will be checked in our Bad Behaviour setup, so that instead of getting a 'banned warning', it looks like problems with their computer
* Replacing user-level bans with the warning system and making it more granular rather than as coarse as it is right now
* Adding functionality from my old Annoy User mod to encourage bad users to go away
* Expanding the warning system to more gradually remove powers, than just moderated and muted
I don't think I missed anything but if I did, I'm sure you're going to let me know about it!
And please, before telling me you need the ban system as it is, really stop and think about what you use in it and why you use it, then before complaining at me for breaking what you think is an essential feature, think about if there's actually a better way of doing it, like the above. Banning is not a particularly wonderful technique as explained - it doesn't solve any problem, it solves some of the symptoms. I'm trying to solve the deeper problems. Just because something is what it is, doesn't mean you have to accept it.
Oh, one more thing I forgot.
I want to introduce a 'Banned' membergroup that users go into. Not only does it have a visual consideration but a permissions one: it would let you reduce access to boards. I don't know yet whether I want to make that an on/off thing (like banning is now, except it would turn off some boards and maybe show others) or a gradual thing (as you get more warnings, you slowly see fewer and fewer boards)
But that would certainly make life interesting!
The ban system as implemented is functional, as in it works but it's not overly elegant, it doesn't support IPv6 and I take the view that it doesn't solve the problem at hand, not one bit.
Let me deal with the IPv6 problem first, before I tackle the other stuff. The current system works on IPv4 addresses, which are x.y.z.a addresses, and whatever you put a ban (on IP address) on, it resolves to a range internally for each of the blocks. So a ban on 1.2.*.* becomes a ban internally on 1.2.0-255.0-255. Structurally, that makes sense, but IPv6 is much larger - instead of 4 blocks in the range of 0-255, you have 16 to contend with, though they're not written in decimal, nor written in the same way, but written as aaaa:bbbb:cccc:dddd:eeee:ffff:0000:1111 and similar.
There is one thing to consider, that addresses are divided in half in IPv6, the first half is for a 'network' and the second half for machines in that network, and it sounds that on the surface you could get away with just barring based on the first half only. Whether that will be successful or practical remains to be seen, but something tells me it's not that practical. It's not even that practical from a technical standpoint because if you're keeping that approach, you're not just comparing 4 values against ranges, but doing it for at least 8 - and you need to handle the high/low values, which is what SMF's and Wedge's system does right now.
I didn't implement IPv6 in Wedge in a way that would make this particular easy to implement for, because I took the view that it was the wrong way to be going about it, that any minor change extending the current direction of implementation to fit either 2x or 4x larger scope was an unnecessary performance headache, as well as a logistical one.
So, I sat back and thought about what I'd really like to be able to use in the ban system, and that lead me to my normal approach of trying to figure out what it is the ban system should be needed for, and what it should be able to do.
What is the ban system for? Primarily it's for getting rid of miscreants, and troublemakers. It isn't really a spam-solving solution, and it's not really for keeping users out that you're not interested in - it's for keeping users out that you don't want, which isn't the same thing.
Now before you start, I'm well aware that users do currently use it for keeping users out that they're not interested in, but on a variety of levels, I'm just not sure how viable that is, but we'll get on that in a minute.
So, dealing with troublemakers. The ban system lets you ban a user by name, email, IP or hostname. So you ban them, they come back under a new name through a proxy. Doesn't solve the problem much. For dealing with trolls and so on, there are better ways of dealing with them instead of slamming the door in their face - the tools used by Annoy User for example, to lock off certain features, plus the warning system that allows you to control whether they can post or whether their posts are moderated.
Of course, none of those things will solve the proxy problem, but the ban system wouldn't anyway. No, the solution is to gently turn up the heat so they don't realise that they're being pushed out, or at least discouraged from posting for whatever reason, and without it being obvious - so that they go and do something somewhere else.
If anything, the face-slam of the door is probably worse, not better, at making them go away - because what happens is that they don't have closure, they're not leaving of (kind of!) their own will, so you get all kinds of hassle as a result.
As for banning on email address, what is the hope of that? If you have miscreants who have their own domain, they can create as many emails as they like, so you just restrict the entire domain - it won't prevent them re-registering, though. So you get the extra account, you ban the entire domain, they try to register a third time and they still register - but this time they're banned and will take the hint. The problem is you've still got more accounts than you wanted in the first place.
Instead, then, how about limiting the email addresses up front? Put in the ability to restrict emails based on domain, either whitelisting or blacklisting certain domains as necessary. I know a number of users that restrict signups from mail.ru because of spam - if the domain is blacklisted, they can't even register (which is better than banning it).
There is, interestingly, a performance consideration here - and one for the better. If you ban based on email, the ban has to be evaluated more frequently than just locking it down at registration/change email time. In fact, that's going to be true of all bans - the more bans you have, the more you have to evaluate, and it has even a per-page consequence. By removing that query, you remove the performance hit, especially on long-term sites that have many bans, most of which aren't needed any longer.
Then we have IP addresses. Hello, darkness, my old friend. Putting aside the considerations of above with IPv6 addresses, the simple fact is that IP bans are really not that effective at keeping out miscreants because of proxies. That said, if you apply any of the measures in something like Annoy User, such users will likely notice it when they log out, or if they use another computer after logging out (so you can't even really use cookies on their computer) - not to mention the fact that IP addresses are shot to bits if you use mobile devices on 3G connections and similar. It's not like you can even reliably block proxy connections here.
With all that, IP bans are basically useless, except to the most technically inept of users - and they certainly don't keep out spammers, there are better ways of doing that which don't require tracking IP addresses, which are only going to be more and more useless for tracking in future as IPv6 goes mainstream.
The only salvage then is hostname, but even that... well, it's typically disabled in a lot of cases because of sluggish performance (usually because hosted machines are behind a laggy rDNS) meaning it's not a lot of use to you, and even if it wasn't, most of the time bans are not carried out on hostnames but on IP addresses, when really, hostnames would be more useful.
The solution then, might be to be able to blacklist certain hostnames if lookups are enabled and functioning, but to use it at a deeper level than keeping the conventional bans on it (there are performance considerations too), and then you could use it only if you needed it. What I might do is integrate that into our Bad Behaviour implementation, making it look like (to the user, anyway) as if their computer has a problem rather than anything else.
That wraps it up for the problems with the ban system and how they can be mitigated, but let's go further: dealing with miscreants needn't stop at fixing the current setup.
So, user-level problems, we deal with at the user level, not some global administrative level. I'm thinking we can expand the warning system as a result. Right now users can be watched, moderated or muted. It's trivial to expand that to full-on banned, and it would be useful to expand how the tail-off works. Right now you can set how quickly the warning level drops for all users (in points per day), but making that per user would make more sense, so that users who just need a time-out can be given one, and it can be done per user, rather than something across the board.
I'm also thinking we could influence other permissions, such as losing avatar and signature if the warning is over a certain level.
Just for fun, there's another subsystem I've been thinking about, that will debut in some form. Specifically, it will allow you to add rules to certain parts of the system, e.g. things to do when a post is made - so you can check the contents of a post, and if it contains words you don't like, it gets moderated and the user can be warned automatically.
Too long, didn't read (tl:dr;) summary:
* Removing the ban system as it is
* Making post moderation more prominent, probably even enabled by default (but with performance tweaks to make it run more efficiently)
* Email blacklist/whitelist on registration/change email, instead of the old method of banning
* Add hostnames to the possible rules that will be checked in our Bad Behaviour setup, so that instead of getting a 'banned warning', it looks like problems with their computer
* Replacing user-level bans with the warning system and making it more granular rather than as coarse as it is right now
* Adding functionality from my old Annoy User mod to encourage bad users to go away
* Expanding the warning system to more gradually remove powers, than just moderated and muted
I don't think I missed anything but if I did, I'm sure you're going to let me know about it!
And please, before telling me you need the ban system as it is, really stop and think about what you use in it and why you use it, then before complaining at me for breaking what you think is an essential feature, think about if there's actually a better way of doing it, like the above. Banning is not a particularly wonderful technique as explained - it doesn't solve any problem, it solves some of the symptoms. I'm trying to solve the deeper problems. Just because something is what it is, doesn't mean you have to accept it.
Oh, one more thing I forgot.
I want to introduce a 'Banned' membergroup that users go into. Not only does it have a visual consideration but a permissions one: it would let you reduce access to boards. I don't know yet whether I want to make that an on/off thing (like banning is now, except it would turn off some boards and maybe show others) or a gradual thing (as you get more warnings, you slowly see fewer and fewer boards)
But that would certainly make life interesting!
348
Off-topic / Either I'm going mad or I found a PHP bug
« on July 8th, 2011, 12:58 AM »
I don't want to get into the details, suffice to say I had need to write a SimpleDesk plugin today, and one of the things it does is add a new area to the admin panel, through $config_vars being passed to prepareDBSettingsContext. Nothing wrong there.
Then, after I finish setting up the array and passing it through to that function, I get a Warning: Invalid argument supplied for foreach() in C:\Dev\public_html\intranet\smf_2-0_install\Sources\ManageServer.php on line 1824.
This is a bit strange, but sure enough, line 1824:
Code: [Select]
Now, there's nothing happening between the start of prepareDBSettingsContext and that line that touches $config_var. And if I do a var_dump, I find there's a random NULL at the end of the var-dump that appears to be breaking it. Now, I'm confused because I have no idea where that NULL is coming from.
Here's the kicker: if I var_dump BEFORE the call, I get a normal var_dump and the array is normally traversable, so something about the call itself causes it to go nuts. It's not even the fact it's a reference, I reverted it to a normal variable by value and the same thing happens.
It's not like there's anything else going on - this variable is passed directly to the destination function and nothing hokey is going on in the middle.
So I'm really, really confused, and wondering if it's a bug. Maybe I should try upgrading (currently on 5.2.13 on local PC)
In other news, I am actually going mad, ignore me. Stupid bug, having spent an hour of frustrated debugging, because I forgot something quite important...
Then, after I finish setting up the array and passing it through to that function, I get a Warning: Invalid argument supplied for foreach() in C:\Dev\public_html\intranet\smf_2-0_install\Sources\ManageServer.php on line 1824.
This is a bit strange, but sure enough, line 1824:
foreach ($config_vars as $config_var)Now, there's nothing happening between the start of prepareDBSettingsContext and that line that touches $config_var. And if I do a var_dump, I find there's a random NULL at the end of the var-dump that appears to be breaking it. Now, I'm confused because I have no idea where that NULL is coming from.
Here's the kicker: if I var_dump BEFORE the call, I get a normal var_dump and the array is normally traversable, so something about the call itself causes it to go nuts. It's not even the fact it's a reference, I reverted it to a normal variable by value and the same thing happens.
It's not like there's anything else going on - this variable is passed directly to the destination function and nothing hokey is going on in the middle.
So I'm really, really confused, and wondering if it's a bug. Maybe I should try upgrading (currently on 5.2.13 on local PC)
Posted: July 8th, 2011, 12:46 AM
In other news, I am actually going mad, ignore me. Stupid bug, having spent an hour of frustrated debugging, because I forgot something quite important...
349
Development blog / Package Manager, how we won't miss thee
« on June 22nd, 2011, 06:12 PM »
The question about the package manager, SMF mods in general, still haunts us. I recently proposed what I want to do about it to the private board, and now I'd like to expand on that and put it in general terms for everyone; my proposal was more technical than general in nature. Besides, I figure that you want to see not only where we are but a few thoughts and insight into where we're going. (That's what the blog's for, right? :lol:)
SMF's package manager is an interesting artefact, and certainly more than a nod to what came before. But we're bidding it farewell in Wedge, to be replaced with a very different beast, even if it looks similar on the surface.
The Add-on Manager. It sounds nicer than package manager, and it implies its purpose better; packages don't just have to be new functions even in SMF, they can be packs of avatars, language packs and so on, whereas an add-on is physically a new thing added on to the core.
In many ways it's more than just a change of name, it's also a change of mindset: the add-on manager does not allow add-ons to modify files AT ALL. I'm not just removing the functionality from the existing package manager, I'm actually implementing a whole new branch of code to replace it, every aspect is being gutted, torched and rebuilt. It means you're never trying to break old habits, you start out by learning better ones from the word go. It also means that SMF mods will have to be rewritten, but honestly, that's a blessing rather than a curse.
No permissions issues where you have to open up all your files to higher permissions than they needed. You'll even be able to add and remove packages simply by uploading folders and removing them, without risking it just breaking randomly - but you'll have to visit the admin panel to enable it, of course.
It's also much smarter: instead of this version emulate madness and tying it to versions, the process is much closer to feature detection - add-ons declare the facilities they need to be able to use, and if those needs are met, it can be activated. (Add-ons can even, if they so wish, declare that they provide certain facilities, and other add-ons can indicate they want to use them, so you can build add-ons that have implicit dependencies)
Also if a plugin has specific requirements such as obscure PHP extensions, these can be indicated in the package itself preventing installation without them.
Naturally, all this stuff will be available through whatever we come up with as an add-on repository, so it becomes much clearer as to what's needed and what works with what.
Just for an encore, the add-on management will be able to figure out what languages are supported in an add-on, so we can also display that on the add-on repo, as well as displaying it in the core.
Add-ons will live in their own folder, which I expect to call Addons (and removing the old Packages folder), one folder per add-on. That way, a plugin's functionality is self-contained rather than filling up the Sources and Themes/default/languages folders with stuff.
Now, all this sounds wonderful, too good to be true in fact... except it isn't. It's not only workable, but a slimmer, less refined version is even built in to SimpleDesk 2.0 and has been since I prototyped it a year ago. I've learnt some lessons since then, some refinements to that design, and some of the changes we've made in Wedge make it possible to really do it justice.
I won't get into the innards right now, other than that Modifications.*.php files will be disappearing, that the add-ons still use XML to relate their details, much like package-info.xml but nicer, and that it'll have more in common with WordPress' plugins area than SMF's package manager.
I'll release a few more details once I'm comfortable and can show you a bit more about how it works.
SMF's package manager is an interesting artefact, and certainly more than a nod to what came before. But we're bidding it farewell in Wedge, to be replaced with a very different beast, even if it looks similar on the surface.
The Add-on Manager. It sounds nicer than package manager, and it implies its purpose better; packages don't just have to be new functions even in SMF, they can be packs of avatars, language packs and so on, whereas an add-on is physically a new thing added on to the core.
In many ways it's more than just a change of name, it's also a change of mindset: the add-on manager does not allow add-ons to modify files AT ALL. I'm not just removing the functionality from the existing package manager, I'm actually implementing a whole new branch of code to replace it, every aspect is being gutted, torched and rebuilt. It means you're never trying to break old habits, you start out by learning better ones from the word go. It also means that SMF mods will have to be rewritten, but honestly, that's a blessing rather than a curse.
No permissions issues where you have to open up all your files to higher permissions than they needed. You'll even be able to add and remove packages simply by uploading folders and removing them, without risking it just breaking randomly - but you'll have to visit the admin panel to enable it, of course.
It's also much smarter: instead of this version emulate madness and tying it to versions, the process is much closer to feature detection - add-ons declare the facilities they need to be able to use, and if those needs are met, it can be activated. (Add-ons can even, if they so wish, declare that they provide certain facilities, and other add-ons can indicate they want to use them, so you can build add-ons that have implicit dependencies)
Also if a plugin has specific requirements such as obscure PHP extensions, these can be indicated in the package itself preventing installation without them.
Naturally, all this stuff will be available through whatever we come up with as an add-on repository, so it becomes much clearer as to what's needed and what works with what.
Just for an encore, the add-on management will be able to figure out what languages are supported in an add-on, so we can also display that on the add-on repo, as well as displaying it in the core.
Add-ons will live in their own folder, which I expect to call Addons (and removing the old Packages folder), one folder per add-on. That way, a plugin's functionality is self-contained rather than filling up the Sources and Themes/default/languages folders with stuff.
Now, all this sounds wonderful, too good to be true in fact... except it isn't. It's not only workable, but a slimmer, less refined version is even built in to SimpleDesk 2.0 and has been since I prototyped it a year ago. I've learnt some lessons since then, some refinements to that design, and some of the changes we've made in Wedge make it possible to really do it justice.
I won't get into the innards right now, other than that Modifications.*.php files will be disappearing, that the add-ons still use XML to relate their details, much like package-info.xml but nicer, and that it'll have more in common with WordPress' plugins area than SMF's package manager.
I'll release a few more details once I'm comfortable and can show you a bit more about how it works.
350
Off-topic / A PHP fork?
« on June 15th, 2011, 07:29 PM »
http://www.xarg.org/2011/06/php-hacking/
I'm staring at this and quietly thinking 'why in god's name weren't some of these implemented in PHP itself?'
I mean, [] syntax for arrays, various string/array enhancements and optimisations. Plus he really took some brave moments with forcibly kicking out register-globals and magic quoting instead of them being deprecated. And, for the love of all things holy, he's made UTF-8 the default! (About fucking time. ISO-8859-1, or CP1251, or other character sets... not default.)
I'm not sure about this being really deployed (I think PHP is perhaps too entrenched at the moment) but it does feel like he's doing it because he's frustrated with the way PHP is being developed - and doesn't that sound familiar? ;)
I'm staring at this and quietly thinking 'why in god's name weren't some of these implemented in PHP itself?'
I mean, [] syntax for arrays, various string/array enhancements and optimisations. Plus he really took some brave moments with forcibly kicking out register-globals and magic quoting instead of them being deprecated. And, for the love of all things holy, he's made UTF-8 the default! (About fucking time. ISO-8859-1, or CP1251, or other character sets... not default.)
I'm not sure about this being really deployed (I think PHP is perhaps too entrenched at the moment) but it does feel like he's doing it because he's frustrated with the way PHP is being developed - and doesn't that sound familiar? ;)
351
Other software / SMF 2.0 final THIS MONTH?
« on May 6th, 2011, 01:51 AM »
I hope they know what they're doing. I really do. For their sake.
http://www.simplemachines.org/community/index.php?topic=432988.0Quote That gives them a shade over 3 weeks to fix the 32 bugs currently tracked. It's feasible, but honestly... they now have to deliver because not doing so will make them look like the biggest laughing stock going, and they will lose what little credibility they have left.
EDIT: Corrected typo.
http://www.simplemachines.org/community/index.php?topic=432988.0
So, what does this all mean? It means 2.0 final is very very close to being released. Really! I can't give an exact date, but you can trust me that we will release SMF 2.0 final by the end of May, 2011, unless we get hit by an asteroid. In the mean time thank you all for your continued support.
EDIT: Corrected typo.
352
Off-topic / I'm open minded, so I tried writing a blog post on my iPad
« on April 15th, 2011, 02:38 AM »
One of the future posts on InI is written solely on an iPad; this is not a particularly common thing for me, to write several hundred words, in mostly one sitting on an iPad - you'll tend to notice my posts are a bit shorter when I'm not deskbound.
I have to say I was yet more underwhelmed by WP on an iPad than WP on a desktop, which takes some doing, to be fair, and WP's mobile offering is almost as bad as the real thing, good thing it's free really.
Anyhow, someone linked me to an app for iPad called Blogsy, and I'm watching their how-to, and I'm sitting here getting jealous. Not so much the touch functionality but how damn easy it is to *get* to everything.
I personally don't really care too much for the sorts of things that the how-to video shows for myself; I'm quite capable of copy/pasting a link and so on, but for less technical users, it's a godsend - even more so than a WYSIWYG editor.
Just watch it, how easy it is to do stuff then tell me this isn't something Wedge should be able to do.
Blogsy Demo Video
I have to say I was yet more underwhelmed by WP on an iPad than WP on a desktop, which takes some doing, to be fair, and WP's mobile offering is almost as bad as the real thing, good thing it's free really.
Anyhow, someone linked me to an app for iPad called Blogsy, and I'm watching their how-to, and I'm sitting here getting jealous. Not so much the touch functionality but how damn easy it is to *get* to everything.
I personally don't really care too much for the sorts of things that the how-to video shows for myself; I'm quite capable of copy/pasting a link and so on, but for less technical users, it's a godsend - even more so than a WYSIWYG editor.
Just watch it, how easy it is to do stuff then tell me this isn't something Wedge should be able to do.
Blogsy Demo Video
353
http://www.theregister.co.uk/2011/04/13/wordpress_hack_attack/
WordPress is beginning to demonstrate its level of vulnerability... I think there may be some ground here :niark:
WordPress is beginning to demonstrate its level of vulnerability... I think there may be some ground here :niark:
354
Off-topic / Why the hell has no-one thought of this before?
« on April 14th, 2011, 12:25 AM »
http://www.kickstarter.com/projects/huskyjackaltheater/terminator-the-second
If you can't be bothered to read the link or watch the video, I'll sum it up.
Take Terminator 2: Judgement Day. Remove all original dialogue. Substitute in dialogue from Shakespeare that still tells the story.
Serve and enjoy.
Seriously, this is going to be epic.
If you can't be bothered to read the link or watch the video, I'll sum it up.
Take Terminator 2: Judgement Day. Remove all original dialogue. Substitute in dialogue from Shakespeare that still tells the story.
Serve and enjoy.
Seriously, this is going to be epic.
355
Off-topic / YouTube using short links?
« on April 8th, 2011, 02:41 AM »
http://www.simplemachines.org/community/index.php?topic=200401.msg3012232#msg3012232Quote Long version works here, short version does not. I don't particularly plan on documenting the fix publicly over there, but would be worth knowing that it needs to be fixed.
I'm using the old Auto Embed Video Clips...
YouTube seems to now be using shortened links to vids.. so links change
from http://www.youtube.com/watch?v=iqXE9XWvMPM
to http://youtu.be/iqXE9XWvMPM
which in turn does not embed the video .. How can i update the code so that it embeds both the old and new format ??
356
Off-topic / Dr S.E. Optimisation, or How I Learned To Stop WP and love the Wedge
« on April 7th, 2011, 02:33 AM »
I've been wondering, before I make the move of my blog to Wedge, is it worth spending time chasing the SEO dragon?
I've got a month's worth (9, if you're wondering) blog posts already pre-written, none of them keyword rich or any of that BS (and I refuse to alter my content for that), but is it worth spending a little time with the other stuff (like we'd likely implement in Wedge anyway)?
Note that I am going to be moving it to Wedge once the blogging stuff is done, with my custom styling Worldwind, so any SEO impact by Wedge will automatically up the ante.
I wonder if we should add the month-based navigation that's in WP, might be useful.
I've got a month's worth (9, if you're wondering) blog posts already pre-written, none of them keyword rich or any of that BS (and I refuse to alter my content for that), but is it worth spending a little time with the other stuff (like we'd likely implement in Wedge anyway)?
Note that I am going to be moving it to Wedge once the blogging stuff is done, with my custom styling Worldwind, so any SEO impact by Wedge will automatically up the ante.
I wonder if we should add the month-based navigation that's in WP, might be useful.
* Arantor also wonders who gets the title to this topic.
357
Off-topic / Another reason to dislike GoDaddy, as if any more were needed
« on March 31st, 2011, 02:49 PM »358
Other software / So, SMF has declared the cold war...
« on March 31st, 2011, 02:24 AM »
Apparently, there's a rule that no links to other forum packages - the example given was MyBB - in signatures and would I remove the Wedge image from my sm.org sig.
I have just replied asking whether it's appropriate for team members to be linking to phpBB forums and will await the reply with interest.
EDIT: Did I mention that I'd never heard of this rule before now?
EDIT 2: Wait until I point out a few things of interest, such as the fact that it violates their Core Values. This is going to be hilarious.
:edit: 3 by Nao: renamed topic from "So, I've been asked..." to something that's clearly more in line with the contents.
I have just replied asking whether it's appropriate for team members to be linking to phpBB forums and will await the reply with interest.
EDIT: Did I mention that I'd never heard of this rule before now?
EDIT 2: Wait until I point out a few things of interest, such as the fact that it violates their Core Values. This is going to be hilarious.
:edit: 3 by Nao: renamed topic from "So, I've been asked..." to something that's clearly more in line with the contents.
359
Features / Find and repair errors
« on March 22nd, 2011, 05:31 PM »
I've been looking at how it works in SMF because one of the things we will need to do is maybe extend it (and I had to write something similar for something else)
I have to admit, I'm more than a little confused why it's done how it's done in SMF. Let's get a really big array, one element for each test we're going to perform, then just for shits 'n' giggles, let's stuff at minimum one query into that array (raw SQL) for what we're testing for, likely a second query to repair it, sometimes a lambda function to pass the rows from the original test query to...
Is there something wrong with having one function per test and encapsulating it like that?
I have to admit, I'm more than a little confused why it's done how it's done in SMF. Let's get a really big array, one element for each test we're going to perform, then just for shits 'n' giggles, let's stuff at minimum one query into that array (raw SQL) for what we're testing for, likely a second query to repair it, sometimes a lambda function to pass the rows from the original test query to...
Is there something wrong with having one function per test and encapsulating it like that?
360
Off-topic / Happy Birthday Nao!
« on March 21st, 2011, 02:21 AM »
You can't hide, I know it's your birthday! Hope today's an awesome one :)