« New One
Fork discussion at SMF
Baibai vblamer »

Nightwish

  • Posts: 41
Re: Fork discussion at SMF
« Reply #45, on August 18th, 2011, 08:42 PM »
Quote from Voldefork on August 18th, 2011, 03:30 PM
It's also interesting that vblamer's and JBlaze's forks will both remove support for PGSQL and SQlite. I'll start counting the number of features they're taking verbatim from the Wedge Feature List... :niark:
I'm going to do this as well in mine and it has little to do with copying, just with agreeing on the fact that it wasn't a very bright idea to include it in the first place. Seriously, how well are the PGSQL and SQLite layers tested in a real-world scenario?

PostgreSQL is, without doubt, a fine database, in some areas much better than MySQL, but its importance for forum installations is close to zero and I'm unsure about SQLite, which is also a very nice piece of software just not very important as a database for web applications.

I'll also kill support for PHP4, caching support for eAccelerator (doesn't make sense, because eAccel has been stripped from the required functionality) and Turk MMCache (doesn't make sense to support it when you're PHP5+). Furthermore, APC, XCache, memcached and the fallback method with disc caching should be enough options to cover the vast majority of installations.

I'm also considering wiping MySQL fulltext search, because it's pretty much useless when you have custom index (sufficient for most installations) and sphinx (for the big guys).

I hate legacy code that just sits there, making the code harder to read and maintain while doing absolutely nothing for 99% of all installations.
Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to a single instruction that doesn't work.
My SMF-based forum fork

Snape

  • Posts: 14
Re: Fork discussion at SMF
« Reply #46, on August 18th, 2011, 09:15 PM »
Quote from Sirius Shadow on August 18th, 2011, 03:55 PM
Sirius Shadow? I'm bad with names. Wanted to adopted Snape but a member here already had it. :P
I'll surrender it...for a price. (stated with proper Rickman-esque tone)

AngelinaBelle

  • Still thinking...
  • Posts: 92
Re: Fork discussion at SMF
« Reply #47, on August 18th, 2011, 09:17 PM »
Quote from Albus Dumbledore on August 18th, 2011, 07:27 PM
I do not know much about open source license but I find it very weird for a BSD licensed software to impose restriction such as not allowing linking to a non-BSD licensed fork....
Well, I'm sure you can imagine that there was much debate on this point -- is discussion of a fork that does not permit free redistribution of the original and derived works beneficial to the community of the original software? Some would say "absolutely", some would say "somewhat less than if it were a BSD or SA-licensed fork", some would say "not at all".

The team debated this issue. And came to a consensus on the purpose and rules for the board.

I guess you are correct -- the team does need to take pride in the fact that we have seen 4 forks announced. It's new territory, though. It will take a while to get used to it.
I'm an SMF doc writer.

Norodo

  • Oh you Baidu, so randumb. (60 sites being indexed at once? Jeez)
  • Posts: 469
Re: Fork discussion at SMF
« Reply #48, on August 18th, 2011, 09:27 PM »
Quote
is discussion of a fork that does not permit free redistribution of the original and derived works beneficial to the community of the original software?
I'm pretty sure the allies wouldn't have won the war if they had refused to talk about the axis.

TL;DR: Yes obviously it's beneficial

AngelinaBelle

  • Still thinking...
  • Posts: 92
Re: Fork discussion at SMF
« Reply #49, on August 18th, 2011, 09:33 PM »
I agree that it is beneficial.
And there is no war. Competition. As friendly as is humanly possible, I hope.

Norodo

  • Oh you Baidu, so randumb. (60 sites being indexed at once? Jeez)
  • Posts: 469
Re: Fork discussion at SMF
« Reply #50, on August 18th, 2011, 10:02 PM »
That was a hyperbole.

I could have said "competition brings progress" or "even enemies gain by discussion" but it would not have the same effect. My point was never that there was a war, but that even the most bitter enemies only lose by limiting their knowledge.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Fork discussion at SMF
« Reply #51, on August 18th, 2011, 10:46 PM »
Quote from Nightwish on August 18th, 2011, 08:42 PM
Quote from Voldefork on August 18th, 2011, 03:30 PM
It's also interesting that vblamer's and JBlaze's forks will both remove support for PGSQL and SQlite. I'll start counting the number of features they're taking verbatim from the Wedge Feature List... :niark:
I'm going to do this as well in mine and it has little to do with copying, just with agreeing on the fact that it wasn't a very bright idea to include it in the first place. Seriously, how well are the PGSQL and SQLite layers tested in a real-world scenario?

PostgreSQL is, without doubt, a fine database, in some areas much better than MySQL, but its importance for forum installations is close to zero and I'm unsure about SQLite, which is also a very nice piece of software just not very important as a database for web applications.

I'll also kill support for PHP4, caching support for eAccelerator (doesn't make sense, because eAccel has been stripped from the required functionality) and Turk MMCache (doesn't make sense to support it when you're PHP5+). Furthermore, APC, XCache, memcached and the fallback method with disc caching should be enough options to cover the vast majority of installations.

I'm also considering wiping MySQL fulltext search, because it's pretty much useless when you have custom index (sufficient for most installations) and sphinx (for the big guys).

I hate legacy code that just sits there, making the code harder to read and maintain while doing absolutely nothing for 99% of all installations.
To sum up:
The PGSQL layer is incomplete and has at least one fatal error in it, the SQLite layer is even less tested, but it's also based on SQLite 2.5 while most hosts run SQLite 3. The idea was that at the time, PHP were pushing it as their next generation DB for smaller purposes, like a starter forum could use.

