0xABADC0DA

This is the same problem with NaCL. The API is complicated and has a bunch of browser-specific features. Firefox can't just include "pepper.c" and have NaCL support, there's tons of work involved. One result is that Firefox won't support Flash for Linux anymore. Implementing Pepper, even though it's "open source" is more of a hindrance than not having Flash.

NaCL is better technology than ActiveX, but uses the same idea of leveraging a OS/browser-specific API as a handicap for competitors.

http://code.google.com/p/go/issues/detail?id=47

So Google Go programs won't run on any RHEL or Fedora with SELinux enabled. Requiring users to disable SELinux in order to run programs is just insane... even a lax SELinux like the default policy from Red Hat is still very effective.

Whoever thought an executable stack was a good idea... well they certainly don't have any clue about OS security.

    defer { result++; }

    defer func() {
        result++;
    }();

    defer func() {
        err := f.Close();
        // handle error
    }();

There's a bug in some AppleTV where it has to be connected to a TV on boot or there's random noise from the digital audio out, but the easy solution is just keep it on (it only draws like 1 watt idle anyway). Hook up to a dedicated amplified speakers and you have wireless audio whenever.

- Easy to remember and type

- Not leet speak

- Reminds you to keep ego in check

What you are doing is looking at the success story and saying 'they already made 100x on their investment that should be enough!' but neglecting to consider the chance of failure. We don't have patents so that Apple can make 150x times their investment instead of 100x, we have them so that companies looking at 150:1 odds instead of 100:1 will try to make those big changes in the first place.

Do they also get to make spurious patent claims left and right now

Absolutely Apple should continue to get advantages over non-innovating competitors even though Apple already has gobs of money.

I don't even... what do you expect Apple Legal to innovate? "Accept EULA to unlock?" They aren't at odds with engineering any more than having a good defense is at odds with having a good offense.

Have you used an up-to-date android phone in the last 6 months? Perhaps even gotten to play with an Nexus 7 or a Galaxy S 3? The competition is fierce right now, and Apple has badly mismanaged its money

That's really the heart of the matter. Patents were created to reward innovation by actually disadvantaging competitors that sat around and waited -- because the market by itself doesn't produce brand new things just by competition. Even though Galaxy-whatever today may be a better phone and the economy is hurt on a small scale by holding it back a bit, the economy is improved on a large scale by rewarding the big innovations.

The tech crowd doesn't get that a local meritocracy where the best phone wins optimizes existing things, like making a better keyboard or improved battery life, but it doesn't often lead to an iPhone or other revolutionary change. A pure merit-based market actually punishes innovation -- if you spend years and a billion dollars researching HCI, form factors, etc and your competitors just copy you then you are competing with a billion dollar hand tied behind your back.

Is this particular patent valid? Maybe, maybe not... it doesn't really matter. What really matters is that unless Apple's competitors need to compete much more effectively in order to make up for their lack of innovation then the market has failed.

But when you pressed Esc or F1 or whatever for a boot menu, instead of choosing what partition to boot from you choose which key. ie the list is

1) Microsoft, Inc. Operating System

2) Red Hat, Inc. Operating System

3) ...

So even if somebody hacked Red Hat and stole their key and signed something malicious, the user would still have to select that key on boot in order for it to run. Maybe the boot menu would only list keys that verified an actual installed OS.

In any case, just because you have a bunch of keys in the BIOS doesn't mean you have to automatically boot anything they sign.

So verifying the bootloader with EUFI is a great thing that must happen. It could be completely transparent to most users -- their system works the same, it's just more secure. The problem is that Microsoft has engineered it so in practice only their key can be on the system to unlock it. Once this scheme gets established they might even be able to maintain a 'windows tax' just to unlock the hardware even if you don't even use their OS. That's really the only negative about EUFI.

"The university has a troubling history when it comes to matter race..."

"UVa's racial problem is larger than simply a few isolated incidents of bigotry. ... There is still a discernable "Good Ol' Boy" network that heavily influences the Commonwealth's social, economic and political life and holds UVA up as a crown jewel."

