Google Chrome Web Browser on TinyCore?

[Jason W]

There also seems to be some not so clear branding rules that may be similar to Firefox that was mentioned on that page:

http://www.google.com/permissions/guidelines.html

http://www.google.com/permissions/brand_terms.html

I don't have time to delve into it now, but I didn't see an answer right off on whether we would need to rename our own build.  I will look more into it later.

[julianb]

You can call it Chromium if you want.

I think it may be against the rules to call any browser "Google Chrome" if you compile it yourself (as someone who doesn't work for the Google Chrome project).

[Arslan S.]

You can call it Chromium if you want.

I think it may be against the rules to call any browser "Google Chrome" if you compile it yourself (as someone who doesn't work for the Google Chrome project).

i will name it chromium-browser
and put a copyright notice under /usr/local/share/doc/chromium-browser

also there is the license in source code bsd style and as i understand as long as you dont use google brand to endorse your distribution with google reputation it is fine to distribute it

there are other distros have their own built from source chromium packages
http://code.google.com/p/chromium/wiki/LinuxChromiumPackages

[baz]

I just noticed the new build in the AppBrowser!! It is lightning fast, and uses much less memory than Shiretoko. Thanks for your great work!! Chrome and TinyCore make a great match.

[oz49erfan]

I only worked out today how to install apps onto TinyCore linux - I love it!

Just installed google chrome but when I ran

/usr/local/bin/chromium-browser

It came up with:

error while loading shared libraries: libdbus-glib-1.so.2: cannot open shared object file: no such file or directory

I ended up installing dbus.tcz and dbus-glib.tcz and it worked fine.

I thought you guys might want to know so you can update the dependencies for chromium-browser-686

Thanks for all the great work!

[Arslan S.]

gconf updated that's the reason, thanks for feedback

new GConf library depends on:

glib2 -> new dependency
dbus -> new dependency (dbus depends on expat2)
dbus-glib -> new dependecy
libxml2 -> new dependency

wish we had a recursive dep system 

[roberts]

gconf updated that's the reason, thanks for feedback

new GConf library depends on:

glib2 -> new dependency
dbus -> new dependency (dbus depends on expat2)
dbus-glib -> new dependecy
libxml2 -> new dependency

wish we had a recursive dep system 

I have incorporated recursive dep processing into tce-load, It is currently in testing.
However it would not be backward compatible, e.g., once deployed for a given extension, then that extension would not load on prior versions.

[Arslan S.]

i see but remember moving from tczl to tcz with tce-notify for older versions

a similar approach can be followed maybe?

[roberts]

You can't retract older versions.
You can't let older versions prevent progress.
Even when I write support programs to support older versions, I get reviews like this:
http://server.ericsbinaryworld.com/blog/2010/01/29/review-tiny-core-linux/

[Arslan S.]

ok no problem  

i have a question to you

let's say extension A dependends on extension B and extension B dependens on Extension C but extension A works without extension C in this case do i have to add extension C to dep list of extension A ?

let's say i did not add extension C as a dependency and loaded extension_A then if i try to load extension B extension C is not loaded and receiving error extension B is already loaded  

my overall question is do i have to recursively add every dependent extensions or not ?

[curaga]

It would be preferable. Even if ext_B can run without some extensions, say perl or some other interpreter, parts of it will be disabled, and users will eventually find out.

[MakodFilu]

When 2.8 was released I was wondering how many people would have been puzzled when upgrading and not finding any of the installed apps, then going back to read the release notes and setup a properly made onboot.lst

Almost no complaints, so for now the TC average user is geeky enough to understand the need for such changes and then adapt. It's not about such changes deserving a mayor version number, even small cosmetic changes could challenge a novel user. One sample: /tce/optional it is no longer about being 'optional', so changing the name to something like /tce/local-repository would clarify its purpose. But such a change would involve apps not starting until moved again to such a new location.

I don't think TC has to rethink anything: it's just the way it is and we know it is a good thing to be the way it is. If someone thinks 2.8 should really be called 0.2.8 that is fine, moreover if that someone thinks that getting to 1.0 means no major changes and stalled thinking for then on.

If 2.9 (or 3.0 or whatever) is not backwards compatible but is greater than any prior version, that is good for me.

[roberts]

Sometimes it is a matter of how best to get the word out for changes that affect extensions.

Perhaps it is too geeky to assume that one would read the change log for a new release.
Perhaps it is too much to ask for one to actually read the .info file to see the actual requirments of a selected extension.

Is there any reason for one to stay behind in the 2.x series and not stay current?
I would really like to release an updated tce-load with recursive dependency capability.

[MakodFilu]

I think I made myself clear in my last sentence but were a little confusing in the preceding paragraph. IMHO, TC doesn't need to rethink itself to be more conservative, quite the opposite. TC is really good in the way it doesn't stay the same thing, and making instead great jumps in usability every release.

Even if it sometimes suffer in the easyness of use. That is a bonus which, while frequently meet, is not tthe real aim.

I honestly think we all agre here.

[baz]

A newer version of Chrome is out that supports extensions - anyone know if it is supported on tc?