Re: HR is the problem
This sounds familiar, thanks for sharing.
2859 publicly visible posts • joined 6 Sep 2007
... to 2001 when IE6 was released and so many websites wanted to make a point that they no longer want to talk with IE4 or IE5. Now we have HTML5 universally supported by almost all browsers, and I frankly am fed up with web developers making a stance "No, we are special because something something something". No you bloody are not, you are just ignorant git!
Particularly good (bad?) example is Barclays banking - connect from Linux Opera or Firefox, current stable version, and it will suggest that my web browser is obsolete and I should use (possibly older, but hey, running on Windows!) versions of Chrome or ... Firefox. At the same time when trying to stuff 15 tracking cookies from 3rd parties on my computer - because it's only banking! Duh!
I didn't say interchangeable, just that they have common roots. Though they are indeed sufficiently similar that pretty-much anything from Apache 1.3 ...
That's not how copyright works. Also, Apache is nowhere in the picture because (back to topic) "Prior Art" does not apply in copyright cases - it only applies to patent law. Unless Russian IP law is somehow different?
I do not think the term "prior art" applies to copyright cases. Also, I very much doubt that nginx or lighthttpd could be described as "derived work" in relation to Apache, which is what you are implying. Sure, they implement largely overlapping set of protocols and have a module system, but I am quite certain that they are entirely independent projects - this claim is based on significant differences of server architecture.
Just nitpicking here: not "performance" but "capacity". For low latency trading, where raw power of every single core is paramount, hyperthreading will be typically disabled because it "only" increases capacity at the cost of performance (due to shared caches).
this++
It annoys the hell of me when people plan for using a single language only. There is no single language good for everything, so when you do that you are basically planning for fail. Also, programming languages are not really that different, so making assumption that one can only learn one language well is pretty demeaning to everyone involved.
By some interesting engineering and good marketing they have placed themselves as "the solution" for managing multiple WiFi access points, but there are simpler and cheaper solutions, which also work perfectly well without an extra PC or "the cloud". For example, I am using TP-Link AC50 for the few APs at home, while a slightly larger AC500 could be used for decent sized network.
There are two different issues here:
1. old kernels have bugs, all kinds of them. Many of the bugs are security holes. Embedded devices are built on some old, randomly selected kernel and never updated - so they "accumulate" (in a passive manner) security holes which are never patched. The same applies to Android phones which do not receive vendor updates, BTW.
2. some of the security bugs are not in the kernel; the patches in the kernel are just workarounds for security related bugs in the CPU hardware itself, e.g. timing attacks which can read one-bit-at-a-time from some hypothetically protected part of the address space. Computers are fast and one-bit-at-a-time can leak a significant amount of data e.g. a private key. The workarounds in the kernel come with performance overhead and also hit intel much more frequently than they do hit AMD. In particular, there either are no good workarounds for some security bugs related to Intel hyperthreading, or GKH is so fed up with merging those that he does not trust the whole edifice. Meanwhile, the equivalent AMD technology appears to be safe.