Re: Reboot: Strategic goals for GNOME
The point I was trying to make was that HTML 5 (or more formally some of the API's for javascript for accessing local storage), among other things, enables offline use of web applications. This sounds both interesting and dangerous. Maybe it would let you explicitly install a free program written in Javascript, and it could do the same jobs a C program could do. That seems fine, just like installing a C program to do it. On the other hand, it might also enable web pages to attack you in new ways. Javascript programs are not necessarily bad, but if browsers temporarily install them silently without checking whether they are free, that systematically leads users to run nonfree software without knowing it. I would like to find out more about this change, so I will write to you separately. 2) but also to improve compression of the loading of such programs initially. People like Google work *hard* on latency and understand every byte counts (among many other things: go look at the google talks by their engineers on the topic). This is a kind of compilation, and in principle it's no more of an obstacle to free software than other kinds of compilation. You just need to make the source code available in another file. We are working on the issue of nonfree Javascript code -- see http://www.gnu.org/philosophy/javascript-trap.html. There are people working on extensions to NoScript to detect nontrivial nonfree Javascript programs in pages, but progress seems to be slow. If you know people who would like to help with this, please put them in touch with me. ___ foundation-list mailing list foundation-list@gnome.org http://mail.gnome.org/mailman/listinfo/foundation-list
Re: Reboot: Strategic goals for GNOME
Philip Van Hoof wrote: On Fri, 2010-03-05 at 07:51 -0500, Jim Gettys wrote: I'm doing a huge [CUT] here, I hope you don't mind? People like Google work *hard* on latency and understand every byte counts (among many other things: go look at the google talks by their engineers on the topic). In my opinion you solve latency more by making services capable of pipelining, than by compressing data. And by making clients that make use of the remote service's pipelining capabilities. They do both routinely. Go listen to the technical talks. But initial startup time is also considered a major latency issue. The perceived latency will include the time to decompress the compressed chunks (when using a compression algorithm instead of code obfuscating, like they do with javascript as you point out), but I'll agree that this is negligible compared to average network latency. Especially on 3G, UMTS and (all) other mobile network protocols. In other words: UI and client developers should learn to build state machines instead of threads that work like (where [...] is ~ an IP frame): [ask], wait, [receive], process, [ask], wait, [receive], process Instead of that, do this: [ask ask ask] [receive receive], process, process, [receive], process Thank you very much for explaining HTTP/1.1 pipelining to the former editor of the HTTP/1.1 standard... ;-) An example of this is Dave Cridland's Polymer and Telomer. This, however, isn't always simple with the newest HTML5 + Javascript technologies. Meaning that GNOME's desktop technologies has an advantage here. Especially for mobile is this interesting (where from quite some time to come, network latency will be the problem numero uno). No, this is not the incentive driving toward obfuscation of code: the apps get cached just like other web content; what you say about latency is true in the general case, but not the case I'm pointing out. I'm making the point that HTML 5 enables longer term and off line use of cached apps, in a standardized way (a great improvement over google gears or adobe air). The issue encouraging obfuscation is *first time* use of applications, or updates to applications. Web applications can and often are updated much more often than conventional apps have been; it is a fundamental advantage they have due to the improved distribution channel. My point, fundamentally, is that we must ensure that free software alternatives never work *worse* than proprietary. This should be be a minimum standard we strive always to achieve. Best Regards, - Jim ___ foundation-list mailing list foundation-list@gnome.org http://mail.gnome.org/mailman/listinfo/foundation-list
Re: Reboot: Strategic goals for GNOME
See http://www.fsf.org/news/2009-07-mscp-mono for details. That article is a load of crap, a package of half truths. You are entitled to your opinion, but I think you're wrong. I invite people to read it and judge for themselves. Some of the points in the article -- not all -- deal with situations that may or may not occur, but that doesn't make them invalid or irrelevant. To judge the effects of a patent promise like this one, it is necessary to consider the possible situations that might arise. Implementing a free platform for C# is a good thing to do. If you would like to promote the use of C# itself, how about explaining to Novell and Microsoft that they need to fully implement said protection in an ironclad way for all the usual C# libraries. I spend a considerable amount of time doing this. It has taken time, and there would be no Community Promise, and there would be no Silverlight agreement (the one that has no special Novell provisions) without this work. Thank you for working on it, and I hope you eventually succeed. ___ foundation-list mailing list foundation-list@gnome.org http://mail.gnome.org/mailman/listinfo/foundation-list
Re: Reboot: Strategic goals for GNOME
It is not a matter of ostracizing anyone. We are glad that they use GNOME, but we must not say we are entirely happy about them as long as they contain non-free programs. But we are closely associated with these organizations. (Your original email said we should make sure we are not closely associated with them.) You're right about that, so I should clarify what I said. Accepting support and contributions of code from those companies is fine. Working closely with them on development of free software is good when it advances GNOME in general. What's a problem is if we are seen as endorsing non-free products. Thus, we should not express pride in these companies (in a general sense). Developing proprietary software is not just a foible -- it is the problem which GNOME exists to help solve. Yes, we can work with companies that distribute proprietary software, but we must avoid giving the impression we don't think that is bad. ___ foundation-list mailing list foundation-list@gnome.org http://mail.gnome.org/mailman/listinfo/foundation-list