What I posted was not just my opinions, and it was not uninformed. Nevertheless I deleted it because the contents or way it was expressed clearly offended a lot of people here.

Yes, gcc now also compiles the language, but they still pimp their own compilers... iirc the "go" tool uses them by default (or maybe exclusively). Why create a new compiler? Why a project management tool that does everything except work with other build systems? Why isolate the language by making it difficult to use with others? I feel those are good questions to ask.

For instance Russ Cox did coroutines and channels in his C libtask in a few thousand lines of code. It's not pretty but it works. Include something like it behind an API as 'libgrt.o' with a few other features and the rest of the code transpiles cleanly.

...but say this existed. What would be the point of writing Google Go code? A more compiler-friendly syntax, less flexibility to make simple memory/pointer mistakes? Would that be enough or would you, with perfect C linkage, just end up writing most of the code in C and Lua? It certainly seem the effect of creating their own compiler (worse than gcc), an opaque "go" tool that does everything, project layout and hosting rules, complicated FFI, etc is to make a 'toolchain island' locking you into writing everything in Google Go, where you might not otherwise.

Ask them. They know their stuff.

For me though, I think Microsoft held back on changes so it would be more accepted as Spdy-like. For instance the whole HTTP format seems pretty lame to me... a 16-bit string length count... amazing, iirc it's 32-bit now but who ever thought that was a good idea?!

https://developers.google.com/speed/articles/spdy-for-mobile

Scroll down halfway to the waterfall charts. Out of 35 requests, 31 were for static files, where there is no blocking. These are bandwidth limited so the main difference is whether they complete one at a time somewhat regularly spaced (pipeline) or interleaved (Spdy), but total throughput will be roughly the same.

For the 4 dynamically generated files the HTTP version actually finished these sooner.

"The waterfall diagrams clearly show SPDY's main advantage over HTTP: The use of out-of-order responses. ... [vs HTTP] handling requests in a FIFO fashion".

Oh really? More like the diagram clearly shows they weren't using pipelining. If they had been using pipelining then requests would have been sent immediately instead of blocking. The bars would be blue, with more variety of length but averaging to the same as for Spdy (as clearly this case was bandwidth limited).

To put this into context, they replaced the Android browser that did do pipelining with Chrome and then post a comparison of Spdy vs no pipelining. Seriously ask yourself why they compared Spdy to non-pipelining HTTP to trumpet their +23% claims when they were previously using pipelining. My hunch is they are just lazy and disengenuous... or are they purposely pushing Spdy, or are they incapable of believing Google doesn't produce the best at everything?

I don't know what Google's motivation is with Spdy, but the claims they make are just absurd. The actual real-world problems with pipelining are that some server/proxy software borks it up.

From what I can see the Spdy draft 3 doesn't include any improvements from Speed + Mobility so I don't see the relvance of your post. It's a shame because Speed + Mobility has real improvements (yes Microsoft does things right sometimes).

Also Spdy only had 23% faster page load times than non-pipelined HTTP (in other words, enabling networking.http.pipelining is just as good).

http://tools.ietf.org/html/draft-montenegro-httpbis-speed-mo...

They took Spdy and dropped priorities, settings and other ill-conceived parts from it and made compression and encryption optional. There's still some Spdy warts in the HTTP parts of it though...

The process of adding an exception in Java:

1. throw TheException

2. compile

3. add "catch(TheException e)" to fix errors or "throws TheException" to signature

4. repeat 2 until no more errors

Compare to C++:

1. throw TheException

2. examine all functions to determine if they might need to handle TheException or consult intuition about program structure

3. repeat 2 until 'done'

So the real problem with exceptions in C++ is the compiler can't tell you where to look next and what you forgot about. Step 2, magically find all the places that should catch the exception, is both time consuming and error prone.

I find it strange that C++ has all kinds of strictness with types (have to cast void*, const virus, etc) but with exceptions they just throw caution to the wind.

Rust: filename.ℛ

Java: filename.☕

Glee: filename.☺

