Ask HN: Open-source commitment for commercial software? - <AUTHOR> Hi HN,
I write a bunch of open source software. I also make and sell closed source products. I'm a small shop and sometimes my clients worry about platform risk should I just decide it's no longer worth bothering to support the product I'm trying to sell them.
What I'd like to be able to do is put a clause in my standard EULA that says "If I ever stop offering this software on the market, I promise I'll give you the source under a BSD licence."
Is anyone aware of prior art in this space? I'd love to learn from history before trying it myself. <comment><USER3> There are a few others doing it, but I think it's a terrible idea. There's a lesson to be learned from the insurance industry on this one. You'd essentially be providing an insurance policy to your customers (i.e. the payout is source code to your application) when they have no insurable interest (i.e. the success of your business.) What this means is that they can benefit from your failure while having no actual interest in seeing you succeed. Perversely, if one of them wants the source code, then they _do_ have an interest in seeing you fail. They may not try to kill your business directly, but it can actually be against their interest to supply you with more business which would keep it worth your while / viable.

Instead, I'd suggest thinking about their concerns and come up with a mutually beneficial way to address them. If they're worried about you walking away from it, offer them a long term support arrangement with some legal teeth where there's enough $$$ involved to guarantee your continued engagement. Bus factor... meh, you're a one-person shop... if they want to mitigate that risk, have them pony up some money and you'll be happy to staff up. etc. etc.

<comment><USER4> We did a deal like this with a giant IT company with a 3 letter acronym for a name.

We had a "break glass" option. If the client wanted to take over the code, they had to pay us a prearranged amount. The actual amount in our case was about 2 x the lifetime revenue to us of the deal from memory.

This seemed to work well, they had insurance, but we knew that if they ever broke the glass we'd be laughing to the bank.

At one stage things got tetchy and we hoped they would break the glass - <USER2> they never did.

<comment><USER3> Something along these lines makes much more sense: the other party got the insurance they want, your company got a non-trivial payment in the event that they walk away against the customer's wishes. Both parties have incentive to make things work. That's very different than 'if we ever stop offering this product, we'll just open source it'

<comment><USER4> I think it works well for megacorp clients too. A future option for a few million dollars is way easier for them to get over the line than some strange, and intangible open source scenario, when they don't want the code ever open sourced anyway.

</comment></comment></comment></comment><comment><USER5> I was a founder at a company that faced this problem: small company, in Australia; big company clients, mostly on other side of the planet.

We added a source-code escrow clause to our contracts, and (the much bigger and more difficult part of the commitment) a bunch of steps to our release process.

Escrow is not just the source code: we had to include full instructions for building the software, lists of dependencies and their versions, etc, etc. With modern CI and declarative DevOps, this would be a lot simpler.

We originally just arranged this with our local Intellectual Property lawyer, who (to my surprise) was pretty well set up for this. For instance, one time we accidentally failed to include some files, and they noticed and called us to get the drop resent.

We were later forced to move to using Iron Mountain by a large client who wasn't happy within anyone else.

When we later discontinued that product (due to pivoting to a more specific market niche) one customer took advantage of their escrow rights to continue to build and maintain the software in house for many years.

From memory, we didn't try to enumerate the circumstances under which the escrow would be triggered too much: just saying something like "becomes unsupported". If it's really necessary, lawyers can sort out whether that's the case or not.

</comment><comment><USER6> Doesn't cover 'hit by a bus' scenario.

Worse, like escrow, there's no guarantee (or likelihood) that it will be in a state maintainable by the client (or by anyone).

Here's my idea: clubsource, opensource within the exclusive club of customers. They all get source, and are allowed to modify and freely share source with each other - but only with each other. It's not open source. If they did want to share it (e.g. with a trade-partner or subsiduary etc), they need a new license from you. i.e open source, within a club.

The benefit is that they have access to source, now; they can assess it; they can build expertise in maintaining it; they can customize it. And most important for you, they can band together in these endeavours, to either share the load, or for those clients most capable to maintain it (probably for consideration; consultants could also take on this role, by being licensed).

The big benefit for you (apart from overcoming this objection), is it can keep improving and producing sales without you (though people will resent this, unless you make it sufficiently-cheap at that point).

The downside for you is you can't screw them for updates or features or maintenance like an Oracle. And someone could easily copy it directly, or "reverse-engineer" it, and you couldn't really trace it.

<comment><USER7> This reminds me of the situation with regards to the unreal engine source code. It's "open", you can browse and contribute, but only after you agree to the terms which include agreeing to pay them when the time comes that you make money with it. The club in this case is everyone who agreed to their contractual terms.

</comment></comment><comment><USER8> I give the following promise [1] for my file manager:

 _If no commit is made to fman in more than 6 months, then it will be open sourced under a BSD license._

Commits are displayed live on the home page, so people can actually hold me to that promise.

1: [https://fman.io/blog/transparency/#open-source- promise](https://fman.io/blog/transparency/#open-source-promise)

<comment><USER9> I think this is a useful promise for customers.

But what happens when you disappear from the web, after you bought a tropical island ;). How are people going to get the source code? Do you use some escrow mechanism?

<comment><USER8> As I mention on the page I linked to above, my family (=brother) knows how to release the source code in case I disappear.

</comment></comment></comment><comment><USER10> It sounds like they are asking for software escrow. Iron Mountain and others offer these services. If required, you should pass the cost on to the client.

</comment><comment><USER11> I think prior art exists. As a specific example of a business that has solved this problem:

