What other browsers work on RPi?

one other browser is NetSurf.

The raspbian guys are saying good things about it.

http://www.raspberrypi.org/phpBB3/viewtopic.php?f=66&t=8438&start=28

A big thanks for the tip!  I tried out a couple images last weekend and used NetSurf.  It's a breath of fresh air indeed.  No JS means some sites don't function correctly (like this one, oy) but it is so much better than trying to interpret pages as pure text in lynx or pulling out my hair waiting for midori to load pages.

Thanks!

Drew

A big thanks for the tip!  I tried out a couple images last weekend and used NetSurf.  It's a breath of fresh air indeed.  No JS means some sites don't function correctly (like this one, oy) but it is so much better than trying to interpret pages as pure text in lynx or pulling out my hair waiting for midori to load pages.

Thanks!

Drew

Midori is one of many (over half a dozen) lightweight browsers all based on webkit.  Most of them have a single-page paradigm, but a few support tabs as well --- Midori and Uzbl-tabbed are the best known for that.

If Midori is giving you trouble, you might want to try some of the others.  I only care about open source ones, and of those, the ones I use occasionally other than Midori are:

• Uzbl http://www.uzbl.org (come in three varieties, one of them tabbed)
• LuaKit http://www.luakit.org
• Jumanji http://pwmt.org/projects/jumanji
• Surf http://surf.suckless.org/

Of those, only LuaKit gets any significant use here.  Other similar lightweight browsers that I haven't tried personally but are also open source are:

• Qupzilla http://www.qupzilla.com/
• Arora http://code.google.com/p/arora/

which don't appear to be available in Gentoo's Portage which may indicate that they have problems, or simply that they are new.  There's certainly no shortage of alternatives if Midori doesn't fit the bill.

Morgaine.

Have you tried NetSurf (which coder27 mentioned earlier) Morgaine, and if so what do you think of it?

@David: No, I haven't tried NetSurf, nor knew about it.  It's not available in Gentoo's Portage, but I'll grab the sources and build it longhand on my main machines:

• NetSurf - http://www.netsurf-browser.org/

As indicated in coder27's linked item, obtaining NetSurf on Pi under Raspbian should be a simple matter of

• apt-get install netsurf-gtk

This doesn't work on my plain Debian install though, as "apt-cache search netsurf" finds various GIF and BMP decoder libraries but no "netsurf-gtk" browser, even after an apt-get update.  I expect that Debian just needs to be told about the Raspbian package repository (assuming the two repos are compatible), which I haven't looked into yet.

Thanks to coder27 and yourself for mentioning it.

Morgaine.

I found a description of the Debian repo issues on the Raspbian site, specifically:

• http://www.raspbian.org/RaspbianFAQ#Can_I_mix_packages_from_the_Debian_repositories_with_Raspbian.3F
• http://www.raspbian.org/RaspbianFAQ#What_do_I_need_in_my_sources.list_file_to_access_the_Raspbian_repository.3F

Short version:  Raspbian uses armhf (Hard Float) architecture in contrast to the standard Debian ARM distro's armel which is soft float.  In general, you can't install any old package from an armhf system into an armel one and expect it to work.  There is a tool script "v7clean" that allows you to check whether a Raspbian package is armel compatible.

I haven't checked netsurf-gtk with v7clean yet.

Morgaine.

Morgaine,

  I think you may be misunderstanding what v7clean does.

My understanding is that it predicts whether object code

will run on raspbian, that is, it doesn't use any v7-only instructions.

It doesn't predict whether raspbian code will run on armel.

That's not what the code says, coder27.  I've got it here and the description is quite clear:

v7clean (from http://pastebin.com/BtSdvrXM ) says:

 

v7clean -- script to verify that a .deb and .udeb files are clean from armv7 code using the 'readelf' Linux utility.

Standard Debian on ARM is armv6l, so it must not have any ARMv7 instructions in it or it won't run.  The script checks the number of files containing v6 and v7 instructions, and if the v7 count is greater than zero, it outputs "v7_dirty", which means that the package won't run on arv6l.

I still think you're confused.  The raspbian guys are pulling code

from the debian v7 distro, and compiling for RPi (with different

compilation flags), and wrote the v7clean script to warn them when

that won't work due to v7-specific op codes.  They aren't concerned

about whether code from their raspbian distro will work on a soft-float

armel v6 version of debian, since they don't expect that to work due to

abi differences.

Interestingly, I've extended my copy of the script a little to show the actual CPU architecture tags for each file processed by readelf, and it shows that every .deb I've installed so far has ARM architecture v4T.

That's positively antique, it's the architecture implemented on the ARM922T which predates even Pi's ARM11.

coder27 wrote:

 

I still think you're confused.  The raspbian guys are pulling code

from the debian v7 distro, and compiling for RPi (with different

compilation flags), and wrote the v7clean script to warn them when

that won't work due to v7-specific op codes.  They aren't concerned

about whether code from their raspbian distro will work on a soft-float

armel v6 version of debian, since they don't expect that to work due to

abi differences.

Heh, I think you need to read the code a bit, it's very helpful to explain what's going on. 

The '6' and '7' have nothing to do with Debian v6 or v7.  It's the ARM architecture:

• ARMv4T as used in ARM922T and also accepted by Pi's ARM1176
• ARMv6 which is native to ARM11 and is also used in Cortex-M0
• ARMv7 as used in modern ARM CPUs like Cortex-M1/M3/M4/A8/9/15 (does not include Cortex-M0).

New architectures can often execute old instruction sets (it depends entirely on chosen core options), but old architectures can't execute newer instruction sets because ... well, because they're not clairvoyant.

Anyway, the v7clean tool checks which instruction set a package's files were compiled for, nothing else. You can use that information in many ways, it's just a low-level information tool.  Its name "v7clean" suggests that absence of ARMv7 arch tags was the desired property.

Presumably the Raspbian guys and gals are using it to check that their build is clean and hasn't accidentally pulled in libraries that were compiled for the wrong architecture --- for example (I'm guessing) they could be cross-compiling on a Pandaboard for ARMv6, but the Pandaboard is natively ARMv7 (Cortex-A8) so its native libraries are ARMv7 and they need to check that those haven't accidentally leaked in to their build.  While I don't know exactly what Raspbian are doing, I do know what the script does so it's straightforward to see how it can be used.

In our case it can be used similarly to determine whether a compiled package out there somewhere in the world of .deb repos will run on Pi, since ARMv7 instructions won't run on our ARM1176.

Morgaine.

> The '6' and '7' have nothing to do with Debian v6 or v7.  It's the ARM architecture:

agreed.  didn't mean to imply otherwise.

>In our case it can be used similarly to determine whether a compiled package out there somewhere in the world of .deb repos will run on Pi, since ARMv7 instructions won't run on our ARM1176.

I think you also need to worry about the abi, and v7clean doesn't report that.

I don't think raspbian-built packages will generally run on RPi debian distros

even if v7clean shows no problems.