Isn't that just so much clearer and nicer-looking than ".rs" or ".java" or ".g"? It's really the fine aesthetic points like this that can make or break a language.

According to the recent EU ruling your program is derived from MongoDB's API. But to prevent 'monopolization of ideas', MongoDB APIs are not under copyright so your software is not a derived work. In addition the ruling voids license clauses with conditions on how you run the software past normal use, so clauses like 'except you can't clone the API' or 'can only link with approved software' or 'have to publish the signing key' are unenforceable.

Since it's not a derived work and GPL linking restrictions are not enforceable, you simply accept the GPL and distribute the .so and source for that code along with your closed-source program and use it. You still have to publish your changes to the GPL code itself, like LGPL, but that's all.

This is the flip side of the API-copyrightability coin.

It's not all the time and I haven't investigated to find out what the problem is... Bing search always works so I just use that.

"Has Oracle proven that Google has infringed the overall structure, sequence and organization of copyrighted works?"

As far as I can tell nobody disputes that Google lifted the Java API's structure, sequence, and organization from Sun, and the judge told them to consider SSO copyrightable. Most programmers think it's ok to rip off an API because otherwise the world will burn, or something, but 1A is asking what Google did not whether it was illegal.

My bet is the jury is held up on the fair use, either for implementation (1B) or documentation (2B). These are vague questions that can easily go either way. My bet is that they find 1B for Google (implementing the API is ok) but find 2B for Oracle (reprinting the API SSO is not ok). You have to implement the API to make it compatible, but you don't have to republish the API.

That's just not true. You can create your own classes for IO, or anything else, implemented as native methods. The only problem you have is if you want to copy the whole structure, sequence, and organization of Sun's API that Sun designed. For instance if you want the use the C library functions to implement your new Java classes, that's fine since you aren't copying the SSO of them.

I think a lot of people have to jump to these 'sky is falling' 'it'll break the internet' arguments because they refuse to accept that Google is the bad apple here. Google copied Sun's work, didn't pay Sun for it, and at the same time destroyed Sun's future revenue from Java licenses (as everybody just used Android for free). This was probably a significant factor in the decision to sell Sun (the Schwartz mentioned for instance that some companies were not renewing their Java license).

But this is capitalism not morality, and when somebody else creates something you want you pay them for it. That's really the issue here, Google used Sun's work and didn't pay.

- doesn't include DNS lookup times

- doesn't include packet loss

- doesn't compare to pipelining

First two mean the claimed speedup isn't measuring the whole real time. Third is just amazing... the stock Android browser even uses pipelining. Basically pipelining gives the same benefits as Spdy and they really, really don't want to admit this.

http://www.belshe.com/2012/03/29/comments-on-microsofts-spdy...

This is what I'm talking about... every one of Microsoft's changes he identifies as b-h is a positive change. That he can't see it I guess is a testament to being young and inexperienced.

This is a good point, for instance the developers of Spdy don't actually compare it to HTTP pipelining. They don't measure the effect of 'head of line blocking', just assuming it is a major problem. They don't consider that the protocol performs worse than HTTP over satellite and similar links. Neither the design choices nor specific details have been vetted or backed up by real deliberations.

There are tons of ways a committee of experts could improve Spdy, but it looks like Google is just going to show up with their draft RFC and demand a rubber stamp.

But this is just typical Google. Even when they do work with committees they show up and for instance say 'add big integers to JavaScript or else' (the 'or else' being Dart).

Google - "giving itself all permissions it could possibly need" including creating derivative works of any kind.

Dropbox - "solely to provide the Services"

Skydrive - "solely to the extent necessary to provide the service"

iCloud - "solely for the purpose for which such Content was submitted"

Basically Google can do anything they want with your data, but the others can only use the data for what you would expect (storing/syncing your data).

I'm not a lawyer so I don't know if Google's case is solid legally, but putting myself as a juror the Oracle opening statement I think would be very convincing compared to Google's.

But my reading of the slides is probably colored though by my personal opinion that the Java API should be copyrightable. It's a substantial creative work and no two people would create the same APIs even containing the same ideas and concepts (.NET for example).