fzltrp

I have to admit that, while I knew these documents existed, I was not aware they included as much information as they do: I was under the impression that it was merely an xml version of the original C headers to facilitate their parsing. Having a second look, it seems that it also covers information like array expected size and valid enum subsets for parameters, which is very valuable data for all players using the API (even driver implementors could use it to generate basic conformance tests).

In my humble opinion, they should write formal specifications which are not just targetting a C API, but may degrade consistently to a C API. With a more formal description of each function call, including predicates for parameters, and possibly the context itself, they make things way easier for user land, where these could be mechanically translated into API bindings, and thus checked automatically. If all these checks are made on the user side, then they may add a simple toggle in the API to remove the checks on the driver side. Most users aren't using the C API directly anyway, and people writing bindings would welcome specs which could be mechanically translated into their favorite language bindings. The problem might remain for WebGL though.

> Then, if someone writes a popular API wrapper, Khronos can take that API and standardize it as the next version of OpenGL, no design-by-committee required.

If that wrapper actually supports all the features evenly, and doesn't favor a particular implementation. Is that possible outside a design by committee?

> Oh. Ocaml again.

Nothing forces you to read the posts you don't like.

> Well, I'll chirp on the opposite side of discusion. The syntax is completely <->:%^&#$^ $% %^&*% up. Unreadable. Yes, it maybe somewhat pleasant to write code in such syntax, but readability sucks.

Readability is mostly a matter of experience.

> Which means that there are uncountably many ways to screw up the design

And many ways to make it fit a given problem. It's again a matter of experience.

> And each OCaml primadonna developer thinks that his way is the right way. And the rest can't read his code. Fuck that.

Glad you give your opinion. Apparently you have an axe to grind against the OCaml community though. You could probably replace OCaml with any language with a lot of expressiveness, and still be correct - assuming there are "primadonna"s in the OCaml community and that "any other". Or do you mean that this happen only with OCaml?

This is the ability to abstract concepts and then recognize them in different settings (for instance, the idea of a child being a miniature version of a given animal, with less pronounced traits). In order to understand the clues you are talking about, an AI has first to be familiar with the terms used in the discussed topic, so as to be able to construct a definition by itself (what is "miniature", "traits", "pronounced"). These terms' definition must be synthetized somehow before hand, or perhaps as the discussion goes, but then the amount of necessary information in that discussion must be much larger, for the AI to untangle them properly.

Yes, this is correct. Thank you for pointing that out.

If a company is producing new ideas, and stock pile them in the form of patents, are they playing the game correctly?

Is it (just) an issue in the case of sotware patent?

I meant that mentor thing in the context of IBM. I agree that it would not be much better in the case of Project Zero.

That said, I still think that a positive approach (positive criticism) cannot be worse than plain critics.

> "You come in here and think that you know our applications, but you don't know the history and the specific compromises we decided to make, etc, etc."

That's exactly the sort of answers that team should prep for: it is obvious to me that whatever compromise I made for my software stack, if there's a security issue, I will have to reconsider them. The whole point is to not rub it up my face for me to accept the issue more easily (not everyone is an adept of egoless programming). I was also saying that with the perspective of the Sony situation: in Japan, losing face is an extremely serious matter. I don't know how this situation was handled by this guy though: perhaps he did all he could to manage their feelings. It's clear to me though that doing it the IBM black team way did is a recipe for failure.

> Playing Devil's advocate

Actually you raise a good point. ARM has been always doing that though, they built their own cpus when they started, iirc. That would have large consequences on their current business model, it's true.

> And if not, what would prevent NPEs from licensing to one small company and then suing everyone else?

It's already happening. When one of those company win a lawsuit, it is usually followed by them selling a license to whomever they sued...

Which is the lesser evil? Forcing patent holders into producing practical implementation of their patents, or allowing NPEs to exist?

I guess my idea doesn't really hold waters. Most probably smarter people already have thought about that possibility and saw the issues you hinted at. Oh well.

The original point of patents is to provide protection to inventors and give them a head start in implementing their inventions. A company which hold patents without implementing them is basically not following the spirit of the law. Hence, there should be a drastic "countdown" to a patent viability, which would be dispelled by a producing a viable, marketed application of that patent. I would suggest a 6 months timeframe, non renewable. For software patents, given the very abstract nature of the invention, 3 months should be enough, and the patent lifetime itself should not exceed 3 years - 12 times the countdown to market (3 years is already quite long in the software industry, although not in the law one). This should be retroactive. Note that I'd rather see the concept of software patents completely invalidated, but I understand that the issue is quite complex.

Oh, and what should be done in the case of patent transfers? Should the new holder be subjected to that countdown as well? What if the products tied to a patent is eol'ed? Should the countdown be restarted? I do think so. It's all about the practical side of things.

> isn't it still positive for the economy?

Why? Where's the benefit for the economy? If somehow the patent trolls reinject the benefits they make (ie what they obtain from the law suit minus the lawyers/legal fees) in the economy, perhaps we could say it's maybe a positive outcome, but there are no garantee that the infringing company would not have done so. So where is the benefit for the economy?

The insight there is that one should always try to wrap criticism with praises: people don't like being told that they suck at their job, even if it's true. If instead of showing themselves as destructors, they'd adopted an image of mentors or teachers, things would've gone way better. Hopefully Google's Project Zero will be wiser than the IBM team on this point.

Note that this is even truer when criticism comes from an outsider, and Google's team will be doing exactly that. If they also deal with companies whose culture is very much reputation based (like in Asia), they'll have to be even more cautious.

Thanks for correcting me: indeed, it's an open architecture which was used by Sun, Fujitsu and TI for their CPUs, and it's unrelated to MIPS.

Oh, ok. So every python implementations follow that practice?

However, how difficult would it be for a foreign fab to rig the design of a customer and include backdoors?