I believe there is a setting to force enable the hardware acceleration, but i forget what its called...
The prefs for hardware acceleration are layers.acceleration.disabled (whether it is enabled at all) and layers.acceleration.force-enabled (whether to enable it even if the system graphics drivers are not known to be stable enough).
So, enabling the first is enough if your drivers are good, and if you want to run it even with potentially problematic drivers, then both.
Significantly more interesting would be a GTK that draws with PPAPI and runs in NaCl, which would allow you to develop a web app using GTK, deploy it on the web, and run it (safely) within your browser.
I agree that running a GTK app entirely clientside would be very interesting. There is another way to do that: Compile a GTK app from C to JavaScript using Emscripten. (I wrote Emscripten, sorry to plug my own project, but I'd be thrilled if someone used it to do something like this!)
And before someone chimes in and posts this saying that they're working on it, take a look again, that page hasn't been updated since May 2010.
I am afraid that page is out of date, I edited the 'Status' section of it now - thanks for pointing it out!
The status of multiprocess Firefox is that we have been working very hard at it, and made lots of progress. In fact Firefox Mobile is multiprocess already, you can run it right now and see that the UI remains responsive even if you load lots of tabs, JS heavy sites, etc. So that shows that rendering, networking, etc. etc. are ready for multiprocess.
But getting desktop Firefox to be multiprocess will take more time, since there is a lot more stuff to support there, in particular addons, developer tools, etc. The plan is to finish that stuff later this year.
Yes, Qt in its current form will be freely available, but what if nobody from Nokia works on it? No more new features?
Yes, this is exactly why it is important we have both GTK and Qt as open source toolkits - we can't afford to bet on a single one. Right now, it looks like the amount of development put into Qt will decrease very significantly, and GTK will become the faster-moving one. Good timing for them with GTK 3.0, actually.
But again, my point is that we don't want to bet on a single toolkit (or a single open source OS, or web browser, or anything). Here's to the continued success of both Qt and GTK!
You are correct that not all open source licenses are free software. I intended FOSS and not just open source, I apologize if that was not clear.
You are also correct that the GPL allows you to charge money for software. However it is important to be clear - you would still be providing the software under the GPL, which gives the users all the regular software freedoms.
To be more specific, H.264's business model is incompatible with the the W3C, with the GPL, with Debian's policies on openness, etc. For those reasons I think H.264 is not suitable for the open web.
Mozilla, like all market centric organisations, does not care about technical features, usefulness, usability or technical competence. Like all such companies, they care about only one thing--the latest fad. They will follow this fad, be it graphical, academic, ergonomic and they will follow it regardless of its effect, positive or negative, on their overall product.
I'm a Firefox dev, and I have no idea how you came to this opinion of Mozilla's development practices.
Anyhow, all of our development is in the open - you can look at weekly meeting notes on our wiki, read debate on our mailing lists, details of decision making on IRC and bugzilla. So you can see exactly how we make the decisions that we make. I honestly don't see how you can read all that stuff, and say that we are 'market centric'.
You can argue with particular decisions that are made - often after a lot of debate (again, see our mailing lists and bugs). No body is perfect. I personally don't agree with all of them. But to say they are made due to 'following fads' - that's pretty funny:)
There are two problems with the let-the-browser-use-OS-codecs argument:
First, the patented codec remains patented. The problem just goes down to the OS, or in other words: It is not possible to legally implement an open source OS to power such a browser. In such a world, you can only use closed-source OSes to access the web (sometimes through open source browsers). That is a very bad outcome, and against the idea of the open web, and open source in general.
Devs from Firefox, Opera, etc. have detailed many technical issues with using OS codecs, that make them not want to go that route. Of course there are benefits as well, but overall browsers vendors have decided to only use OS codecs when they also make the OS (IE on Windows, Safari on Mac), that is, when they control the entire stack anyhow.
I kinda like Tab Candy. I use it at work to keep work related and other browsing activities cleanly seperated. What I don't like is the lack of statusbar: I have been looking in the statusbar to look where a link leads since the nineties and now they move it to the addressbar of all places.
Well, the reason it's there does make logical sense: The current URL is there, and when you hover over a link, the next URL is shown after it. So you can see which URL is going to which.
But I am not sure it makes practical sense. It's a little confusing for me right now. I'm not sure whether I'll get used to it and love it (like the awesomebar), or whether it will just remain 'odd'. I'm giving it a chance though.
H.264 is a real standard, developed and governed by a multi-party process, recognized by international standards organizations, and extensively documented.
That is all well and good, but, the fact stands that it is impossible to legally create an open source H.264 enabled browser (in countries where patents are valid). Because of that, H.264 is simply not suitable as a standard for the open web - if only closed-source browsers can view the web, it is no longer open.
To clarify that point: Even if Google or Mozilla paid MPEG-LA royalties for their own browsers, the browsers would not be freely redistributable, which violates a fundamental principle of free and open source software. MPEG-LA's current business model is simply not compatible with open source software and the open web.
The interesting question would be, what would happen if MPEG-LA made an exception for open source implementations of H.264. Total guess, but I suspect Google approached MPEG-LA with that or something similar, got rebuffed, and went through on their bluff to remove H.264 from Chrome. MPEG-LA's next move will be interesting (remember that they already made H.264's licensing more lenient several times, in response to Google's previous moves of buying On2 and announcing WebM).
Personally, I'd recommend Python as a starting language...
I might, if there were a simple, cross-platform, one-click-install download bundle for all of the major operating systems which included pygame and a decent IDE, and even then I'd target motivated 13 year olds as the youngest users.
You can run Python directly in the browser - no need for installs at all. In fact one of the motivations for getting CPython working in JavaScript was for things like this. (Note: It doesn't work perfectly yet, but all the hard work is already done.)
For a basic IDE, that demo includes Skywriter. Integrating some additional features like load/save etc. would make it very usable I think.
Regarding pygame: It would be possible to get something like that working in the browser, targeting an HTML canvas element. See this demo for C++ code written against SDL, compiled into JavaScript and an SDL implementation that targets a canvas.
Re:Will it support languages other than JavaScript
on
Firefox 4 Beta 8 Up
·
· Score: 1
A neat demo, to be sure, but it's not compiling. It's just interpreting Python into JavaScript which is itself interpreted.
Just to clarify, CPython is compiled (not interpreted) from C into JavaScript. (Then Python is interpreted inside that, just as CPython interprets code normally.)
The first step is compilation, since C is actually translated into JavaScript. There isn't a runtime that interprets it. Unless you mean the JavaScript engine itself, which interprets the JavaScript into which it's compiled - but that engine too, in modern browsers, will compile JavaScript into machine code, and not interpret it.
Anyhow, maybe that's what you meant and were just being brief, sorry if so. I just wanted to clarify that for other people reading.
I agree that optimally, the best thing would be to allow it to be toggled. I wasn't working on that, so I don't know the technical reasons for the decision to do it the way it was, sorry.
About performance: It does cause some lag, but most of that will be fixed for FF4 final. It even works fast on smartphones in mobile firefox.
As for not liking your changes, please consider making changes to base functionality of a program element optional.
I agree it's important. We try to do that when feasible, and we're actually making plans now to do that more, some of that discussion appears in this thread.
The big issue, though, it FF dev's attitude of 'F-U, learn to like it.'
Not sure where you got that impression - I'm a Firefox dev, and I definitely don't think that way. As I said above, I'm sad when people don't like our changes.
Sorry, I don't know much about how it's done on Windows. All I know is that on Linux, it is generally/usr/lib/firefox/plugins and ~/.mozilla/extensions
I like that firefox wants to be fast and everything but does it even matter anymore. I have at least 10-15 extensions in my browser and at least one of them keep crashing/leaking memory etc. Does this release have a better plugin container for these extensions?
Firefox 4 will ship with much better plugin and extension support. Plugins already run in a separate process in 3.6, while in FF4 you can also write addons that run that way (using Jetpack). Note that addons will need to have changes made to them, so this won't immediately fix all of these issues if you use older plugins. But, it's a major step forward, and most major plugins are already in the process of updating to FF4.
If by "enhancements" they mean "throw the awesomebar out a window", I'm all for it.
As a long time Firefox user, this has been one of the most infuriating things, as they continually remove or fuck up useful features. The Mozilla developers seem obsessed with changing things just to make them different. The list of things they have eliminated or made less useful is almost endless. I'm sure they can give us all sorts of rationalizations for what they do, but it's all bullshit. Making things less useful is not an improvement.
I'm a Firefox developer. I understand that it can seem that way, but trust me, a lot of thought goes into each change we make. I'm not saying we are always right, or even always right for most people - nobody's perfect. But I do think that overall we do a good job, in picking what to change, and for the specific stuff you dislike, most of it should be configurable through prefs.
But, I realize that doesn't help you, and I'm sorry that some of our changes are not to your taste.
There's more to a browser than rendering and Javascript performance. Firefox has become a hard disk hog. It almost continually writes to disk, which can be very slow, for example on netbooks with first generation SSDs or when you keep your profile on a USB stick (portable Firefox).
You can disable the disk cache, that would help in situations where the disk is slow. It's disabled in Mobile Firefox, for example.
Desktop Firefox is tuned for typical desktop/laptop machines, where it makes sense to cache on disk quite a bit. I think you raise a very good point, as netbooks are getting more popular, Firefox should be tuned for them as well.
Android is not Google's OS any more than Linux is a Red Hat OS. It is an OS produced by 78 different companies who are members of the Open Handset Alliance and also has numerous unaffiliated contributors.
Android is developed by Google behind closed doors. I am unsure of whether those other companies work with it behind those same closed doors, or not. But it's development is controlled by Google in a way very unlike Red Hat's development of Linux (or RHEL).
You can take the released Android code and use it however you want. But practically speaking, Google still maintains a lot of control through the closed-doors development model. So it is fair to say Android is "Google's OS", but I would agree that that can be misunderstood to mean proprietary (which the released code most certainly is not), so maybe it's a bad choice of phrase.
As I said before, I don't know if the other companies work with Google behind closed doors on the development - the development is behind closed doors, so we can't tell. But even if they do, it's still controlled by Google. For practical purposes, if you want to launch a device with Android, you need to partner with Google - only that way can you work on the latest code, and be aware of features in development, so your product when it finally launches will not use an outdated OS.
Kudos to Google though for open sourcing it, when they do release it into the world. I am not saying Android is bad or anything. Just that it is controlled by Google. I'm a fan of Android myself.
Regarding the story itself: Google is 100% right. Patents apply to 'specific machines', or should according to the law, so Google should be free to develop software free from worry from patent lawsuits. Hardware companies may need to enter patent agreements for their specific products. Google is arguing for a model of patents that makes a lot more sense than the one currently in practice in the US, and it happens to be the one that is on the books, so hopefully Google will prevail.
BTW: New & faster Firefox for N810? Pretty please? Or should I stop hoping to really use that beast? A clear no is better than an endless maybe.
Sorry, we support the N900 but not the N810. There are just so many mobile hardware and software variations, we don't have the time to make Fennec run properly on them all I'm afraid.
I like the Nokia devices myself - familiar Linux environment, open, etc. - so I'm sad about this. But we'll be supporting the future versions of them (running MeeGo).
That's a significant change in size. Usually when such a drastic change occurs, it means they originally included many things that weren't necessary. That leads me to believe they really didn't care about this before.
That's not the case - we both care a lot about this, and did not include unnecessary stuff. See this blog post, specifically the section "Installation size: Problems and solutions", for the reasons.
Basically, Firefox has some unique challenges to overcome, in that unlike other mobile browsers, it includes a complete web rendering engine (Gecko), unlike others which use the bundled WebKit. With some tricky methods (the custom linker mentioned there, and other stuff), it's now much better. You can also move a large part of it to SD now.
We're going to continue working on this - we know how much users care about it, and so do we!
Slashdot Mirror
I believe there is a setting to force enable the hardware acceleration, but i forget what its called...
The prefs for hardware acceleration are layers.acceleration.disabled (whether it is enabled at all) and layers.acceleration.force-enabled (whether to enable it even if the system graphics drivers are not known to be stable enough).
So, enabling the first is enough if your drivers are good, and if you want to run it even with potentially problematic drivers, then both.
Significantly more interesting would be a GTK that draws with PPAPI and runs in NaCl, which would allow you to develop a web app using GTK, deploy it on the web, and run it (safely) within your browser.
I agree that running a GTK app entirely clientside would be very interesting. There is another way to do that: Compile a GTK app from C to JavaScript using Emscripten. (I wrote Emscripten, sorry to plug my own project, but I'd be thrilled if someone used it to do something like this!)
And before someone chimes in and posts this saying that they're working on it, take a look again, that page hasn't been updated since May 2010.
I am afraid that page is out of date, I edited the 'Status' section of it now - thanks for pointing it out!
The status of multiprocess Firefox is that we have been working very hard at it, and made lots of progress. In fact Firefox Mobile is multiprocess already, you can run it right now and see that the UI remains responsive even if you load lots of tabs, JS heavy sites, etc. So that shows that rendering, networking, etc. etc. are ready for multiprocess.
But getting desktop Firefox to be multiprocess will take more time, since there is a lot more stuff to support there, in particular addons, developer tools, etc. The plan is to finish that stuff later this year.
Yes, Qt in its current form will be freely available, but what if nobody from Nokia works on it? No more new features?
Yes, this is exactly why it is important we have both GTK and Qt as open source toolkits - we can't afford to bet on a single one. Right now, it looks like the amount of development put into Qt will decrease very significantly, and GTK will become the faster-moving one. Good timing for them with GTK 3.0, actually.
But again, my point is that we don't want to bet on a single toolkit (or a single open source OS, or web browser, or anything). Here's to the continued success of both Qt and GTK!
You are correct, I should have been more clear.
It is at odds with the GPL, MPL, etc., and for that matter the DFSG, and even the W3C. That makes it unusable for the open web IMHO.
You are correct that not all open source licenses are free software. I intended FOSS and not just open source, I apologize if that was not clear.
You are also correct that the GPL allows you to charge money for software. However it is important to be clear - you would still be providing the software under the GPL, which gives the users all the regular software freedoms.
To be more specific, H.264's business model is incompatible with the the W3C, with the GPL, with Debian's policies on openness, etc. For those reasons I think H.264 is not suitable for the open web.
Mozilla, like all market centric organisations, does not care about technical features, usefulness, usability or technical competence. Like all such companies, they care about only one thing--the latest fad. They will follow this fad, be it graphical, academic, ergonomic and they will follow it regardless of its effect, positive or negative, on their overall product.
I'm a Firefox dev, and I have no idea how you came to this opinion of Mozilla's development practices.
:)
Anyhow, all of our development is in the open - you can look at weekly meeting notes on our wiki, read debate on our mailing lists, details of decision making on IRC and bugzilla. So you can see exactly how we make the decisions that we make. I honestly don't see how you can read all that stuff, and say that we are 'market centric'.
You can argue with particular decisions that are made - often after a lot of debate (again, see our mailing lists and bugs). No body is perfect. I personally don't agree with all of them. But to say they are made due to 'following fads' - that's pretty funny
I kinda like Tab Candy. I use it at work to keep work related and other browsing activities cleanly seperated. What I don't like is the lack of statusbar: I have been looking in the statusbar to look where a link leads since the nineties and now they move it to the addressbar of all places.
Well, the reason it's there does make logical sense: The current URL is there, and when you hover over a link, the next URL is shown after it. So you can see which URL is going to which.
But I am not sure it makes practical sense. It's a little confusing for me right now. I'm not sure whether I'll get used to it and love it (like the awesomebar), or whether it will just remain 'odd'. I'm giving it a chance though.
That's a standard patent retaliation clause, that many open source licenses (Apache, etc.) include. There is nothing nefarious about it.
H.264 is a real standard, developed and governed by a multi-party process, recognized by international standards organizations, and extensively documented.
That is all well and good, but, the fact stands that it is impossible to legally create an open source H.264 enabled browser (in countries where patents are valid). Because of that, H.264 is simply not suitable as a standard for the open web - if only closed-source browsers can view the web, it is no longer open.
To clarify that point: Even if Google or Mozilla paid MPEG-LA royalties for their own browsers, the browsers would not be freely redistributable, which violates a fundamental principle of free and open source software. MPEG-LA's current business model is simply not compatible with open source software and the open web.
The interesting question would be, what would happen if MPEG-LA made an exception for open source implementations of H.264. Total guess, but I suspect Google approached MPEG-LA with that or something similar, got rebuffed, and went through on their bluff to remove H.264 from Chrome. MPEG-LA's next move will be interesting (remember that they already made H.264's licensing more lenient several times, in response to Google's previous moves of buying On2 and announcing WebM).
I might, if there were a simple, cross-platform, one-click-install download bundle for all of the major operating systems which included pygame and a decent IDE, and even then I'd target motivated 13 year olds as the youngest users.
You can run Python directly in the browser - no need for installs at all. In fact one of the motivations for getting CPython working in JavaScript was for things like this. (Note: It doesn't work perfectly yet, but all the hard work is already done.)
For a basic IDE, that demo includes Skywriter. Integrating some additional features like load/save etc. would make it very usable I think.
Regarding pygame: It would be possible to get something like that working in the browser, targeting an HTML canvas element. See this demo for C++ code written against SDL, compiled into JavaScript and an SDL implementation that targets a canvas.
A neat demo, to be sure, but it's not compiling. It's just interpreting Python into JavaScript which is itself interpreted.
Just to clarify, CPython is compiled (not interpreted) from C into JavaScript. (Then Python is interpreted inside that, just as CPython interprets code normally.)
The first step is compilation, since C is actually translated into JavaScript. There isn't a runtime that interprets it. Unless you mean the JavaScript engine itself, which interprets the JavaScript into which it's compiled - but that engine too, in modern browsers, will compile JavaScript into machine code, and not interpret it.
Anyhow, maybe that's what you meant and were just being brief, sorry if so. I just wanted to clarify that for other people reading.
I agree that optimally, the best thing would be to allow it to be toggled. I wasn't working on that, so I don't know the technical reasons for the decision to do it the way it was, sorry.
About performance: It does cause some lag, but most of that will be fixed for FF4 final. It even works fast on smartphones in mobile firefox.
As for not liking your changes, please consider making changes to base functionality of a program element optional.
I agree it's important. We try to do that when feasible, and we're actually making plans now to do that more, some of that discussion appears in this thread.
The big issue, though, it FF dev's attitude of 'F-U, learn to like it.'
Not sure where you got that impression - I'm a Firefox dev, and I definitely don't think that way. As I said above, I'm sad when people don't like our changes.
Sorry, I don't know much about how it's done on Windows. All I know is that on Linux, it is generally /usr/lib/firefox/plugins and ~/.mozilla/extensions
Can you give an example of removing functionality, so I more clearly understand what you mean?
I like that firefox wants to be fast and everything but does it even matter anymore. I have at least 10-15 extensions in my browser and at least one of them keep crashing/leaking memory etc. Does this release have a better plugin container for these extensions?
Firefox 4 will ship with much better plugin and extension support. Plugins already run in a separate process in 3.6, while in FF4 you can also write addons that run that way (using Jetpack). Note that addons will need to have changes made to them, so this won't immediately fix all of these issues if you use older plugins. But, it's a major step forward, and most major plugins are already in the process of updating to FF4.
As a long time Firefox user, this has been one of the most infuriating things, as they continually remove or fuck up useful features. The Mozilla developers seem obsessed with changing things just to make them different. The list of things they have eliminated or made less useful is almost endless. I'm sure they can give us all sorts of rationalizations for what they do, but it's all bullshit. Making things less useful is not an improvement.
I'm a Firefox developer. I understand that it can seem that way, but trust me, a lot of thought goes into each change we make. I'm not saying we are always right, or even always right for most people - nobody's perfect. But I do think that overall we do a good job, in picking what to change, and for the specific stuff you dislike, most of it should be configurable through prefs.
But, I realize that doesn't help you, and I'm sorry that some of our changes are not to your taste.
There's more to a browser than rendering and Javascript performance. Firefox has become a hard disk hog. It almost continually writes to disk, which can be very slow, for example on netbooks with first generation SSDs or when you keep your profile on a USB stick (portable Firefox).
You can disable the disk cache, that would help in situations where the disk is slow. It's disabled in Mobile Firefox, for example.
Desktop Firefox is tuned for typical desktop/laptop machines, where it makes sense to cache on disk quite a bit. I think you raise a very good point, as netbooks are getting more popular, Firefox should be tuned for them as well.
Android is not Google's OS any more than Linux is a Red Hat OS. It is an OS produced by 78 different companies who are members of the Open Handset Alliance and also has numerous unaffiliated contributors.
Android is developed by Google behind closed doors. I am unsure of whether those other companies work with it behind those same closed doors, or not. But it's development is controlled by Google in a way very unlike Red Hat's development of Linux (or RHEL).
You can take the released Android code and use it however you want. But practically speaking, Google still maintains a lot of control through the closed-doors development model. So it is fair to say Android is "Google's OS", but I would agree that that can be misunderstood to mean proprietary (which the released code most certainly is not), so maybe it's a bad choice of phrase.
As I said before, I don't know if the other companies work with Google behind closed doors on the development - the development is behind closed doors, so we can't tell. But even if they do, it's still controlled by Google. For practical purposes, if you want to launch a device with Android, you need to partner with Google - only that way can you work on the latest code, and be aware of features in development, so your product when it finally launches will not use an outdated OS.
Kudos to Google though for open sourcing it, when they do release it into the world. I am not saying Android is bad or anything. Just that it is controlled by Google. I'm a fan of Android myself.
Regarding the story itself: Google is 100% right. Patents apply to 'specific machines', or should according to the law, so Google should be free to develop software free from worry from patent lawsuits. Hardware companies may need to enter patent agreements for their specific products. Google is arguing for a model of patents that makes a lot more sense than the one currently in practice in the US, and it happens to be the one that is on the books, so hopefully Google will prevail.
Sorry, yeah, I meant 'any more'. The current beta and newer versions aren't being tested on the N810, while older versions work, as you said.
BTW: New & faster Firefox for N810? Pretty please? Or should I stop hoping to really use that beast? A clear no is better than an endless maybe.
Sorry, we support the N900 but not the N810. There are just so many mobile hardware and software variations, we don't have the time to make Fennec run properly on them all I'm afraid.
I like the Nokia devices myself - familiar Linux environment, open, etc. - so I'm sad about this. But we'll be supporting the future versions of them (running MeeGo).
That's a significant change in size. Usually when such a drastic change occurs, it means they originally included many things that weren't necessary. That leads me to believe they really didn't care about this before.
That's not the case - we both care a lot about this, and did not include unnecessary stuff. See this blog post, specifically the section "Installation size: Problems and solutions", for the reasons.
Basically, Firefox has some unique challenges to overcome, in that unlike other mobile browsers, it includes a complete web rendering engine (Gecko), unlike others which use the bundled WebKit. With some tricky methods (the custom linker mentioned there, and other stuff), it's now much better. You can also move a large part of it to SD now.
We're going to continue working on this - we know how much users care about it, and so do we!