We came to the same conclusions about PHP 4, the caching technologies and also with respect to full text indexes, especially as InnoDB doesn't support them and as of MySQL 5.5, InnoDB is the default engine.


Regarding competition, I'd love to see all the different branches of SMF sit down in a year's time and look at the different directions taken. We took a bold road in some of the changes we're making and it'll be interesting to see if our instincts about them were right, and I know I'd be interested in sharing how we get on in that respect.
When we unite against a common enemy that attacks our ethos, it nurtures group solidarity. Trolls are sensational, yes, but we keep everyone honest. | Game Memorial

AngelinaBelle

  • Still thinking...
  • Posts: 92

Nao

  • Dadman with a boy
  • Posts: 16,080
Re: Fork discussion at SMF
« Reply #53, on August 20th, 2011, 05:08 PM »
Quote from Nightwish on August 18th, 2011, 08:42 PM
I'm going to do this as well in mine and it has little to do with copying, just with agreeing on the fact that it wasn't a very bright idea to include it in the first place. Seriously, how well are the PGSQL and SQLite layers tested in a real-world scenario?
I'm assuming it made sense back in 2005, when SMF2 was started. PHP5 was new, and at the time the MySQL license was seen as problematic when linked to PHP's, or something, and they decided to try and push for SQLite. Which didn't really work... I don't know about PG, but I suppose that because they made it possible to add other engines, they wanted to make space for a third one by default.
Quote
I'll also kill support for PHP4, caching support for eAccelerator (doesn't make sense, because eAccel has been stripped from the required functionality)
Not exactly, it was simply made disabled by default. Meaning someone using it can still force it to be enabled, so, because eAcc is still updated, I think it also makes it harder to remove support for it, unlike MMCache which was one of the first things to go in Wedge IIRC.
Quote
I hate legacy code that just sits there, making the code harder to read and maintain while doing absolutely nothing for 99% of all installations.
I think we 'managed' to remove several thousand lines of codes altogether. Still, it doesn't represent much when compared with the SMF codebase's size, but it did add a lot of overhead to functions that are central to SMF. Also, removing the first parameter in $smcFunc['db_query'] was heavenly. I've never liked the fact that 99% of SMF's queries had an empty string in front of them... It could have easily been put to the end of the list!

karlbenson

  • Posts: 44
Re: Fork discussion at SMF
« Reply #54, on August 21st, 2011, 10:28 PM »
Well sqlite and pgsql were all tested (i did most of the bug hunting on it).

But both got repeatadly broken with each RC.  Some sites did start using them, but I don't think any survived.
We come in peace, shoot to kill, shoot to kill, shoot to kill; we come in peace, shoot to kill; Scotty, beam me up

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Fork discussion at SMF
« Reply #55, on August 21st, 2011, 11:27 PM »
I think it's fairer to say that they weren't "broken repeatedly with each RC" - each RC did have more bug fixes for the PGSQL stuff, and almost nothing for SQLite, but no-one really tested them that thoroughly, and as such the bugs that are coming to light are simply ones that fell through the cracks.

JBlaze

  • Boldly going where no idiot has gone before
  • Posts: 67
Re: Fork discussion at SMF
« Reply #56, on August 24th, 2011, 09:35 AM »
Interesting...

My fork is just a side project I've started working on just for fun. Something to help me increase my skills in programming. I highly doubt it will be anything successful.

As for "stealing" features, there's not much a forum can have implemented that hasn't already been done. Forums can have similar features without them being stolen. It's not the idea that matters, it's how you implement said idea.

And I know most of you know I have commitment issues (dropping in/out of team, etc), but that's a wonderful trait of me being ADHD.

And no, it's not a "hostile" fork. It's not even competition from the way I see it, but rather building on an existing structure and molding it the way I would like it to be.
Jason "JBlaze" Clemons

Follow me on Twitter!

Nao

  • Dadman with a boy
  • Posts: 16,080
Re: Fork discussion at SMF
« Reply #57, on August 24th, 2011, 09:43 AM »
I think a lot of capable people are going to be building their own SMFs... Sometimes even when it just could have been all made into a mod... And you know why? Because mods in SMF are painful :P
Although I'm not sure the weight of having to support an entire SMF codebase is going to be worth it!

Basically, I think what SMF should be going, if it HOPES to have a chance at surviving, is moving its SVN to git, and allowing anyone to commit patches for the lead devs to check and push into the core.

Since the SMF devs are obviously unable to do the amount of work they're expected to do, I'm sure the SMF team will eventually rely on this.[1] I'm not saying it won't be exploitative of external developers.... But that's the 'spirit' of open source... :whistle:
 1. After all, that's what they did last year with me: when all devs were on vacation, they fucking offered me a dev position in late May when it was all sunny outside, I did all of the work for a month, and then when they refused to give me a consolidated position I left the job. I mean, I did something like 90% of the commits in June and July 2010.

Jeff Lewis

  • Posts: 5

Dismal Shadow

  • Madman in a Box
  • Me: Who is Arantor? Cleverbot: It stands for time and relative dimensions in space.
  • Posts: 1,185
“I will stand on my ground as an atheist until your god shows up...If my irreligious bothers you much, and if you think everything I do is heresy to your god I don't care. Heresy is for those who believe, I don't. So, it isn't heresy at all!


   Jack in, Wedge,
   EXECUTE!
« New One
Baibai vblamer »