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?

Someone else mentioned that the architecture is based of Sparc technology (Sun's line of CPUs, which is a mips derivative iirc). It's hardly a completely new architecture.

True, what I meanbt is that the consumer software marketplace is originally built around those platforms. During the last several years, the market has been largely fragmented by tablets, but I have the impression they still represent a major segment. That said, industries and services may more easily accomodate the absence of these players.

> In my opinion schools should stick to basic teaching,

Define basic teaching.

> a high percentage of french teenagers cant even write french at the end of highschool,

Reference?

China has a team developping a mips like architecture, with several produced iterations: https://en.wikipedia.org/wiki/Loongson

I don't know if Russia has the industry to mass produce it, but surely it has the skilled people to design it, and it may probably use foreign fabs for the remaining steps if necessary.

As for the software, with an established ISA, they may quickly leverage exising open source solutions. Of course, Windows and OSX support will be a problem (given that they are the major desktop players).

Politic or not, they know it's doable.

> This makes it non deterministic because objects in OCaml can destruct at different times in your program depending on the inputs.

There's clearly a different notion of deterministic there! If your program using ref counting gets a different input, the same object might be released at a different time as well, or am I misunderstanding?

> "OCaml's automatic memory management guarantees that a value will eventually be freed when it's no longer in use, either via the GC sweeping it or the program terminating"

> So, it can guarantee your object will be freed... but only when the program terminates? That's not a very strong promise.

”A or B imply C” is not the same as ”B implies C”. There's a logic mistake there.

> OCaml uses non-deterministic garbage collection, whereas python mostly uses reference counting (in CPython). This is another case where the first system was safer in one aspect.

How is reference counting safer?

Afair, we had close to 100Mbit/s on our lines. The building wasn't very old, apparently we had good copper wires (I can't comment on the average quality of those across the country, but knowing Japan, it should be good).

I've seen this kind of setup in Japan more a few years ago, with vsdl as the technology for "the last meters": fiber optic was used by service providers down to neighborhood/building concentrators, and then the signal was carried over phone copper lines down to the office. We had a vdsl modem there, instead of a fiber one (I've seen those as well for business and homes).

> The problems with google's approach have been pointed out almost immediately after their policy became known.

I've been the devil's advocate til now, I will not give up so easily. If people knew about this policy, then they couldn't have opt out of the service and look for something more amenable to their needs of privacy, couldn't they?

>For a hamhanded car analogy, if someone parks in a parking space for the disabled out of laziness, and now some guy in a wheelchair has to cover another block's worth of distance because he had to park elsewhere,

The policy there wasn't that someone took that reserved parking place, it's that the place simply disappeared from that parking lot. So yeah, it does suck, but there are other parking lots to use (which also mean other shops, if that guy in a wheelchair liked Google's ones, tough luck).

> I think that's really unlikely. I might conjecture a hypothetical culture where insults are expected and polite, but I think it's sufficient to look at the actual cultural context. Correct me if I am missing something, but "jerkface" is the blandest, least serious insult I can think of. It doesn't invoke gross body parts, religion, sexual language, the subject's intelligence, morals, looks or status. In fact, I cannot imagine anyone using it without irony, going intentionally for a weak and childish insult.

Really? Do kids use that insult? Well, I don't speak English fluently enough (especially cursing), and I'm not going to pull a dictionary definition to verify it. If indeed it's as you say, then that's a misunderstanding on my side, and I clearly deserved a downvote for that. I'll take your word for it.

>That harm and those people are apparently not as important as some business goal. That offends me.

I understand your point.

> Why would an insult convey more offense than all the criticism in the article already does?

That really depends on the aim of the article. If it is to express a feeling, fine, she did express her feeling. If it is to make a point, she shouldn't, or one might simply say she cannot have a rational discussion, because it simply doesn't prove anything. Google didn't use insult, it undisclosed private information. While it is senseless, it's not an offense, in the sense that there's no proof that it was intended to hurt. I don't believe that S. Brin woke up one day with the idea of harming people, or do you think that is what happened? If it were the case: if I had been the victim of a deliberate attempt at hurting me by disclosing things about me that I consider private, I would be seriously pissed. The question is: was it deliberate, or was it simply an error, or a misunderstanding? People make mistakes, that's unfortunate, but it's understandable. She, otoh, cursed voluntarily.

> It's also a particularly harmless insult that as far as I can tell

That's anyone's appreciation. In a different culture, it might well be the worse thing you could say to someone. The fact that it carry already a insulting connotation is enough: there's no way someone could take it as a compliment, thus whether it is harmless or the worse one could say is besides the point, the message is clear.

> That's a lot of words about this sidetrack

For a minor issue, that happened in _the title_, but I surely don't care that much.

Well sure, as long as the real name policy is actively enforcable by G (which I doubt, but someone else apparently had to go through their enforcment practice), there's a risk. Then maybe it means that G isn't the right medium to express oneself anonymously and have an official virtual life. As I said, the only real problem is that policy.

> It's much less offensive than the G+ real name policy, so that's a weird focus. ;)