[https://www.opendesign.com](https://www.opendesign.com)

ODA offers several licenses of their CAD related data processing tools. The most expensive licence gives direct access to source and the right to compile the source, but strictly controls how that source may be used.

You may want to take a peek at their licenses. The source code is available at the most expensive 'Founding' tier:

[https://www.opendesign.com/join](https://www.opendesign.com/join)

The other alternative is software escrow but I would fathom you could just offer a premium license for full source code access and capture all that additional revenue yourself.

</comment><comment><USER12> I am doing this with searchcode server [https://github.com/boyter/searchcode- server](https://github.com/boyter/searchcode-server) which I wrote about here [https://boyter.org/2016/08/gpl-time-bomb-interesting- approac...](https://boyter.org/2016/08/gpl-time-bomb-interesting-approach- foss-licensing/) in short 3 years after a release is published the source at that time is licensed as GPL3. I did it like this to cover the hit by a bus, bored and such scenarios.

I did get some attention here [https://news.ycombinator.com/item?id=12459492](https://news.ycombinator.com/item?id=12459492) from the post at the time and have actioned on a lot of the feedback.

</comment><comment><USER13> See section 4.4 [https://drone.io/enterprise/license/](https://drone.io/enterprise/license/)

edit: section 4.4 provides a business discontinuation clause that specifies the source code will be released under an open source license if the business is discontinued. The clause was written by an attorney (not something I added myself).

</comment><comment><USER14> What caseyf said - this should be covered by software escrow, making an OSS commitment public is dangerous as it can put your IP at risk.

Though software escrow comes with added costs so it's really down to the individual contract.

<comment><USER15> > making an OSS commitment public is dangerous as it can put your IP at risk

How so?

<comment><USER14> You're staking your IP on the financial health of your company. If you have a promise to push OSS then you also provide motive for sabotage.

It sounds extremely paranoid, I know, but escrow is a much safer option because when you pass that on to the client it forces them to really commit as opposed to not caring if you go bust.

To put it another way: you get a commitment from them in terms of having to pay the fees for escrow, which is more than they would have to do if you made a public promise. That's a longer term commitment, so you can wrap that into a longer term deal, which in turn can help you stay sustainable for longer.

<comment><USER15> > It sounds extremely paranoid

Yeah, and a bit like FUD, too.

I'm still unclear how a public release would be any better for said saboteur, compared to code escrow where they could potentially be the sole beneficiary of it. If someone is willing to go to those lengths to get access to your code, do you expect an escrow fee is going to stop them?

</comment></comment></comment></comment><comment><USER16> Well that's a common risk that clients have to accept, and it's often what pushes them towards larger software consultancies.

The argument is that you may not be there next year and they'd be stuck in a hole with software out of date.

You could offer to commit 4 hrs per week on retainer in the maintenance mode of the software, later down the track. That gives you a retainer and gives them predictable cost. If the required changes are bigger than the allocated time per week (or they want it sooner) you'd have an hourly rate attached with it.

I always try to build relationships that last and not quick in/out software.

<comment><USER17> Off Topic but your profile has some kind of key and a visual representation (similar to SSH but not quite) What is that?

<comment><USER18> -

<comment><USER16> I wish you edited that with '42'.

</comment></comment></comment></comment><comment><USER19> Add a Clause in your contract that covers 2 scenarios:

1\. If YOU go out of business or cannot support the customer for any reason, they get access to the source code with a non-exclusive license.

2\. If THEY want to leave (as some others are pointing out in the thread, then they have to buyout the IP for a price. You can either negotiate the price upfront (make it worthwhile for you and high enough that it is not worth for them to do the buyout easily) or leave it open depending on how far along you went with that customer.

</comment><comment><USER20> That sounds like a lawyer question. IANAL, but I can see it being kind of complicated to try and come up with some clever licensing for customers you're not sure you'd like to support. What I've seen some companies so is make the core product AGPL and then offer a separate commercial license. Take a look at the source code for JFrog's Artifactory; I'm pretty sure they are duel licensed (but I'm on my phone & can't confirm at the moment).

</comment><comment><USER21> You could roll your own source code escrow with a "canary" where if you don't check in periodically...your client gets the key to decrypt a source tarball (with whatever licensing you want to put in it).

I can't vouch for it, but I found a tool that does this: [https://bitcannery.net/overview](https://bitcannery.net/overview)

</comment><comment><USER22> As others have mentioned, this is not uncommon at all, it's called software escrow.

For clients that need/want/demand this you can pass the cost onto them.

On your side, you do the work once in your build/CI to upload/FTP source and artifacts to the escrow agent and you're done.

</comment><comment><USER23> Here is a precedent that has been going on for ~20 years now: [https://www.kde.org/community/whatiskde/kdefreeqtfoundation....](https://www.kde.org/community/whatiskde/kdefreeqtfoundation.php)

<comment><USER24> This is the true example of this happening.

TrollTech -> Nokia -> Microsoft -> Digia -> Qt Company

Qt is still Free and Open Source under LGPL.

</comment></comment><comment><USER25> We and i mean i , because i do a lot of solo projects solved it this way. I drop on a regular base my latest sources at a notary, with a list of clients / software. When i might go bankrupt or die, they have access to the sources.

</comment><comment><USER26> This is largely forgotten now, but notch promised to open source Minecraft if it ever stopped selling.

Obviously it still sells today. He doesn't own it anymore and it's not a proper license like what you're asking. But it's a precedent.

</comment><comment><USER27> I've heard of code being put into escrow for similar reasons. Basically a guarantee because one man shops or even startups might be asking an enterprise to take a risk on them.</comment>


Ask HN: After becoming a parent, what perspectives changed for you? - <AUTHOR> Talking with a friend of mine I used the phrase "as a Dad...", which caught me off guard as I always had a strong negative reaction when hearing it before becoming a father.<p>What perspective changes have you noticed after becoming a parent? <comment><USER2> When my children were young I went through a short phase of worrying about dying. It seemed like a cloud would come over my brain and I was worried it would come one day and not leave. I have never experienced any type of anxiety like this before or after.

After some time I confided the problem with my wife. I was surprised by her reaction. She said, "you should be glad you are starting to feel normal things for the first time in your life".

Then the penny dropped. I had never been loved unconditionally in the way my wife and children loved me. It's not surprising to worry about being separated from such love. So to answer your question it was more like a brain re-wiring than new perspective.

25 years on I have a contenment about life and death. I hope my children will go on to do better things than I have done and that I can help them along the way.

</comment><comment><USER3> Three things for me have changed:

The first is my willingness to make sacrifices and the extent to which I've gone to make sure my children are safe.

The second is my view of what's important in life. While younger, money most definitely topped my list. Presently, being able to spend time with them is highest.

The other thing that I realize that has changed for me is the awareness that so few things are fixed.

I've seen how the kids try and fail, and try again. This helped me to realize that a lot of what I used to take as a given was in reality not. It's made me more curious and willing to experiment.

As they grow, more things will change in my life.

</comment><comment><USER4> The one that keeps on giving is doing things that a few years earlier I would have said "that's crazy I would never do that."

</comment><comment><USER5> For me, it's really changed my conception of what a proper adult/parent is. Well, I guess it's not _just_ personally becoming a parent, it's probably a mix of a whole bunch of things. When I think back to being younger, it seems to me now that I had quite a specific idea in my head of what "responsible" adults/parents should be. But once you've got a couple kids of your own, and are lucky enough to have several friends who are a decade or so ahead of you (so you can compare and contrast parenting styles, and their results), it's pretty tough to maintain this notion that there is a narrow range of "proper" behavior that you have to adhere to if you want your kids to turn out "right".</comment>


Intel fires warning shots at Microsoft, says x86 emulation is a patent minefield - <AUTHOR> https://arstechnica.com/information-technology/2017/06/intel-fires-warning-shots-at-microsoft-claims-x86-emulation-is-a-patent-minefield/ <comment><USER2> This marks a distinct shift for Intel. Historically, Intel's IP approach has focused on trade secrets, because they had a huge advantage in manufacturing and implementation techniques that are not easily reverse-engineered. Patent- protecting x86 didn't make much sense during the long period where nobody could make a general-purpose CPU as fast as Intel running native code, much less while emulating x86. As Moore's law has run its course, Intel's lead on that front has been shrinking. Apple's A10 is shockingly close to matching Kaby Lake on performance within a similar power envelope. And Ryzen is within spitting distance of Broadwell at the high end. All on non-Intel foundry processes. That was unimaginable 10 years ago.

<comment><USER3> That's the opposite of my impression of their history. Intel's approach to x86 historically has been asserting that it's basically impossible to implement a clone due to their patents, which they aggressively asserted to keep any competitors out of the market entirely if possible, and restricted to older ISA features if not possible. With the main exception of AMD, which was initially given patent licenses and tolerated in order to meet 2nd-source requirements. But even AMD they tried to strongarm out of the market later, leading to litigation where AMD eventually won a bunch of continued patent licenses only as part of the lawsuit settlement. Intel has also used patent lawsuits over the past 30 years to attempt to limit competition from Cyrix, Via, NVidia, and Transmeta, among others. Though they did lose or unfavorably settle a number of those lawsuits.

<comment><USER4> It's kind of difficult to believe this when the relevant architecture of today (x64) was developed by AMD. X86 is ancient, any patents that can't be avoided would have expired years ago.

<comment><USER5> I'm always surprised when I read this. How long do patents last? I'd always thought they were indefinite or like copyright.

<comment><USER6> No. Patents are generally valid for 20 years from the initial filing. The idea is that you get a limited term monopoly in exchange for making the details of an invention public.

</comment></comment></comment></comment></comment><comment><USER7> Attorneys on both sides must be excited on some level about the potential number of billable hours it'd take to litigate a case like this. Reminds me of a something an entrepreneurship professor told me...

If there's one lawyer in town, they drive a Chevrolet. If there are two lawyers in town, they both drive Cadillacs.

<comment><USER8> To be fair Intel has done a lot of work to make the x86 as great as possible. Patent lawsuits are awful. I'm not sure just copying someone's technology and emulating it without paying a license fee is all that great either.

My guess is this is all just negotiation from Microsoft's point of view and they are just trying to get Intel to license the ability to emulate x86.

Another possibility is this is a way to get Intel to invest more resources ( even at a loss) into competing with ARM.

<comment><USER9> Emulation is only an implementation of the ISA. The x86 _ISA_ is hardly "as great as possible". In fact, it's downright crummy: x86-64 is as bloated as RISC architectures usually are without any of RISC's benefits. At best you can make the argument that x86 has done well _in spite of_ the ISA, not because of it.

The silicon-level implementation is another matter entirely, of course--but emulation has nothing to do with that. In fact, that's the definition of emulation--using a completely different implementation to offer a compatible interface.

<comment><USER2> x86-64 is a perfectly acceptable ISA. Strong memory ordering, no architectural optimizations leaking out like branch delay slots or stack windows. Pretty good i-cache efficiency through the use of two-address code and memory operands. Of course, Intel didn't have much to do with it. Most of it is either an accident of history or the work of AMD, who a lot of work regularizing the ISA in the 64-bit transition.

<comment><USER9> 1\. Yeah, ARM has one nasty architectural optimization leaking out: the program counter register being 8 bytes ahead of where it should be due to pipelining. Thankfully that got fixed up in AArch64, and if 32-bit mode gets dropped down the line (which is allowed by the architecture) it'll be a thing of the past. x86 has some architectural leaks too, though: the aliasing of the MMX and FP stacks as a hack for compatibility with early versions of Windows comes to mind. This one hasn't been fixed.

2\. The REX prefixes are a nightmare: most instructions have one and this tremendously bloats up the instruction stream size. For this reason, the i-cache efficiency is _not_ good compared to actual compressed instruction sets such as Thumb-2 (not that Thumb-2 is wonderful either). Note that if you do extreme hand-optimization of binary size, you can get x86-64 down pretty far, but so few people do that that it doesn't matter in practice.

3\. Two address code isn't necessarily a win, especially since it doubles the number of REX prefixes. In AArch64 "and x9,x10,x11" is 4 bytes; in x86-64 "mov r9,r10; and r9,r11" is 6 bytes (and clobbers the condition codes). There's a reason compilers love to emit the three-address LEA...

4\. Memory operands are nice, though I think the squeeze on instruction space makes them not worth it in practice. I'd rather use that opcode space for more registers.

5\. Immediate encoding on x86-64 is crazy inefficient. "mov rax,1" is a whopping 7 bytes.

<comment><USER10> Regarding 5, no, it's five bytes (b8 01 00 00 00) for movl $1,%eax. If you actually have a 64-bit immediate, just the immediate itself would be 8 bytes, and the actual instruction is 10 bytes.

<comment><USER11> MOV RAX, 1 is seven bytes: 48 C7 C0 01 00 00 00

<comment><USER9> The parent has a good point actually, because "mov eax,1" automatically zero- extends in 64-bit mode.

It's still one byte longer than the equivalent AArch64 instruction, though.

<comment><USER10> Fine. If you are really into getting the shortest instruction, try "xorl %eax,%eax" then "incl %eax" which is four bytes (31 c0 ff c0).

<comment><USER12> push $1/pop %eax (6a 01 58) is shorter, but perhaps not the best idea.

<comment><USER13> Actually, there is no 32-bit pop instruction in x86-64 mode. Your code won't work.

<comment><USER12> You're right: it should be pushq $1/pop %rax (which is also three bytes, although there will be a prefix byte for registers r8 through r15).

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> The article mentions Cyrix as a "victim" of Intel patent defense; however, Cyrix not only won their lawsuits, but they also went after Intel for patent violations in the Pentium Pro and Pentium II processors.

[https://en.wikipedia.org/wiki/Cyrix](https://en.wikipedia.org/wiki/Cyrix)

[http://law.justia.com/cases/federal/district- courts/FSupp/84...](http://law.justia.com/cases/federal/district- courts/FSupp/846/522/1687321/)

<comment><USER15> You can win a lawsuit and still lose so much time and money on the way that you are worse off afterwards.

Vice versa you can cause your opponents so much trouble with lawsuits that - even though you don't win them - you are better off than them afterwards.

<comment><USER16> But Microsoft is bigger than Intel. So if anything, they will cause trouble to Intel.

<comment><USER15> Both can afford to spend hundreds of millions on a lawsuit. The lawsuit will be only a part of the budget for both and non-existential. So I don't think that the size matters here.

It would be different if the lawsuit is so expensive that one party could go bankrupt due to it.

This isn't about right and wrong. It's about money. Who has to pay how much to the other party? Both parties think they are better off if they fight. Both parties think they could win money in the end. It's a gamble in the courtroom.

<comment><USER17> The stakes could potentially present an existential risk to Intel. Imagine if Microsoft won and transitioned all Windows customers to ARM. That would be a huge blow to Intel's market!

</comment></comment></comment></comment></comment><comment><USER18> Years ago, I spoke with an attorney with a CS background. He had once worked on a case like this. Sharp guy. He didn't tell me the parties involved, and I didn't ask, though I assume he wouldn't speak openly about it while it was ongoing. I therefore don't know how it turned out. It was many years ago, so I might be remembering wrong. I'm not a lawyer, this is not legal advice (neither mine nor his).

Basically, there are two approaches the plaintiff might take here. The simplest is to cite the doctrine of equivalents[1]. This is basically the notion that if you do the same thing in the same way for the same purpose, then it's the same process, even though you are using digital instructions instead of logic gates. The legal theory here is pretty well settled. The problem is that you'd need to justify that digital instructions are obviously equivalent to logic gates, and a skilled professional would have equated them at the time of the patent's filing.

The other approach is to argue that an emulator actually is a processor, and therefore fits the literal claims of the patent. The explanation for this is pretty well-established: it's literally the Church-Turing Thesis[2]. However, the viability of this argument depends on the language of the patent claims. Also, it's hard enough to explain the C-T Thesis to CS students. My undergrad had an entire 1-credit-equivalent course that basically just covered this and the decidability problem. Explaining it to a judge, who (while likely highly intelligent) probably has no CS background, over the course of litigation is likely to be _really_ hard.

Now, Intel certainly has enough resources to do both of these things (and they may also have precedent to cite, that didn't exist back then or that wasn't relevant to that case). Don't take this as an opinion on any possible result, it's just information such as I remember it.

[1]- [https://en.wikipedia.org/wiki/Doctrine_of_equivalents](https://en.wikipedia.org/wiki/Doctrine_of_equivalents) [2]- [https://en.wikipedia.org/wiki/Church%E2%80%93Turing_thesis](https://en.wikipedia.org/wiki/Church%E2%80%93Turing_thesis)

<comment><USER19> if it's Church Turing you're arguing, then Intel surely doesn't hold the patent on the whole equivalence class...

<comment><USER18> The argument is that anything with that equivalence is a processor, which means an emulator is a processor, which means that any patent thats mentions the word "processor" (or equivalent) covers the emulator if it would cover the emulated device. The argument is not that the patent covers all processors.

<comment><USER19> that's not the church turing thesis then.

<comment><USER18> You're right that it expands upon the C-T thesis a bit, so my use of the word "literally" was incorrect. It does depend on the C-T thesis though, because it relies on a definition of "processor" that references it. You'd still need to explain it to a judge.

<comment><USER19> What do you mean when you say "expands upon"? Either all computers are equivalent or you aren't invoking C-T.

</comment></comment></comment></comment></comment></comment><comment><USER20> Patents expire after 17 years and x86 is 39 years old, so any of the original patents must have expired twice over already.

They no doubt have been filing additional patents over the years. But I'm sure MS and Qualcomm have plenty of their own patents to bargain with.

Also their warning could backfire if it gives Microsoft one more reason to finally walk away from x86 compatibility... not that this is likely to happen anytime soon.

<comment><USER21> TFA specifically mentions SSE, AVX, TSX, and SGX. All of those have had new features added in the last year or two.

<comment><USER22> Intel implements a thing, say SSE and AVX which were pioneered by Cray 20+ years earlier. So arguably, they took out of patent protection technology and applied it to X86. This is exactly how the patent system was designed to work.

I would argue that what they _don 't_ get is a defacto monopoly on the use of vector instructions for X86. Even that specific encoding. Because it is now an issue of compatibility and interoperability. The history of closing an instruction set from the patenting of a self few instructions is atrocious. Millions of entities have expressed solutions to their problems in X86, having to pay a tax to Intel in-perpetuity because of that is bullshit.

</comment></comment></comment><comment><USER23> Can someone explain this:

> AMD made SSE2 a mandatory part of its 64-bit AMD64 extension, which means > that virtually every chip that's been sold over the last decade or more will > include SSE2 support. [...] That's a problem, because the SSE family is also > new enough—the various SSE extensions were introduced between 1999 and > 2007—that any patents covering it will still be in force.

AMD64 requires SSE2 which was introduced in 2001, right? So isn't it just 1 year until Microsoft can put in what's required for the AMD64 architecture?

<comment><USER24> Worth noting that Microsoft's emulator is only emulating x86, not AMD64 (at least not yet)

<comment><USER23> I definitely didn't know. Are you sure about this/do you have a link?

<comment><USER24> Yeah, it's been mentioned in all the posts. I assume it was enough work just to get x86 working, and there's almost no 64-bit-only Windows software (certainly nothing you would want to run emulated).

"only 32-bit x86 support is being offered"

[http://www.anandtech.com/show/10889/microsoft-and- qualcomm-b...](http://www.anandtech.com/show/10889/microsoft-and-qualcomm- bring-windows-10-to-snapdragon-processors)

<comment><USER23> Wow, you're right, I totally missed that. Thanks!!

</comment></comment></comment></comment></comment><comment><USER25> Intel will not threat Microsoft, not even indirectly, in my opinion. Rationale: once Apple starts shipping desktops and laptops with ARM chips, the only safe port for the expensive x86 chips would be Microsoft (desktop and server market) and big iron on Linux/Unix/Hypervisors.

</comment><comment><USER26> So they will ban all virtual machines which sometimes have to go for emulation, e.g. to handle XSAVE?

Scorched earth policy will likely not be defensible under fair use law. Reverse engineering for compatibility has a few precedents.

<comment><USER27> Patents may be selectively enforced, there's no forfeiture as there is with trademarks.

Intel had (and has) no issue with qemu or bochs emulating everything, as long as they were niche and/or promoting the Intel platform (and grudgingly accepting compatibles).

However a move to rid Microsoft's platform from Intel altogether without compromising compatibility is something worth fighting for. I heard that ARM is rather similar in that aspect: emulators for development are a-ok, but trying to run ARM emulation on a consumer product with no ARM components inside will drive up the legal fees until some licensing agreement is set up.

<comment><USER28> Intel uses that for their x86 Android devices - and as far as I know, ARM did not sue.

<comment><USER29> Intel also makes arm processors (a cortex a5 i think?); perhaps they do license it.

<comment><USER26> Licenses can be revoked, patents cannot other than by analysis and finding them invalid.

<comment><USER27> As soon as Intel licenses the ARM ISA for each device, ARM Ltd. probably doesn't care if it's implemented in silicon, software or expressive dance.

</comment></comment></comment></comment></comment></comment><comment><USER30> Well, since x86 is a monopoly ... Intel oughta go easy on this one.

<comment><USER31> Intel would argue (semi-sanely) that there's no monopoly on CPUs. You can make your own mips, arm, it even Risc-V CPUs.

Also that they cross license x86 with competitors.

<comment><USER27> Were there any new licensees in the last 15 years?

Nvidia reportedly had issues getting the necessary paperwork: [https://en.wikipedia.org/wiki/Project_Denver#History](https://en.wikipedia.org/wiki/Project_Denver#History)

<comment> amiga-workbench How very convenient, Denver would have pooped all over Intel's Atom offerings at the time.

</comment></comment></comment></comment><comment><USER32> An earlier discussion here had most people guessing it was Apple, not Microsoft, that Intel was lobbing the threat at. [https://news.ycombinator.com/item?id=14518189](https://news.ycombinator.com/item?id=14518189)

<comment><AUTHOR> I apologize; I did a brief search before submitting but did not see that one.

</comment></comment><comment><USER33> > And Intel's business health continues to have a strong dependence on > Microsoft's business, which has to make the chip firm a little wary of > taking the software company (or its customers) to court.

I mean, Apple and Samsung had a billion dollar lawsuit while Samsung chips were still in iPhones. It's certainly precedented to sue a corporation you're actively doing business with.

<comment><USER34> They had contracts so Samsung was bound and Apple did start using their own chips, so it's not at all certain that the law suit didn't further disturb the business relation.

<comment><USER29> I believe their chips continue to use samsung fabs today.

<comment><USER26> If GlobalFoundries didn't make these chips, Intel could pick up the slack... (Not to mention it is a consortium and not part of Samsung.)

<comment><USER35> Intel doesnt let anyone else use their fabs.

<comment><USER36> sure they do, Intel manufactured FPGAs for a long time before buying altera

<comment><USER35> I don't think FPGA's count in this context but I did a quick search on Intel fabs and it looks like I'm wrong anyway: [https://arstechnica.com/gadgets/2016/08/intel-will-allow- arm...](https://arstechnica.com/gadgets/2016/08/intel-will-allow-arm- chipmakers-to-use-its-10nm-manufacturing-process/)

</comment></comment></comment></comment></comment></comment></comment><comment><USER37> I would personally be pleased if the millstone of the x86 instruction set sank both Intel AND microsoft's hegemony.

</comment><comment><USER38> I remember IBM having a contract with Intel to allow other chip companies to make x86 chips in case Intel could not keep up with demand.

QEMU emulates X86 chips as does other emulators. I wonder how those are effected?

<comment><USER39> AFAIK white box emulation has been around forever. I'd be surprised if it isn't already worked out in the courts, since this has been happening since before computers were around.

<comment><USER40> I don't think Intel wants to waste resources (and get bad PR) if it isn't a significant threat to their bottom line. Microsoft saying they are going to emulate x86 on ARM with low overhead (and thus making it possible to switch to ARM and still use tons of legacy software) is a much bigger danger to them.

<comment><USER32> Isn't there some notion that you have to actively defend a patent to enforce it? That is, something where selective enforcement puts you in a weaker legal position?

Edit: The legal term appears to be "the doctrine of latches"

<comment><USER41> _doctrine of laches_ [1]

However, the Supreme Court has recently (March) said that laches is no defense to patent infringement. [2]

[1] [https://en.wikipedia.org/wiki/Laches_(equity)](https://en.wikipedia.org/wiki/Laches_\(equity\))

[2] [http://www.ipwatchdog.com/2017/03/22/supreme-court-says- lach...](http://www.ipwatchdog.com/2017/03/22/supreme-court-says-laches-no- defense-patent-infringement/id=79750/)

</comment></comment></comment></comment></comment><comment><USER42> Alright, I'll come out of retirement to hit this dead horse another lick.

"if WinARM can run Wintel software but still offer lower prices, better battery life, lower weight, or similar, Intel's dominance of the laptop space is no longer assured."

Peter. My man. I laughed. I cried.

For the millionth time, the ARM ISA does not magically confer any sort of performance or efficiency advantage, at least not that matters in the billion+ transistor SoC regime. (I will include some relevant links to ancient articles of mine about magical ARM performance elves later.) ARM processors are more power efficient because they do less work per unit time. Once they're as performant as x86, they'll be operating in roughly the same power envelope. (Spare the Geekbench scores... I can't even. I have ancient published rants about that, too).

Anyway, given that all of this is the case, it is preposterous to imagine that an ARM processor that's running emulated(!!!) x86 code will be at anything but a serious performance/watt disadvantage over a comparable x86 part.

This brings me to another point: Transmeta didn't die because of patents. Transmeta died because "let's run x86 in emulation" is not a long-term business plan, for anybody. It sucks. I have ancient published rants on this topic, too, but the nutshell is that when you run code in emulation, you have to take up a bunch of cache space and bus bandwidth with the translated code, and those two things are extremely important for performance. You just can't be translating code and then stashing it in valuable close-to-the-decoder memory and/or shuffling it around the memory hierarchy without taking a major hit.

So to recap, x86 emulation on ARM is not a threat to Intel's performance/watt proposition -- not even a little teensy bit in any universe where the present laws of physics apply. To think otherwise is to believe untrue and magical things about ISAs.

HOWEVER, x86-on-ARM via emulation could still be a threat to Intel in a world where, despite its disadvantages, it's still Good Enough to be worth doing for systems integrators who would love to stop propping up Intel's fat fat fat margins and jump over to the much cheaper (i.e. non-monopoly) ARM world. Microsoft, Apple, and pretty much anybody who's sick of paying Intel's markup on CPUs (by which I mean, they'd rather charge the same price and pocket that money themselves) would like to be able to say sayonara to x86.

The ARM smart device world looks mighty good, because there are a bunch of places where you can buy ARM parts, and prices (and ARM vendor margins) are low. It's paradise compared to x86 land, from a unit cost perspective.

Finally, I'll end on a political note. It has been an eternity since there was a real anti-trust action taken against a major industry. Look at the amount of consolidation across various industries that has gone totally uncontested in the past 20 years. In our present political environment, an anti-trust action over x86 lock-in just isn't a realistic possibility, no matter how egregious the situation gets.

So Intel is very much in a position to fight as dirty as they need to in order to prevent systems integrators from moving to ARM and using emulation as a bridge. I read this blog post of theirs in that light -- they're putting everyone on notice that the old days of antitrust fears are long gone (for airlines, pharma, telecom... everybody, really), so they're going to move to protect their business accordingly.

Edit: forgot the links. In previous comments on exactly this issue I've included multiple, but here's a good one and I'll leave it at that: [https://arstechnica.com/business/2011/02/nvidia-30-and- the-r...](https://arstechnica.com/business/2011/02/nvidia-30-and-the- riscification-of-x86/)

<comment><USER43> You seem to be assuming that the scenario here is that the system will mostly run x86 code in emulation. But it's not the case - on mobile devices, most of the time it will run native ARM code, and most of the time that code will be the browser. Then, of course, most apps from Windows Store will also be native ARM. Emulation is there for that occasional desktop app that users _need_ \- and which made Windows RT non-viable - but which they don't actually use all the time. It's the 20% case, and if that 20% uses as much (or even more) power as a native Intel device, that's perfectly acceptable.

<comment><USER42> Nope, I'm not assuming that in the slightest. In fact, I'm assuming exactly what you're assuming -- some fraction of time way less than 50% spent running emulated code. I'm also coming to the same conclusion you are -- that emulation of legacy x86 code with Good Enough performance could be used as a bridge off of x86. Reread the post.

But let me address this specifically:

"It's the 20% case, and if that 20% uses as much (or even more) power as a native Intel device, that's perfectly acceptable."

There's no need to speculate, here: the emulated code either will use significantly more power, or it will perform significantly worse.

In fact, as for the native ARM code on the ARM chip, it also will either use more power or perform worse than comparable x86 code running natively on an Intel chip within the same power envelope, because Intel has thrown a massive amount of engineering at their microarchitectures and manufacturing process, they have vertical integration that they can use to their advantage, and their stuff is just very good.

Again, there are no magical ARM performance elves lurking under the hood -- the ARM ISA by itself doesn't confer any real advantages in performance (and hence performance/watt) in the billion+ transistor regime. I truly don't understand why this is so hard for people to accept, but I blame Apple for spreading years of FUD about x86 (before bailing on "RISC" for it, of course).

Back to the topic of the emulated code, though: I can't say is whether "significantly worse" or "significantly more power" will still be Good Enough, but I'm assuming it will for most apps people care about.

<comment><USER42> Again, it has been over 20 years since ISA has mattered for performance in a head-to-head matchup between comparable CPUs. Moore's Law has thoroughly done away with it as a factor in performance. Relative code size (and cache/memory space + bus bandwidth) of RISC vs CISC, "x86 tax" of translating into micro-ps as a percentage of the die area, register file size, load/store, and everything else you can think of have all fallen away as real performance factors as transistor counts have soared and compilers have improved.

There are so many things that matter for performance now, and ARM vs. x86 ISA just isn't anywhere on that list, and hasn't been on it for a very long time.

</comment></comment></comment></comment><comment><USER44> For anyone interested, here's a Microsoft Channel 9 video in which they talk about some of the x86 emulation layer internals:

[https://channel9.msdn.com/Events/Build/2017/P4171](https://channel9.msdn.com/Events/Build/2017/P4171)

</comment><comment><USER45> Logically this implies that I can't execute some i386 binary that I possess without infringing Intel patents.

I think this theory of infringement has to run into various thought-experiment problems such as : can I auto-translate that binary into some other instruction set, then execute the translated binary, without infringing Intel patents? (yes, surely) Is the translator now infringing Intel patents because it has to understand their ISA? (no, surely).

Now, can I incorporate that translator into my OS such that it can now execute i386 binaries by translating them to my new instruction set which I can execute either directly or by emulation? If so then I am now not infringing. Or did infringement suddenly manifest because I combined two non-infringing things (translator + emulator for my own translated ISA)?

<comment><USER46> If you execute your i386 binary on an Intel, AMD, or other licensed processor, then you're protected by the doctrine of exhaustion:

[https://en.wikipedia.org/wiki/Exhaustion_of_intellectual_pro...](https://en.wikipedia.org/wiki/Exhaustion_of_intellectual_property_rights)

If you execute it in an emulator, though, all bets are off...

<comment><USER24> Here's an insane idea--what if every Win10 ARM laptop also included a Pentium 4 or Athlon XP chip (from a junked PC) glued inside the case? Would the x86 patent rights from that chip cover an emulator running on the ARM?

(I'm pretty sure it's a no, but an Aereo-esque lawsuit arguing the opposite would be fun to watch)

<comment><USER47> No more than wearing an Intel t-shirt would give you rights to all their patents.

</comment></comment></comment></comment><comment><USER48> It will be interesting to see how this strategy fares in the US, given the Alice ruling which made it much harder to patent methods that were purely software.

Intel's strategy of going after other hardware companies may not translate neatly to emulators.

</comment><comment><USER49> How did I not already know Microsoft had a working x86 emulator.. this is a massive game changer for the laptop space if it's fast and reliable enough, as afaik ARM chips are so much more power efficient for similar perf

<comment><USER50> There are several existing and excellent x86 emulators floating around. In the open source space, QEMU is quite fantastic and well supported. I'm not surprised at all that Microsoft managed to either develop one in house, or acquire one.

x86 is an old and _very_ well understood architecture at this point. The difficulty thus isn't in writing a working emulator, it's in figuring out which features you can support from a business perspective without treading on still active patents. Microsoft is one of the few companies that can probably absorb a patent fight here and come out on top, and if they succeed, it will counter-intuitively threaten the continued dominance of x86. Once they can release an ARM-based version of Windows that sports backwards compatibility (the primary missing feature that caused Windows RT to fail spectacularly) more mobile machines will be free to use ARM chips, and software developers will have incentives to natively support ARM targets for power efficiency reasons.

Since Intel banks on x86 continuing to be the dominant architecture in the desktop and laptop space, they must feel threatened by this move, so the suit doesn't surprise me. They'll now be fighting an uphill battle. On the one hand, Intel processors are still pretty much king in raw performance, but on the other hand, very few consumers actually need the kind of performance that you can only get on Intel chips anymore. A decent web browser runs on just about anything, so an architecture shift in the consumer space is quite plausible. Some could argue that it's already happened with tablets.

<comment><USER51> The huge tech thing here is that running Windows-on-ARM you can run x86 programs which can then call into the Windows-on-ARM OS. So no need to virtualize the OS

<comment><USER35> Dynamic binary translation is not exactly a huge tech thing.

</comment></comment></comment></comment><comment><USER52> [https://blogs.technet.microsoft.com/mmpc/2017/06/07/platinum...](https://blogs.technet.microsoft.com/mmpc/2017/06/07/platinum- continues-to-evolve-find-ways-to-maintain-invisibility/)

[https://news.ycombinator.com/item?id=14515381](https://news.ycombinator.com/item?id=14515381)

</comment><comment><USER53> Keep in mind the most relevant instruction set is the X86-64 instruction set (32 bit code is not very relevant these days). The x86-64 ISA was created by AMD, not Intel. Intel was busy trying to milk the enterprise market with the Itanium, trying to reserve 64 bit as an enterprise feature.

<comment><USER54> That is not true on Windows, where most software is either 32 bit only, or both 32 and 64 bit. In fact, for many software on Windows, the 64 bit port is considered beta versions.

<comment><USER55> > In fact, for many software on Windows, the 64 bit port is considered beta > versions.

That's probably due to Microsoft's choice of keeping both "int" and "long" as 32 bits while pointers increased to 64 bits, unlike everyone else which kept "int" as 32 bits and increased "long" to 64 bits. If any part of your program stored a pointer in a "long", it would break when the memory allocator gave you an address above 4G. You have to carefully comb your code to change the relevant variables to things like LONG_PTR (which isn't a "long" on 64-bit Windows) instead.

Storing a pointer in a long is probably common in 32-bit Windows, since window messages have a pair of parameters, WPARAM (which, despite its name, was an "int") and LPARAM (which was a "long"); pointers are often passed in LPARAM.

<comment><USER43> Most Windows apps don't deal directly with things line LONG_PTR and window procs - they just use a framework, and frameworks have been updated to do this all correctly a long time ago (this migration started in early 00s, when Windows on IA-64 appeared).

The main reason these days is that there's simply no strong incentive to go 64-bit for most desktop software. The 2Gb memory limit is a non-issue for most scenarios, and other than that, why bother? If you compile and test for 32-bit, it works for anyone who is still on 32-bit Windows _and_ it works for 64-bit. And recompiling for 64-bit is usually easy, but it doubles your test matrix - so "here's a build, but there's no official support" is not an unpopular approach.

</comment></comment></comment></comment><comment><USER56> Another component of Microsoft getting off Intel is that the antitrust settlement only applied to x86 hardware, so MS getting off x86 would let them lock down the platform and do all their dirty tricks all over again.

</comment><comment><USER57> May someone please elaborate on the difference between what MS does and emulators on Linux like Quemu and ExaGear?

<comment><USER46> The difference, as it pertains to the patent issue, is nothing technical - it's simply that Intel feels threatened by Microsoft's emulator and not by qemu. (Though if Intel has ever redistributed qemu, there may be an additional GPL wrinkle...)

<comment><USER58> Intel contributes to qemu (or at least, developers with @intel.com email addresses contribute). However AFAIK they don't contribute to the emulation code (TCG).

</comment></comment></comment><comment><USER59> Another reason Microsoft should be telling ISVs to recompile for Win32 on ARM instead of binary emulation.

</comment><comment><USER60> IBM sold an x86 translation for a while [https://en.wikipedia.org/wiki/PowerVM_Lx86](https://en.wikipedia.org/wiki/PowerVM_Lx86). Would be interesting to know why it was discontinued.

<comment><USER24> That is odd. IBM bought Transitive and owns the tech (so no ongoing license fees to pay) and I would thimk that x86 binary support for POWER would still be a useful migration tool.

</comment></comment><comment><USER61> If AMD can implement x86 in hardware, why can't Microsoft implement it in software?

<comment><USER62> AMD has a (non-transferable!) license to do so.

<comment><USER15> I wonder if this kept AMD alive during the hard times.

x86 isn't going away for the next 10 years or longer.

<comment><USER63> Yup, Intel literally needs a competitor to keep out of hot-water with regards to anti-trust laws.

</comment></comment></comment></comment><comment><USER64> Windows still has a HAL, makes me wonder why Microsoft don't just cut a new HAL for the ARM.

It's quite possible I'm missing something vital here, of course.

<comment><USER65> They have a HAL for ARM, this is to allow x86 programs to run on top of that HAL. That's what Intel is attacking.

</comment></comment><comment><USER66> Anyone know if it is an emulator, or an on-demand isa translator that operates at runtime? I wonder what the implications are for infringement.

</comment><comment><USER67> I'll just sit hear eating my popcorn and waiting for a lowRISC computer I can buy.

<comment><USER68> Can't see it happening in the next decade.

However, if you're interested in embedded hardware, you can buy a RISC-V chip from SiFive now.

[https://www.sifive.com/#](https://www.sifive.com/#)

<comment><USER67> Next decade?! That long???

<comment><USER68> Yes.

x86 is dominant for desktops/laptops. ARM is starting to make inroads with Chromebooks and covers the low end. RISC V is starting from scratch, both in terms of available hardware and software support. If RISC V can quickly prove popular in the embedded space then perhaps we'd see a desktop/laptop earlier than in a decade, but it's a competitive market.

To give a comparison, MIPS is popular in the embedded space, but how many MIPS-based laptops have their been? Very few.

<comment><USER67> but, lowRISC says they are going to crowdfund a SOC this year... let's say it takes them 2 years to have one I can buy, I should be able to have a RISC V based computer that can run linux within 5 years! Am I dreaming?

<comment><USER68> lowRISC are currently on v0.4 of their design, and we're already half way through the year. I'd be very surprised if they decided to commit to building an ASIC before they reached v1.0.

[http://www.lowrisc.org/blog/2017/06/lowrisc-0-4-milestone- re...](http://www.lowrisc.org/blog/2017/06/lowrisc-0-4-milestone-release/)

By the way, I'm not trying to stop you dreaming, I'm hinting the fact that if you want to speed things along you should get involved in the embedded space. If you're waiting as a passive consumer you'll more than likely get disappointed, but if you're actively contributing to the platform you may find the wait more bearable as you're helping to speed it along.

</comment></comment></comment></comment></comment></comment><comment><USER69> Everything Intel have said and put forth are Hardware companies. I can't believe anyone can be sued for software emulation of x86.

And unless Qualcomm and Microsoft are working on a Hardware assisteed X86 emulation, this warning shot may be directed at somebody else.

My guess: Apple.

</comment><comment><USER70> I was just watning about fhis on anothet thread. It's not competition if it requires compatibility with patdnt-protected ISA or microarchitectures. It's coercion.

</comment><comment><USER71> So Intel is so scared of little ol' ARM (compare their revenues) that it's willing to use patents to take it out of the PC market, rather than compete on technical grounds?

Okay, got it. I'll make sure to account for that in my next CPU/device purchase.

<comment><USER72> Intel vs ARM revenue is not an apples-to-apples comparison, since the former makes chips and the latter only licenses designs.

</comment></comment><comment> dis-sys best outcome I can think of:

AMD licenses x86 patents to Qualcomm/MS to make x86 emulator better patent troll proof. In return, Qualcomm and AMD team up for better ARM server based processors. MS can sell more Windows/Windows Sever (sad).

<comment><USER73> It's a non-transferable license.

</comment></comment><comment><USER74> Microsoft should Partner with AMD to pressure the big desktop and laptop OEM's to stop using Intel CPU;s

I would love to see Dell, Lenovo and HP to switch exclusivly to Ryzen processors,

And switch to the new Naples CPU in all their Server/Storage systems</comment>


Books geeks should read to their kids - <AUTHOR> http://www.wired.com/geekdad/2012/04/67-books-every-geek-should-read-to-their-kids-a-printable-list-rewind/

<comment><USER2> Saving you two clicks: [http://www.wired.com/geekdad/wp- content/uploads/2012/04/67-B...](http://www.wired.com/geekdad/wp- content/uploads/2012/04/67-Books-Every-Geek-Should-Read-to-Their-Kids-Before- Age-10.pdf)

</comment><comment><USER3> I'd throw in _The Great Brain_ [1] books, any of the _Tom Swift Jr._ [2] books, the _The Three Investigators_ [3] books, and the _Encyclopedia Brown_ [4] series.

Edit:

Remembered a few other suggestions... Pretty much anything by Jules Verne, especially _The Mysterious Island_. Definitely some HG Wells, and definitely some _Choose Your Own Adventure_ books (anybody remember _The Cave of Time_?)

Glad to see _A Wrinkle in Time_ and _The Mad Scientists Club_ on the list. Those were awesome reads as a kid.

[1]: <http://en.wikipedia.org/wiki/The_Great_Brain>

[2]: <http://en.wikipedia.org/wiki/Tom_Swift,_Jr>.

[3]: <http://en.wikipedia.org/wiki/Three_Investigators>

[4]: <http://en.wikipedia.org/wiki/Encyclopedia_Brown>

</comment><comment><USER4> No Jules Verne?

I guess he's not very popular in the states, and thus my Soviet upbringing is showing, but I can't imagine growing up without him. I learned pretty much all of the geography that I know from him.

<comment><USER5> Verne suffers from a lack of good translations in English. Most of them are abridgments of public domain Victorian translations. They get the science wrong, they introduce British 19th-century racism, they rename characters for no reason (Axel -> Harry, Lidenbock -> Hardwigg), and they eliminate Captain Nemo's anti-British rant because after all, he's a wog.

That being said, no child's education is complete without "Around the World in 80 Days" and "Journey to the Interior of the Earth."

<comment><USER6> I had no idea - that's fascinating. Do you know of any translations that don't have those problems?

<comment><USER5> There's a F.P. Walter translation of "20,000 Leagues Under the Sea" which is both modern and donated to Project Gutenberg.

The North American Jules Verne Society has a list of works, a determination of which are the best translations, and links to Amazon here: <http://www.najvs.org/works/index.shtml>

</comment></comment></comment></comment><comment><USER7> I'd add Lauren Ipsum, a kids book about computer science I wrote with my wife: [http://www.amazon.com/Lauren-Ipsum-Carlos- Bueno/dp/146117818...](http://www.amazon.com/Lauren-Ipsum-Carlos- Bueno/dp/1461178185)

For every copy we sell we're donating another, too: <http://www.laurenipsum.org/141>

</comment><comment><USER8> If you're interested in reading to your kids, consider checking out "The Read- Aloud Handbook" by Jim Trelease (<http://www.trelease-on-reading.com/>).

It has loads of practical advice, and suggested reading lists at the end.

</comment><comment><USER9> I'm glad The Phantom Tollbooth is on the list, but don't overlook Norton Juster's The Dot and the Line.

</comment><comment><AUTHOR> I would add Momo by Michael Ende.

The list is available at [http://www.wired.com/geekdad/wp- content/uploads/2012/04/67-B...](http://www.wired.com/geekdad/wp- content/uploads/2012/04/67-Books-Every-Geek-Should-Read-to-Their-Kids-Before- Age-10.pdf)

</comment><comment><USER10> One for younger audience:

If I Built a Car (Chris Van Dusen)

[http://www.amazon.com/Built-Car-Chris-Van- Dusen/dp/014240825...](http://www.amazon.com/Built-Car-Chris-Van- Dusen/dp/0142408255/ref=sr_1_1?ie=UTF8&qid=1335089085&sr=8-1)

</comment><comment><USER11> Don Quixote needs to be on this list. I started it a few years ago and every time I pick it up I feel like a kid inside. If my parents had read that to me chapter by chapter, from age four on I think I would've been in bedtime heaven.

</comment><comment><USER12> A bit more obscure, but tremendously fun (and very geeky), are George Gamow's Mr. Tompkins books (<http://en.wikipedia.org/wiki/Mr_Tompkins>) - I discovered the first two in my high school library, but they would be very accessible to any elementary school child.

Also in the geek mode, why not Abbot's Flatland (<http://en.wikipedia.org/wiki/Flatland>)?

</comment><comment><USER13> I witnessed university faculty squabbling, debating, supporting arguments, and a lot of years of experience and input go into the reading list for students, and this was an Ivy League school. Although this was obviously a different level, I would suppose considering the absorption rate of children that a reading list should be taken very seriously and I would make sure those who put it together were qualified to do so.

</comment><comment><USER14> I'm very surprised (and pleased!) to see my favorite YA author, John Bellairs, show up on here, although I am a little questioning of The Lord of the Rings for kids under 10 - it's been a long, long time since I read them, but I wonder if someone that young would be able to keep track of the different characters' journeys.

<comment><USER11> It's worth it. A great aunt bought me the Hobbit when I was around five, and I immediately took to the whole Lord of the Rings series, Silmarillion, etc. By 10 I'd read every Tolkien book I had ever heard of, including ones by his son that I didn't even realize. My best friend to this day was just as freakish, and it turns out not only was it pretty much what taught us how to read, but we kept track of many of the characters and stories the same way– by drawing all of it. Personally, without them I don't know if I would have appreciated _books_ , period. Some kids will go to great lengths to match with the things they're given, so there's certainly no harm in gifting a copy of at least the Hobbit and testing whether or not they'll really enjoy it.

</comment></comment><comment><USER15> I'd add Weighty Words - fun stories that make large words like "abasement" and "ingratiate" accessible to 12-year olds [http://www.amazon.com/Weighty-Word- Book-Paul-Levitt/dp/08263...](http://www.amazon.com/Weighty-Word-Book-Paul- Levitt/dp/0826345557)

<comment><USER16> My 3rd grade teacher read this to my class, and I, to this day, think of the phrases "a basement" and "in grey she ate" when I hear those words thanks to this book.

</comment></comment><comment><USER17> i am actually reading flatland and one,two,three,infinity to my son these days. slow, but pretty interesting reading...

<comment><USER18> One,Two, Three, Infinity is probably the best possible introduction to math for kids.

The big challenge is skipping ahead to the "cool stuff" for kids who are still young enough to lack facility with algebra. Most attempts to do this are either hand-waving or unfairly advanced. But the real solution is to show them genuine math that doesn't _require_ any solving for x, like Cantor's diagonalization lemma.

</comment></comment><comment><USER19> No Edward Gorey?

[http://www.fuddytv.com/blog/books/edward-gorey-and-his- alpha...](http://www.fuddytv.com/blog/books/edward-gorey-and-his-alphabet/)</comment>


Cripple the Prototype: Sabotaging your best ideas - <AUTHOR> http://boundary.com/blog/2013/02/27/cripple-the-prototype/

<comment><USER2> Having done this sort of thing both ways, it's clear to me that there is much value in getting the consensus and energy of teammates and potential clients behind your project before it gets too far along.

When designing a prototype service / API, it's really easy to miss important use cases and failure modes that may be obvious to a fresh set of eyes, and get lost in the fun of creating it. Once this code goes to production, it's always harder to go back and fix these deficiencies, especially if a large number of clients come to depend on the API in its prototype form.

It's better to scrap and rewrite the prototype with multiple people involved, as it will save time, pain, and churn in the long run.</comment>


Confessions of a Sweatshop Inspector - <AUTHOR> http://www.washingtonmonthly.com/features/2008/0804.frank.html <comment><USER2> It's easy to forget how fortunate we are to be in an industry in which good working conditions are positively correlated with good results. What a sobering reminder.

<comment><USER3> During the first half of this century, a number of research experiments by companies (including GE) showed that good working conditions nearly always correlated with improved productivity and better quality.

The problem with China is that it is cheaper to higher more workers than to improve the conditions for the ones they already have. As the average income in China increases, and the middle class grows, this problem should lessen.</comment></comment>