Kinda reminds me of http://www.youtube.com/watch?v=gmOTpIVxji8
HN user
1SaltwaterC
[ my public key: https://keybase.io/saltwaterc; my proof: https://keybase.io/saltwaterc/sigs/IjBJkAyFqIgQsAy0DegDGqqtP2qWPqqLvKbU5bUsVv0 ]
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.
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.
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.
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.
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.
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.> 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.
> 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.
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.
> you must always have both hands on the wheel
There aren't any folks driving manual in your area?
Nope. As noted in the article, it actually works. Tried it a few times where I had svn around, but not git.
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.
Thinking the same thing. It'll be interesting to see somebody going out sorosing the BTC "economy".
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.
By any chance, did you try Sparrow?
There's no need. git by itself already does that. Shameless plug: http://www.saltwaterc.eu/git-is-distributed-stupid.html
Thinking the same thing. But the medigel is that thing too useful to be banned by the Council, so ... yes.
Did they send Schrödinger's cat with Voyager 1?
But it helps Google for better profiling.
The actual version numbers:
2000: NT 5.0
XP: NT 5.1
Vista: NT 6.0
7: NT 6.1
8: NT 6.2IIRC is the only case where you can not kill a process under unices. It goes into the D state (uninterruptible sleep). Usually waiting for I/O is the reason for a process going into a D state. From my own experience, had this issue with faulty hardware and network filesystems. Here's something easy for reproducing a process going into uninterruptible sleep: GlusterFS 3.0.4 (Ubuntu 10.04 packages that version, a single machine setup is sufficient). A bug in Gluster turns into a deadlock and the process that triggers that bug does into the D state. Cause: using file locks without explicit unlock when releasing the file descriptor. The process can't be killed as it waits for the FS while the FS waits for the process to release the lock (which never happens). Had fun debugging that on a live deployment where each process got stuck one by one till the process pool was exhausted, while monit could not restart the daemon that managed the process pool.
"Rage faces" aren't necessarily composed only of "rage". Explained in the other comment why this actually isn't lexicographic sorting.
If you look at my comparison, you can see that it isn't a decimal number. I said (dropping the v prefix, that may bee to subtle for HN): 0.8 < 0.10 < 0.80. In decimal that would be: 0.8 < 0.1 < 0.8 - the comparison doesn't work this way (duh). But it isn't lexicographic sorting either. This sequence: 0.8, 0.80, 0.2, 0.20 has this lexicographic order: 0.2, 0.20, 0.8, 0.80, while a proper version ordering is to compare the stuff after the dot aka 2 < 8 < 20 < 80.
By reading some of the gems around here, apparently not. Example:
> A version number is a sequence of natural numbers ordered lexicographically.
I need a new rage face for expressing this.
Do you have _any_ standard to back up that claim or you're pulling that out of nowhere like the rest of the down-voter crowd? Besides, in the node.js community the semantic versioning is accepted as standard. npm is the default tool for managing packages. For reference: http://semver.org/
v0.8 < v0.10 < ... < v0.80. God damn math.
Due to the "PHP beauty", ! $string isn't equivalent for $string == ''. In this case it is better due to the logical evaluation clusterfuck that PHP does. Example: passing an empty array() as $string bypasses the if, while ! $string is sane enough, but the bang operator fails with "0" which is a valid string that "happens" to evaluate to false. I know these are edge cases, but can lead to funny bugs. Not so funny for those who debug that.
> on every possible configuration
You either have the case sensitive fs, or you don't. Sounds like you're making up excuses for the developer laziness.