1SaltwaterC

vor 13 Jahrendiscuss

Kinda reminds me of http://www.youtube.com/watch?v=gmOTpIVxji8

vor 13 Jahrendiscuss

How many actual users suspect that something is wrong with the input, even without URL obfuscation? OTOH, with a permanent XSS it is pretty much game over, even though I doubt that's the case. XSS can do a lot of damage if used properly.

1SaltwaterC

vor 13 Jahrendiscuss

Per CloudWatch stats, it varies for machine and region. We have a 6 machines array in three regions receiving round robin traffic from ELB's. It is network bound. However, the CPU graphs say otherwise. Here's the output of three machines in three regions: http://i.imgur.com/nadGmDH.png while their siblings follow the same trend. The working set resides in RAM. The disk and network follow the same path. These are instance store machines sharing as little as possible. Failing over a multi-AZ RDS for maintenance reasons did not change the graphs.

1SaltwaterC

vor 13 Jahrendiscuss

They aren't "unsyncable" per se, but Google Drive has preferences. For example, I could not sync files from a stackable encrypted filesystem (EncFS or eCryptfs). Files that go just fine through Dropbox or SugarSync. Same "error". I guess there's no money for Google in files you can't take a peek at.

1SaltwaterC

vor 13 Jahrendiscuss

http://xkcd.com/538/

1SaltwaterC

vor 13 Jahrendiscuss

Both TCP and UDS depend on it. UDS uses an API that follows the BSD sockets standard. However, TCP makes sense when you use nginx as load balancer between multiple PHP-FPM backends. A really tricky setup if you ask me. For UDS, besides lower latency, the namespace is cleaner (filesystem paths vs numeric ports - much easier to automate the configuration), and (at least under Linux) they follow the filesystem ACL. For example, under my setup, only nginx's user is allowed to read / write to the PHP-FPM sockets.

1SaltwaterC

vor 13 Jahrendiscuss

I'd argue a little with the "Apache is monolithic". If you know your elbow from your butt, you can make a decent Apache setup as any decent sysadmin should do. The thing that I hate the most in nginx is the lack of DSO modules. When I need a new module, I need a new nginx build. nginx itself has more than you ask for in a standard build. As example, I counted the "with" and "without" flags from out nginx package build script. It has 3 "with" flags (SSL, gzip static, PCRE JIT) vs 14 "without" flags. And we can part with gzip static since most of the static objects are pushed by CDN's now.

Apache is catching up with its evented MPM and proxy support, but I still wouldn't go back to Apache though. The main selling point that the OP should get is the fact that evented servers have much better memory usage under the same load as the threaded servers or (cough) process based servers.

1SaltwaterC

vor 13 Jahrendiscuss

I can provide you some pointers as we made it go away. Some data from one of our production virtual hosts:

  cat access.log.1 | wc -l
  1054423 # no static objects served here
  cat error.log.1 | grep timed

For PHP-FPM we use static pm and unix domain sockets. This virtual host if fairly busy with some slow (~200 ms) requests, therefore it uses 96 processes per pool. listen.backlog = -1 in php-fpm.ini for letting the kernel decide the size of the actual connection backlog. UDS is getting filled faster than TCP and nginx starts responding with 502's. Throw net.core.somaxconn = 65535 somewhere in /etc/sysctl.d for increasing the actual backlog since even if you specify a high listen.backlog value, the actual value is truncated to SOMAXCONN. Couple of years ago I wrote an article about stuff like this: http://www.saltwaterc.eu/nginx-php-fpm-for-high-loaded-websi... (shameless plug, I know, but you may get some useful info). As a side note, I am curious how the backend persistency for nginx is playing. Our production still uses the same config since 2011 as it isn't broken, but it may be more efficient.

1SaltwaterC

vor 13 Jahrendiscuss

> to uninstall something installed from a .dmg file all you need to do is delete the ApplicationName.app "file"/folder.

AppCleaner / AppZapper / AppDelete / CleanApp / etc beg to differ. A lot of packages leave a lot of crap behind that doesn't get removed with the .app directory itself.

1SaltwaterC

vor 13 Jahrendiscuss

> To do otherwise is to suffer a whole day trying to install ImageMagick

Sure, you could do that, or issue [pkg-manager] install imagemagick. It took me yesterday around 15 seconds to install imagemagick without even leaving iTerm. Even brew knows that.

1SaltwaterC

vor 13 Jahrendiscuss

The CPU doesn't get that hot. On a machine with an Athlon II 240e cgminer uses ~18% CPU vs the GPU that sits at 99% load. scrypt is indeed viable on GPUs, but it depends onto the available memory bandwidth which presumably lessens the impact of FPGA/ASIC if people start to push those as LTC mining solutions.

1SaltwaterC

vor 13 Jahrendiscuss

> you must always have both hands on the wheel

There aren't any folks driving manual in your area?

1SaltwaterC

vor 13 Jahrendiscuss

Nope. As noted in the article, it actually works. Tried it a few times where I had svn around, but not git.

1SaltwaterC

vor 13 Jahrendiscuss

Call me a skeptic as I see this like speculation, but where I've seen that kind of return, turned out to be really clever ponzi schemes and enough supply of dumb enough "investors". Oh yea, I remember that fun time when the housing market in my area went up 5X in 4 years. It was all fine till people ran out of actual money. The rest is history.

1SaltwaterC

vor 13 Jahrendiscuss

Thinking the same thing. It'll be interesting to see somebody going out sorosing the BTC "economy".

1SaltwaterC

vor 13 Jahrendiscuss

I hate it. I hate it with passion. It is really disruptive to my type flow as I don't accidentally press caps. I actually press it when I need it.

1SaltwaterC

vor 13 Jahrendiscuss

By any chance, did you try Sparrow?

1SaltwaterC

vor 13 Jahrendiscuss

There's no need. git by itself already does that. Shameless plug: http://www.saltwaterc.eu/git-is-distributed-stupid.html