I don't think we have the same definition of offensive (please correct me if my second language english is wrong). That policy was harmful, but I wouldn't qualify it as offensive. I think the article provides good examples where it was harmful.

That said, if you don't think it's inappropriate for someone to use anonymity (or is it her real name?) to insult someone else, you won't mind if I finish this comment by the same sentence? I won't, because I know that it's not necessary, and it would undermine the message I'm trying to convey, as it does in her case.

I don't think that G+ was a mistake. The only real issue is the real name policy, though I fail to see how they'd be able to enforce it. People could create alternate email addresses with fake names (and some did), and use it when they want to participate social "i-events" without giving up their id. It's been like that before G+, and it would only take a small move from them to correct it. Of course, the downside of this is that they wouldn't be able to claim a number of real users. But could any social site?

Btw, am I the only one to find the article title offensive, and unworthy of a place like zdnet? I wasn't a regular reader of their columns, I don't think that will help.

> HFT provides liquidity

For those like me who don't understand, what does it mean? What are the benefits? What are the drawbacks?

> There is functionally no chance of that software bug ever getting patched; card vendors don't care about older versions of their technology,

Well, is that an OpenGL issue? Wouldn't you get that very same problem with D3D?

> reasonably-performant way

I don't understand. How can you objectively define such thing? Doesn't it depend on the workload? If you're pushing 3 tris per frame, any feature can be labeled as reasonably performing, but if you have 300M, can any card these days maintain reasonable framerate even on the most basic settings? I am exagerating on purpose; some apps will require a very small amount of work on each stage of rendering, and could reasonably afford any extra pass, even if software implemented. And in other cases (which might be the majority), it doesn't cut work. I don't see how there could be an objective way of deciding if a feature is sufficiently performant. Your example is telling: an application as complex as F.E.A.R. Should clearly make its benchmarks (or keep a database) to decide which feature can be included without hurting performances. And even then, players have also different perceptions of what constitutes playability.

I agree with you: multiple standards, multiple vendors, multiple products, the fallout is "struggling compatibilities" at worst, "varying performances" at best. But that's a common point between D3D and OpenGL, not a divergence. Am I missing something?

A bus will drive you on a fixed itinerary...

> "OpenGL is broken" refers to the market adoption of the standard, because when you're developing graphics software for consumers that's the aspect you care about.

(This isn't the only point the OP is arguing about, but anyway.) What exactly would be the alternative? It's either there's a standard, and adherents must follow its core features to get the compliancy stamp, or there are no standards, and each go its merry way, up to third parties to follow up on all the completely different API resulting from that. As someone else said, there are core levels in the standard, which give garantees to third parties. It hasn't always been like that, but now we do have them.

As for support of the latest features on my old Geforce 7600, I guess I should accept the fact that they cannot be implemented efficiently, and if I want to play the latest installment of Wolfenstein, I'll have to grab a new card. Or I could try getting a more modest game. There is clearly a commercial aspect to this whole upgrade mechanism too, but since upgrades are necessary for technical reasons, it's difficult to argue against the mercantile part.