Error: This thread is too old. You can't reply anymore.

Oh shit! What ever happened to NO EXCEPTIONS^?

>>40
SQLite is a flat file.

>>40
Did you add an index?

>>36
Shitchan (the python clone) uses sqlite and stores threads as compressed flat files inside the db. The compression savings is huge but it's intensive to access and edit threads.

>>40
That sounds very wrong. SELECT * FROM whatever LIMIT 50 shouldn't take that long unless it physically takes a minute to get that amount of data from the disk. If that's the case, you have misunderstood the benefit, try getting the *last* 50 rows instead.

But your query was probably more complex than that, and maybe you had no indices or referenced a large field in a WHERE or ORDER BY clause.

SQLite isn't the fastest but it will handily show a great improvement over flat files for non-sequential access.

Well, here's a good reason to avoid CGI: http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html

He's scanning with http://seclists.org/oss-sec/2014/q3/649

tl;dr gnu bash environment export of functions allows command execution. Any service that lauches a gnu bash shell with tainted environment variables (including some CGI implementations) allows remote code execution.

>>43
That's surprising, unless the de/compression is done in pure Python, or it's something slow like bzip. (It took me a minute to realize you weren't talking about shiⁱchan.)

>>45
It's something slow. DEFLATE with maximum compression, provided through python's standard library.

http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html

>>44
Its literally a "SELECT * FROM table LIMIT 50" and the disk has no problem keeping up when it comes to anything else.
>>42
No, but there aren't any WHEREs.

>>47
That's weird. It's never been like that for me.

>>47
Very strange, and this was SQLite 3?

>>49
>>48
Yes. I honestly have no explanation as to what was wrong other than the size of each row. Either way I didn't expect it to be THAT slow.