Tiny Core Linux
Tiny Core Extensions => TCE Bugs => Topic started by: tclfan on July 07, 2009, 10:33:24 PM
-
I do not know if it is just me - Firefox does not start anymore for me.
Specifics:
TCL 2.1 fresh LiveCD from ISO. No modifications/remastering.
Firefox freshly installed - both tce and tcz.
Icon installs fine, however clicking on it does nothing that is visible.
I do not know at what release point it started exhibiting this behaviour, but was behaving well recently...
-
It is missing the libasound dependency for those who do not run alsa as I have yet to add it in. Doing it now.
-
It is missing the libasound dependency for those who do not run alsa as I have yet to add it in. Doing it now.
Thanks much.
-
It is missing the libasound dependency for those who do not run alsa as I have yet to add it in. Doing it now.
Jason,
I know it is probably too much to ask, but is there any way to make a slim version of Firefox, without dependencies, sound, extra fat, etc. Just pure browser, like Opera. I know you may say: Just use Opera. Opera is great, however Firefox has a critical function - prints to PDF, which Opera doeas not have. Less critical - page rendering on some sites and better (smoother) font. Slim to the bone version of Firefox (Tiny Firefox?) would be a great asset to TCL...
-
@TCLFAN: did you just describe minefield? :D
About print to pdf - a workaround would be print to PS, convert to pdf using gs (ps2pdf is a part of Ghostscript)
-
@TCLFAN: did you just describe minefield? :D
Yes, Minefield crossed my mind, except I was missing PDf print. Thanks for the Ghostscript way, I was aware of this (actually it is used by some pdf printers). I may have to go this way, although it is more cumbersome than quick and easy... I'll check if Minefield is still available in TCE repository, I remember it was default in TCL 1, then changed to Firefox... Since then I was using Opera permanently installed and Firefox in Optional, but maybe Minefield will reduce the number of browsers needed...
-
I had considered making a custom build of Seamonkey to minimize resource usage. Curaga has minefield (Firefox 3.0.x) and maybe a custom build of Firefox 3.5 could be done. I didn't go ahead with Seamonkey as I didn't want to spend all my time ironing out the quirks of a custom build, but the need for faster and lighter browsing is definitely there. Perhaps Curaga or I could give Firefox 3.5 a go and see if it can't be trimmed down.
-
I believe printing to pdf comes from Gnome-print, which is a huge dependency and so not included in minefield.
I likely won't have time to mess with FF/Minefield in a long while, so Jason if you wish to update it it would be welcome.
-
I will go ahead then with a custom build of Firefox 3.5 and Seamonkey. Once the build details are set they shouldn't be too hard to keep current with each release.
These will be minimal/optimized builds and hopefully some performance gains can be realized as well as reduction in dependencies.
-
I will go ahead then with a custom build of Firefox 3.5 and Seamonkey.
These will be minimal/optimized builds and hopefully some performance gains can be realized as well as reduction in dependencies.
Jason,
Thank you very much. It is greatly appreciated, just to let you know...
-
Shiretoko is the new name of the custom Firefox. I probably won't build Seamonkey as custom as a minimal browser only install is available through the official installer. And the official build of Seamonkey performs quite well as it is.
-
Shiretoko is the new name of the custom Firefox.
My understanding of this is that Shiretoko (In this context) is a somewhat optimized version in relation to Firefox 3.5, similar to the way Minefield was in relation to Firefox. I did not have a chance to do any good comparison, but from a quick glance Firefox 3.5 appears to require about twice memory in relation to Minefield. Do we have any rough idea how much is Shiretoko optimized and perhaps how compares to Minefield?
Also as I understand Minefield will no longer be maintained and is replaced by Shiretoko as the new version?
-
I believe that minefield will stay in the repo for those who wish to use it, as long as it works.
-
I believe that minefield will stay in the repo for those who wish to use it, as long as it works.
This will be appreciated. Seems the most lean of FF flavors so far, this is perhaps before Jason may come up with more aggressively optimized version Shiretoko/Firefox, which would be great.
In the interim I will save Minefield TCE, just in case it disappears from repository...
-
Here is the config for Shiretoko:
http://distro.ibiblio.org/pub/linux/distributions/tinycorelinux/2.x/tce/src/shiretoko/mozconfig
It is still a hog, though the --enable-jemalloc option was used to hopefully trim memory usage. I took a look at the swiftfox patch that they used on version 3.5r3 and saw that it only changes some default settings like history retention and maximum connections to a server. It didn't look like it had things that would really change performance beyond being optimized for each specific archetecture. I built Shiretoko as i686 to perhaps improve performance; those with i586 or lower would be much better off with another browser choice.
I am definitely in favor of keeping Minefield available as the Firefox 3.0.x choice. I know they say not to use older browsers, but for non critical web surfing it would be nice to keep choices around for those with lower RAM machines. I may give a custom Bon Echo 2.0.0.20 gtk2 build a go to provide the most recent Firefox 2.x.
Choice is of course a good thing, and using an older browser version is taking advantage of the lower resource requirements while understanding the mild security risk it may involve. I heard it once said that practicing security is more important than patching for security. If you do not practice security but keep your system up to date, you may be at more risk than the user of older software releases that uses good security practices.
-
Those default setting changes can make a difference in perception of speed - for example connections per server. You go to a news site, open a few tabs. Even if the total time to load them all is the same, if more tabs start loading instantly it looks better to the user. :)
-
I see what you are saying though it is kind of like robbing Peter to pay Paul. On a super fast connection it would improve the perception of performance; those with slower connections would probably prefer for a few tabs to load fully before more started loading. But Firefox is obviously not made with slow machines or slow connections in mind. I will try some such modifications and see if helps any.
In fact, limiting the default size of that hideous urlclassifier3.sqlite file would be a modification that would help TC a lot. I will rebuild and change that to about 15MB at most. Those with persistent home can easily change that setting to be as big as they want and I will add that into the info file.
-
I am definitely in favor of keeping Minefield available as the Firefox 3.0.x choice... I heard it once said that practicing security is more important than patching for security. If you do not practice security but keep your system up to date, you may be at more risk than the user of older software releases that uses good security practices.
Thanks Jason for this assessment... Is there Minefield 3.0.11 TCZ available? The current is 3.0.4...
In addition to your point on security we also have in TCL several mitigating factors:
- It is Linux after all... Focus for security threat is Windows as most common.
- TCL session runs as user, not root, which limits how much malware can do
- TCL does not suffer from 'System Rot' - refreshes itself on each boot to 'pristine' state, which limits exposure to malware.
Putting all this together, the window of opportunity for malware seems narrow... Minefield should do fine too. Opera is a great browser and very lean, but the lack of printing to PDF is the biggest problem.
-
Rebuilt shiretoko and disabled the urlclassifier to eliminate that file altogether. Default max size if nothing is specified was either unlimited or 104MB, either being unnacceptable. Provided some other tweaks as well.
The cache size is limited to 20mb now by default. I ran shiretoko with youtube and surfed the web a while and the .mozilla directory never grows beyond 24MB altogether without that urlclassifier file. When I exited the app the .mozilla directory shrank to 9MB. It used to be common for me to see my .mozilla directory grow to over 150MB and that is dreadful on a live RAM based system. Persistent home users can easily enough change the settings to store as much as they want.
-
Thank you Jason for this. This is good news you eliminated that file. It was a cause of major headache for those appreciating efficiency...
Did you have a chance to do any other major optimization? What is your feeling of performance of this new Shiretoko, particularly compared to Minefield, i.e. memory and cpu utilization? Not quite benchmarks, but your opinion in TCL context?
-
Basically these are the optimizations: i686 build with -O3 optimization, eliminated urlclassifier altogether, set default cache to 20MB, reduced maximum default popups. The mozconfig file in the source directory lists the configure options for compiling.
I think that the difference in speed, memory usage, and such can be measured in a few percentage points between the official Firefox and a custom build. Either way you slice it or dice it, it is still Firefox and is resource intensive. Even the 2.0.0.20 build consumes almost the same memory as the current. Of course, correct me if anyone has some benchmarks that tell otherwise. But hopefully by at least eliminating the urlclassifier and trimming down default cache it will be more freindly for TC users, especially those that run with /home in RAM and back it up on shutdown.