Does QT use xlib or xcb under the hood on X11 based systems. I ask because I would like to thread applications without worrying about the finicky nature of xlib when threading is involved.

Even a James bond villain would question of the ethics of CenturyLink.

And where are they getting the money?, They where at last I counted over $20 billion dollars in the hole, And Rackspace isn't large enough to be used as part of their leveraged buyout "WorldCom" esk scam.

AMD, and IBM have both been talking about stacked designs for cache memory, Intel has been a big player in HBM/FCRAM development, and AMD, ARM, and others are throwing a lot of weight behind HSA, even Intel is bringing in some of the idea's of HSA at least as far as unified cpu/gpu virtual memory address spaces are concerned. The next 2-3 years is going to be transformative for computing, languages and software libraries will need to catch up with not just with macro threaded concurrency, but also with micro threading concepts. The convergence of "large enough" caches something like Iris Pro but with real cache memory instead of edram, HSA making igpu a first class citizen(think if opencl had access to the programs heap/stack, aka being able to call virtual functions, checking type information, accessing arbitrary objects not directly passed in the functions parameter list), and hopefully HBM/FCRAM will finely catch memory speed up at least for a year or 2(it'ill never last but here's hope'n lol).

Really I don't get why everyone keeps referring to each other as a bundle of sticks, its very confusing.

Their are many pieces of the past that if works should not be destroyed, And even if they don't work, we can still very likely get parts off it. I personally would love to find an atari ST, atari falcon, Mac 128k, Amiga 600/1200, any of the atari 8 bit computers. It is a shame that so many of these fantastic pieces of hardware end up getting destroyed.

1 byte?, you have no idea what you are talking about. AMD64 has a prefix byte before first op code byte, so in 64bit mode no instruction is smaller then 2bytes, Also 64bit arm is a new instruction set, and it does not in any way resemble 32bit arm. The fact is 64bit ARM, looks much more CISC'y then 32bit ARM, providing access to multiple address modes for load instructions, integrating the SIMD instructions rather then using costly co-processor extensions, having lightly variable length instructions, dedicated stack register and access instructions, And in a huge break from prior arm instruction sets they drop the conditional execution instructions from the instruction set. And it manages to increase the register count from 16 to 32 to boot as well. ARM has a bright future, It is not forced to waste huge swaths of transistors on decoding stupidly scatter brained instruction encodings built from 40 years of stacking shit on top of shit.

This is common to private industry as well, the only major difference being the scale of the project. The government needs to define a process that maintains the chain of custody of important software, and this should be redundant. If multiple persons or organizations are charged with this activity, it is less likely that a death or corporate bankruptcy(or simple lack of interest in continuing the contract) will create the situation where you have 7 million lines of code that nobody employed or contracted have any idea how the bollacks it works. I would suggest a few policy changes to improve the situation, 1. retain the right to directly hire or offer contract to any person employed by a contractor developing software if for any reason that contractor should cease being the contract. 2. when contracting or even writing software in house, on large projects(anything projected to have more then say a million lines of code), also hire a second development house to review and file bug reports on the software, submitting a patch history to both the primary developer and the software owner/government. 3. as relates to point 2, the second development house, as part of their contract an option to make them the primary developer in the event that the original developer can not fulfill the needs of the work, or cease being the developer for any reason.

In most States "teacher unions, firefighter unions, police unions, etc." are paid out of income taxes, property taxes and property taxes. Sales tax generally go into State general funds, and are used non-road infrastructure, road infrastructure, back funding of income tax cuts, Medicaid, and frivolous lawsuits over things like nullification of federal laws(albeit in Utah the States School land fund is used for this)

If you ask me SpaceshipTwo has great potential, Anything that moves us away from using upside down roman candles to get off this rock is an improvement.

Their are so many things that effect student performance outside of the classroom. The child's home conditions, parent involvement, etc. Yes testing can provide a certain measure of understanding, but using test scores exclusively or even as a large part of an overall evaluation of a teacher is incredibly flawed.

Teachers in my state at least(Utah) just are not paid enough in the first place(25-35k per year), if people want to implement merit pay based on some "report card" developed by a bunch of ideological extremists(like say the Utah Legislature) the end result isn't going to be pretty. All the tests will be designed to fail teachers and schools to push charter school rent seekers and likely used as an excuse to push privatization schemes.

Who knows any kind of toys they have barred in the NSA, and DoD. And given the amount of money that flies through defense contracts wouldn't be hard to hide that in a small line item somewhere(likely next to that Wayne Tech justice league space station *wink*).

http://www.sandpile.org/x86/opc_enc.htm its a mess, with 64bit we have a prefix byte , 1 to 4 bytes for the op, mod byte, and above that with avx we have the DREX byte, potentially imm byte. etc. I see no reason why intermediates can't occupy the space the next instruction would have and be aligned to the size of the fixed instruction length. that one exception to the fixed size rule shouldn't cause that much trouble for decoding of instructions.

ARM like any risc chip is great for a particular level of complexity, for a particular application, or situation.

Basically predictions of RISC eating x86 for breakfast were made over 15 years ago and never came to pass. Mostly by x86 morphing so that the difference was essentially irrelevant.

Exactly. x86 might be a pain to decode, but the fact that you can replace the backend arch that actually does all the work with one that fits the particular level of complication desired means that x86 unlike ARM(or any risc for that matter) can scale from simple 8086 with 29,000 transistors to that of a westmere-ex with 2,600,000,000 transistors. and go from 8bit to 64bits, or with SIMD 256bit. when they added large caches throw in instructions for cache control/hinting. What is really needed is a fixed instruction length CISC arch with an opcode address space large enough for future expansion, a means to deprecate old instructions, keep x86 addressing(the 64bit model that is), and an ISA that is designed to be easily decoded into whatever the chip is really running.