Of course, any library published with a restrictive license (GPL) will eventually be supplanted by a library with a more liberal license (BSD, etc) The value proposition is simply better.
What we need is a language that allows us (the open source community) to implement and experiment with different languages. This means the language should (imo) have these traits:
1) (Efficiency) Should be close to machine language (possibly even equal to i386) 2) Should be easy to translate to different platforms 3) Should be secure
Now, fortunately 2 follows from 1 since modern compiler technology can easily transform between different target codes. And 3 also follows from 1 since a machine instruction set is easy to make secure (much more easy than, say, the enormous and "hairy" javascript and html standards).
I think google's NaCl comes closest to this goal. I just hope that others (including W3C) will accept this standard, so that we can start to develop compilers for it.
Since Apple doubled their resolution, and thus effectively quadrupled their pixel count, they actually need a 4X speed advantage, so from the user's perspective the device must be getting slower.
The cat is out of the bag and no matter what I do I can't get it back in.
Well, the one thing you *can* do, is to inject so much noise into the internet about your persona, that the information that is currently on the web becomes practically useless.
You don't even want to have a server, well a big one anyway. For this type of data which is not latency-sensisitve, you probably want to follow the P2P model that spotify uses. It requires a bit more programming, but it can save you a lot of expenses and bandwidth problems.
We need a much more generic programming environment than the current HTML+JS combo. Why? Let me explain.
First, HTML and JS are hairy and complicated. It turns out that in practice no two browsers correctly implement these languages. This means that web developers have a hard time as they have to check and double check their code on every browser that is out there. In essence, stuff written for the web IS platform-dependent. Furthermore, because it is so difficult to implement HTML and JS, there will be only a limited set of browsers available in the market, so it is not healthy for competition, to say the least.
With NaCl, the situation is different: only a relatively small set of machine instructions need to be supported. And because these machine instructions are so generic, much richer applications can be written for this platform. Think also rich libraries, and third-party languages. With JS, we are stuck with a particular execution model and garbage collection scheme. By offering a lower level language we open up a world of possibilities (ecosystem) for open-source library development.
And guess what? Implementing a LLVM bitcode back-end for a new platform is much easier than implementing a JS compiler from scratch. It may sound unbelievable, but even i386 instructions are much easier to translate to a different platform, than implementing a JS compiler.
Slashdot Mirror
Google is more like a chicken: they avoid liability by making their products "beta", and they avoid customer support by making their products free.
Then you have a developer community whose primary incentive is to reinvent the wheel, not to develop new innovations on already-proven technology.
Legal folks don't care about that. They reinvent the (breaking)wheel all the time.
And think about wine and reactOS, both using the Windows API.
And what about Java itself? It borrows a lot from C/C++.
Of course, any library published with a restrictive license (GPL) will eventually be supplanted by a library with a more liberal license (BSD, etc)
The value proposition is simply better.
With so many of this country's processes running wild, and such unfair load-balancing going on, I suggest we ask the linux kernel developers for help.
You replace the current crop of voters with a group that actually bothers to get informed...
Do you suggest we vote for voters instead?
According to some researchers, that essentially proves
According to some other researchers, the verb "prove" has lost its meaning.
What we need is a language that allows us (the open source community) to implement and experiment with different languages.
This means the language should (imo) have these traits:
1) (Efficiency) Should be close to machine language (possibly even equal to i386)
2) Should be easy to translate to different platforms
3) Should be secure
Now, fortunately 2 follows from 1 since modern compiler technology can easily transform between different target codes. And 3 also follows from 1 since a machine instruction set is easy to make secure (much more easy than, say, the enormous and "hairy" javascript and html standards).
I think google's NaCl comes closest to this goal. I just hope that others (including W3C) will accept this standard, so that we can start to develop compilers for it.
anything you throw out in the trash is no longer your possession.
Hah, as if those things "were" your property in the first place, considering all the DRM installed.
Since Apple doubled their resolution, and thus effectively quadrupled their pixel count, they actually need a 4X speed advantage, so from the user's perspective the device must be getting slower.
"When Are You Dead?"
According to copyright law, 70 years after you've died.
Fortunately, git is a distributed version control system, meaning that, usually, there is a copy of the sources and history information elsewhere.
The cat is out of the bag and no matter what I do I can't get it back in.
Well, the one thing you *can* do, is to inject so much noise into the internet about your persona, that the information that is currently on the web becomes practically useless.
Unfortunately, they will probably just slap the "fair use" label onto this to make it go away.
...it's basically impossible to shut down, or compromise effectively, without severely screwing up the internet. Which is probably the next step.
"You have transferred more than 100kB of encrypted data. Your internet connection will be suspended until the end of the month."
computer code is often easier than its legal counterpart
Ok, the next time I'm having a deadlock situation with more than 10 threads involved, I'm calling my lawyer.
SOPA is just part of an exercising of the "door in the face technique". See: https://en.wikipedia.org/wiki/Door-in-the-face_technique
Soon, they'll loosen their demands a little and suddenly governments will be okay with it.
You don't even want to have a server, well a big one anyway. For this type of data which is not latency-sensisitve, you probably want to follow the P2P model that spotify uses. It requires a bit more programming, but it can save you a lot of expenses and bandwidth problems.
I hope they use that money to further stifle innovation. All these technological novelties and the accompanying technobabble are growing over my head.
How about consistency? Does this database even support the notion of transactions?
So now google is able to literally look through our eyes... great.
I can second that.
After reading the quote in the summary, the only thing I can think of is: you can have your eternal copyright.
Here in California no problems whatsoever.
We need a much more generic programming environment than the current HTML+JS combo. Why? Let me explain.
First, HTML and JS are hairy and complicated. It turns out that in practice no two browsers correctly implement these languages. This means that web developers have a hard time as they have to check and double check their code on every browser that is out there. In essence, stuff written for the web IS platform-dependent. Furthermore, because it is so difficult to implement HTML and JS, there will be only a limited set of browsers available in the market, so it is not healthy for competition, to say the least.
With NaCl, the situation is different: only a relatively small set of machine instructions need to be supported. And because these machine instructions are so generic, much richer applications can be written for this platform. Think also rich libraries, and third-party languages. With JS, we are stuck with a particular execution model and garbage collection scheme. By offering a lower level language we open up a world of possibilities (ecosystem) for open-source library development.
And guess what? Implementing a LLVM bitcode back-end for a new platform is much easier than implementing a JS compiler from scratch. It may sound unbelievable, but even i386 instructions are much easier to translate to a different platform, than implementing a JS compiler.