Age | Commit message (Collapse) | Author | Files | Lines |
|
Compresses a little better. I reduced the number of iterations required
to find the optimal image size in spritegen.pl, but generating the
icons.png is *incredibly slow* when combining zopflipng with the 'slow'
option. It's possible to parallelize the calculation and use multiple
cores to speed it up, but that seems overkill.
Some icons.png compression stats:
METHOD SIZE RUNTIME
default 18103 <1sec
slow 17941 few secs
pngcrush 15385 <1sec
pngcrush+slow 15148 few mins
zopflipng 14986 few secs
zopflipng+slow 14898 ~1 hour
|
|
They had to be deleted from the database at some point, otherwise we
still have thousands of easily-cracked password hashes in the database.
Note that I could have opted to use scrypt on top of the sha256 hashes
so the passwords would remain secure without needing to reset
everything, but doing that after one year of switching to scrypt is
likely not worth it. Everyone who still actively uses his account has
already been converted to scrypt, everyone else should just reset their
password whevener they decide to come back.
|
|
A recent version of imagemagick creates 16 bit depth PNG images by
default for some reason. This results in an unnecessarily large file
size increase and pngcrush doesn't do much to counter it (and its
-bit_depth option has been deprecated, too).
The atomic replace is quite handy to avoid people seeing any wierd
intermediate images while the slow+pngcrush options are being used.
|
|
Tends to compress a bit better than JavaScript::Minifier::JS. But is
also a lot slower, so not really useful when devving.
Stats for en.js:
raw gzip
uglifyjs 68199 19446
JS::Minifier::XS 79862 21624
Uncompressed 107662 28663
On an unrelated note, I like how jQuery boasts about being "Only 32kB
minified and gzipped.". That's quite a bit more than all of VNDB's
Javascript combined. For a damn library.
|
|
Looks like login won't always work correctly without.
|
|
I increased the N parameter to approximate about 500ms to generate the
hash. This is quite a paranoid setting for a website, but login attempts
are throttled so there's not much of a DoS factor. (Alright, password
changing feature isn't throttled so the DoS factor still exists. But
really, there's some pages with longer page generation times anyway.)
I did lower the size of the salt a bit (Crypt::ScryptKDF uses 256 bits
by default), because 64 bits of randomness should have low enough chance
of collision with only ~100k users (even with a million users,
seriously).
|
|
|