The first lesson I learned from the book 'High Performance MySQL' is that one should never use an ORM. Optimizing for ORM queries is virtually impossible.

http://stackoverflow.com/questions/7707976/php-and-mysql-high-traffic-solution

FWIW: I notice in a later post you mention PDOs... Which look like they won't impact optimization strategies.

I'm genuinely interested in hearing what the benefits of this are. It seems like mSATA drives are more or less on parity with this in terms of size and capacity, but have the benefit of increased longevity, reduced noise, and lower power consumption.

I honestly think spinning hard disks are going to go the way of CRTs within the next 5 to 10 years. And there's a high probability Segate will go with it.

You can MITM a SSL connection if you have access to a valid CA key. However, the attack would not be undetected; you need the sites private key in order to create a duplicate certificate. To create a duplicate certificate, you'd need the site's private key. And if you have that, you don't need a CA cert.

Someone who's paying attention could easily see that the MITM certificate doesn't match the original cert. For example, SSH doesn't use CA key signing. However, clients can still detect a MITM attack because the MITM public key does not match the cached key maintained by the client. (This presumes of course that you aren't performing a MITM attack using the compromised private key.)

It really depends on the phone. My Nexus S has been dropped a dozen times without issue. My wife has been through an iPhone 4 and a Nexus III. Larger phones don't seem to like being dropped.

Screen protectors are different... There's all kinds of shit in my pockets that can scratch even gorilla glass. Plus, the screens are oil resistant, which is nice.

I strongly disagree. I'd happily deploy configuration management tools or an inventory service in environments with 2 hosts. Configuration management isn't just automation; it's also build documentation and a handy gateway between your RCS and your systems.

There's always Ansible; the remote agent is a SSH server. Communication model is push only. Configuration files are YAML.

There are a dozen different configuration management tools on the market right now. There is almost certainly an option that fits your needs.

It doesn't really need 1.5 pages of description.

Cloud computing is a strong abstraction layer between the physical machine and the logical machine. It's very similar in concept to memory virtualization - each process is given it's own address space, and really doesn't understand or care how that address space maps to physical memory. In a cloud computing environment, you request a new machine, and the cloud computing infrastructure automatically allocates a machine based on your requirements. The abstraction layer allows your physical hardware to be treated as a pool of resources, that can be expanded, repaired, or replaced without much concern about the impact to the logical machines it supports.

Cloud computing doesn't necessarily require virtualization either; physical computers can be provisioned using cloud infrastructure; https://wiki.openstack.org/wiki/Baremetal

If all you need is a place to dump your code, GIT is a perfectly functional GIT server. If you want full features, and damn the cost, you could consider GitHub enterprise.

Yep, you're right. I corrected myself in another post.

I need to offer you credit; you are right. The issue isn't really PAE, it's how the kernel manages memory on 32 bit x86 architectures with more than 1GB of memory installed. PAE simply exacerbates the problem. Here's an explanation of the complaint:

On ia_32 systems, the kernel splits memory into 3 zones; DMA, NORMAL, and HIGHMEM.

ZONE_DMA is the first 16MB of memory, and is generally avoided unless needed (due to lack of available higher memory, or for DMA mappings.) The kernel tries to reserve this address range for devices that use DMA mapping.

ZONE_NORMAL is an address space that is directly accessible to the kernel, and extends from 16MB to 896MB. Kernel data structures are stored in this space, including the kernel page tables. Memory mappings start to consume a lot of memory in ZONE_NORMAL, and thus PAE on ia_32 with a lot of installed memory can cause out of memory issues, even when there is a lot of available physical memory. User data can be allocated into ZONE_NORMAL, but is preferred to be placed in ZONE_HIGHMEM to free ZONE_NORMAL for kernel data structures.

ZONE_HIGHMEM is memory above the 896MB barrier. This address range is not directly accessible to the kernel. In order for the kernel to access anything in this zone, a temporary map must be made into ZONE_NORMAL. These mappings consume pages of ZONE_NORMAL, and suffer a performance hit. User space processes can access these pages directly (handled by the virtual memory manager system, of course.)

Generally, memory will be allocated to ZONE_HIGHMEM, ZONE_NORMAL, or finally ZONE_DMA in that order of preference.

The x86_64 architecture eliminates the need ZONE_HIGHMEM. ZONE_NORMAL extends all the way from 16MB to the end of physical memory. This approach simplifies memory management, improves performance, and is generally more flexible.

You're correct that there was a major issue with my original post... My memory of the kernel architecture had garbled HIGHMEM with PAE, and I was thinking that PAE required mapping pages above 4GB into lower memory. This would of course cause a huge performance penalty for any process consuming memory above 4GB. I deserve downmods for the technical inaccuracy.

Here's a very brief summary of the problems with HIGHMEM:
http://linux-mm.org/HighMemory

Here's a bunch of links used to refresh my memory:

http://www.makelinux.net/ldd3/chp-15-sect-1
https://www.kernel.org/doc/gorman/html/understand/understand005.html
http://unix.stackexchange.com/questions/5143/zone-normal-and-its-association-with-kernel-user-pages

Yes, this is a bit of an oversight on my part. I really should have been discussing the way PAE is implemented on ia32 processors. I had a little bit of difficulty finding information about it online, I'll have to consult my architecture books at home, and will expand on the original post. Here's a bit of the info I could find about PAE weirdness on IA32.

https://www.kernel.org/doc/gorman/html/understand/understand005.html#sec: High Memory

The key quote:

PAE allows a processor to address up to 64GiB in theory but, in practice, processes in Linux still cannot access that much RAM as the virtual address space is still only 4GiB. This has led to some disappointment from users who have tried to malloc() all their RAM with one process.

Secondly, PAE does not allow the kernel itself to have this much RAM available. The struct page used to describe each page frame still requires 44 bytes and this uses kernel virtual address space in ZONE_NORMAL. That means that to describe 1GiB of memory, approximately 11MiB of kernel memory is required. Thus, with 16GiB, 176MiB of memory is consumed, putting significant pressure on ZONE_NORMAL. This does not sound too bad until other structures are taken into account which use ZONE_NORMAL. Even very small structures such as Page Table Entries (PTEs) require about 16MiB in the worst case. This makes 16GiB about the practical limit for available physical memory Linux on an x86. If more memory needs to be accessed, the advice given is simple and straightforward, buy a 64 bit machine.

...

I don't think you actually read what I wrote.

Also, season 5+ seemed to have a lot of everyone sleeping with everyone else. Amy and Bender, for example? Zap and Leela hooking up, Again?

Both of them are my posts. I meant Flanderization. I guess my writing just sucked today. :)

I think if you understand how truly horrifying PAE is, you would have no doubt at all that 64 bit platforms were the way to go. There's a lot of memory management cruft in the Linux kernel that x86_64 eliminates.

x86_64 also slipped in a few much needed enhancements to the ia32 architecture, including some extra general purpose registers.

http://en.wikipedia.org/wiki/X86-64

In Fact, TVTropes has an entire section of Flanderization dedicated to Futurama.

http://tvtropes.org/pmwiki/pmwiki.php/Flanderization/WesternAnimation

(Sorry in advance for your lost productivity.)