McGrath: Proposal for a new Fedora project
McGrath: Proposal for a new Fedora project
Posted Oct 1, 2010 18:48 UTC (Fri) by Kit (guest, #55925)In reply to: McGrath: Proposal for a new Fedora project by flammon
Parent article: McGrath: Proposal for a new Fedora project
I can only see this /possibly/ working if you do the same thing as Chrome OS: target devices at the bottom end of the netbook range... but then again, Android is already stealing ChromeOS's niche- with the advantages of local applications!
(the Quake 2 demo was impressive... for a web browser. Remember, that's a -thirteen- year old game they got to work... and only using unreleased browsers...)
Posted Oct 1, 2010 19:35 UTC (Fri)
by flammon (guest, #807)
[Link] (12 responses)
Posted Oct 1, 2010 20:11 UTC (Fri)
by oak (guest, #2786)
[Link] (7 responses)
Apparently you have no clue about how much these use memory. If you have your "web-apps" as separate processes, they are way heavier RAM-wise than Gtk or Qt. For starters, normal UI toolkits don't run virtual machines or use JIT...
> The write once run anywhere promise is much closer to reality. Even I9 is stepping up and putting in an effort to follow the standard.
Hm. I'm still getting a Java Déjà vu.
Posted Oct 1, 2010 21:30 UTC (Fri)
by cmccabe (guest, #60281)
[Link]
By the way, when Java was still under development, one of the codenames it went by was "Oak."
Posted Oct 2, 2010 22:54 UTC (Sat)
by flammon (guest, #807)
[Link] (5 responses)
Write once run everywhere is much more real today than it ever was. HTML5 and ECMAScript are public standards that are not controlled by any individual company, unlike Java and .NET.
Posted Oct 3, 2010 19:41 UTC (Sun)
by oak (guest, #2786)
[Link] (3 responses)
And if they were in the same process, one can of course do the same with native code to save memory too...
> I think memory sharing and usage optimization is next and a few ideas will be borrowed from the hypervisor guys.
In that case there's same code (or data) bin all these VM instances which can be shared.
If user is surfing a single site, s/he may have multiple pages open for it. If code on those pages share common JS "library/ies", the JITed code for those could be shared. If user has open pages for different sites, I doubt them to share much code as JavaScript isn't well known for having established libraries that are shared by everybody on the net...
Data is mainly images I think. Except for things like site backgrounds and smaller images, images are probably page specific (I would assume browser to already share & cache images that are commonly used). In native applications images come for common widget & icon theme that is shared by all the applications using the same widget set. I don't see that happening for web apps.
And lastly you have the memory overhead that comes just from having a VM & GC. That's always going to eat memory than native non-GC code unless that has leaks (which may be easier to avoid with higher level language & GC).
> HTML5 and ECMAScript are public standards that are not controlled by any individual company, unlike Java and .NET.
I'm not so sure that the backend code for these HTML5 applications is written in ECMAScript. Java or .NET sounds more likely for that...
Posted Oct 9, 2010 21:20 UTC (Sat)
by nix (subscriber, #2304)
[Link] (2 responses)
See this?
RSS VSZ STIME TIME COMMAND
That little bugger is making several hundred GCed allocations a second, incrementally GCing as it goes (using the Lua 5.1.4 collector), and has been doing that for a couple of weeks now. Memory usage attributable to GC and heap fragmentation (overhead with respect to memory usage of GCless implementation at startup), across all that time: perhaps 1-2Mb.
Posted Oct 9, 2010 21:33 UTC (Sat)
by oak (guest, #2786)
[Link] (1 responses)
If your example was of native code using GC and not having JIT, 1-2MB overhead sounds on the largish side for that sized program, but it of course depends completely on how dynamic your program's memory usage is.
Whether the program does lots and very differently sized allocs and how good its allocation patterns are. Heap works like stack so one should in general alloc last things you're going to free first if you want to minimize fragmentation. The allocator you use may utilize buckets for smaller alloc sizes which can affect this or not.
GC and interpreted languages of course have other advantages, but the topic was memory overhead. :-)
Posted Oct 10, 2010 0:57 UTC (Sun)
by nix (subscriber, #2304)
[Link]
1-2Mb overhead, well, yes, it seems excessive because it was tuned to find a good tradeoff between GC frequency/intensity and CPU consumption. (I suspect that most of that overhead is actually heap fragmentation, which even a non-GCed program is exposed to.)
(We are in luck sizewise, though: most of the allocations are the same size. Not all, but most.)
Posted Oct 3, 2010 22:17 UTC (Sun)
by Wol (subscriber, #4433)
[Link]
Cheers,
Posted Oct 2, 2010 1:08 UTC (Sat)
by vonbrand (subscriber, #4458)
[Link] (1 responses)
And gecko will run on what? It doesn't exist in a vacuum... neither is "let HTML replace X11" viable, whatever draws HTML has to do so on something...
Posted Oct 2, 2010 13:32 UTC (Sat)
by flammon (guest, #807)
[Link]
Posted Oct 2, 2010 3:55 UTC (Sat)
by elanthis (guest, #6227)
[Link] (1 responses)
That's like saying that there's a huge pool of high-school physics teacher who can now contribute to solving cold fusion.
I've worked in the web industry for years. The last freaking people you want touching code are web developers. They are -- with very few exceptions -- utterly freaking useless for anything other than building broken, slow, buggy applications that are just hodge-podges of cut-n-pasted jQuery scripts (which themselves are atrocious monstrosities of poor engineering) that function so long as you don't look at them the wrong way. The fact that there are a ton of them doesn't mean shit other than that it doesn't take much effort to go from knowing nothing to knowing enough to be considered as a web developer. there's a TON of people who breath air, but that doesn't mean they're qualified professionals when it comes to wind-powered electric-generator engineering.
The cool web apps you see springing up are not the work of web developers. They're the work of real programmers -- people with an extensive background in C, LISP, Java, or all of the aforementioned -- who decided to toy around with HTML and JS.
The really goofy thing is thinking that a browser is the best platform for application development. It isn't. You're confusing a popular application with its feature set, which are really two distinct things. You don't need a browser, you just need a development environment that has the advantages of a browser (and ideally without its disadvantages). What you're asking for are:
(a) a toolkit that focuses on content, semantics, appearance, and logic as four distinctive entities. HTML is a crappy language to work with, and SVG is only marginally better. CSS is HUGELY limiting. there are better models that exist today, and they exist without the huge legacy cruft of crap that browsers need to support those old HTML, old CSS, and old JS files that make up 99% of the Web today.
(b) a very fast but easy to use programming language, that lets the programmer focus on his application's features and algorithms instead of on tons of boilerplate, memory management, and other low-level details that have been solved a billion times over. once again, there are other languages that fill this niche that do not have the historic mistakes of JavaScript (global-by-default variables, confusing for-each syntax, barely present standard library, lack of a module system, and just a ton of language features that only the native-code backend can hook into; look no further than the "magic" behind document.location that you can't pull off using pure javascript code).
(c) easy XML and JSON processing. once again, libraries already exist for this, and are wrapped up in just as easy to use APIs for easy to use languages. even better, there are libraries for even more formats out there, for those cases when XML is too stupid (most cases) and JSON is still not condense enough (which happens way more often than your average low-bar web programmer could even begin to realize, out here in Real Programmer Land).
(d) write-once, run-anywhere computing. again, exists many times over. the problem with this approach is that it's impossible to actually pull off without running into the exact same problems that JavaScript, Java, C#, Python, or so on have. the only way for a platform to be complete is to offer access to the native hardware, which in turn requires the platform to be low-level. Without hardware access, you require the platform to include a hardware abstraction for every possible piece of hardware that could exist. the web browser is still massively limited in what it can achieve, which is why we're still adding tons of new APIs (and massively bloating the browser platforms) at such a rapid pace. and unless those platforms actually _are_ updated frequently (which is not the case for IE, or even the mobile platforms that never release updated OSes for old hardware), you still end up with a write-once, run-on-some-platforms ecosystem.
(e) a project focused on all these things. go start your own, you don't need Fedora to do it for you. Fedora already has a goal and a vision. instead of forcing another project to become something else entirely, just start a new project to realize your vision. if the community believes your idea has merit, they will contribute; if they don't, you'll flounder on your own with bringing an existing successful project down with you.
The browser is a nice model or prototype of what you want, but it isn't the final product you want.
Posted Oct 4, 2010 3:34 UTC (Mon)
by servilio-ap (subscriber, #56287)
[Link]
Here are the points:
McGrath: Proposal for a new Fedora project
McGrath: Proposal for a new Fedora project
McGrath: Proposal for a new Fedora project
McGrath: Proposal for a new Fedora project
McGrath: Proposal for a new Fedora project
McGrath: Proposal for a new Fedora project
7464 9076 Sep27 02:52:33 ekeyd
McGrath: Proposal for a new Fedora project
McGrath: Proposal for a new Fedora project
McGrath: Proposal for a new Fedora project
Wol
McGrath: Proposal for a new Fedora project
McGrath: Proposal for a new Fedora project
McGrath: Proposal for a new Fedora project
McGrath: Proposal for a new Fedora project
(a) a toolkit that focuses on content, semantics, appearance, and logic as four distinctive entities. HTML is a crappy language to work with, and SVG is only marginally better. CSS is HUGELY limiting. there are better models that exist today
That sounds interesting, can you give us some links or names, please?