Forums

And everyone should not want Facebook (or anyone, for that matter) fully controlling his user base, and collecting data on it. Unless they got a fat check, at the very least.

Facebook connect is a bad idea per se.

Did people learned nothing of the MovableType debacle?

Maybe you should post in a Support forum, like this one: https://fluxbb.org/forums/viewforum.php?id=26

Good content, any non content thing not getting in the way. Simple, efficient.

2400 bauds that's way to fast. 300 or 1200 should do it. Better to have several slow modems than one fast, to allow for more than one connected user.

Did just that 4 times in the past week. And still not happy with it, going for a 5th.

Even the one making government website ignore some, if not much, of the stuff. That one is still pretty young. But pesky things like EU version of copyright & fairuse infringements, official websites break those on a regular basis.

Facebook connect is a bad idea for the web as a whole.

Besides, things like xml sitemap (which is a real standard, and open one), useful for 99.99% of the boards, have been refused into core... doubtful fconnect will make the cut.

The description should match the actual content. Generic description are usually worse than no description at all.

Wonderful! That way, Facebook can not only data-mine and sell to dubious organization the private life you put on their site, but everything else you do on the web.

Marvelous.

Yes it did. You were loading unused strings, and a bunch of them.

In other words, loading and processing a 4kB php page isn't the same as loading and processing a 8kB php page.

If you think that makes no differences, try it (under real working production conditions of a busy and common shared server of course, won't see much differences on a clean idle desktop computer with only one user).

That's a nice option, but it should stay an option.

A web form is the lowest possible text editor there is. No advance search&replace, no regexp, difficult to input some character (the dreaded nbsp for example), no handling of several files at once, no in-screen visual help, etc.

For example, try changing “e-mail” to “email” in a lang pack under 5 seconds using a web interface (unless you propose to load every strings into one form?).

You should provide the code to make the files. If the website is down for some reason, if the team split, whatever, Flux software should not rely on anything other than itself to function properly.

There's a benchmark of loading whole versus loading string by string when they are needed? After all, Pun/Flux main goal is speed.

I disagree. The first proposal was to increase the weight of the source code for absolutely no reason if your board isn't in English, which will increase cpu usage, memory occupation, and I/O. You'll basically load something twice. It just doesn't make any sense.

As to some other reactions, and trust in general, well that's understandable given the past years. Reaping what one sow and such.

On top of that, several minds are better than one. That's the main principle of open source, you work is better because there's other people out there that might see things you didn't.

Oh

My

God