|
OpenBSD Packages and Ports Installation and upgrading of packages and ports on OpenBSD. |
|
Thread Tools | Display Modes |
|
||||
The ports tree can tell you all about dependencies. You may have missed the use of the ports tree in post number 9 above. I used it to count dependencies for you, so that you didn't have to post page after page of them here.
Had I not shovelled the output of the full-run-depends target into wc(1), you would have seen a tsort(1)-compatible package list for each port. For more on what the ports tree make(1) targets can do for you, see the ports(7) and bsd.port.mk(5) man pages. There's a great deal of information available. |
|
||||
Quote:
|
|
|||
Quote:
See this thread for more details. |
|
|||
IMO NetSurf is the most promising lightweight browser long‐term.
It has good licensing: GPLv2 core, MIT libraries. (Compare to Dillo’s GPLv3+.) There’s active work on improving JavaScript and DOM support. The biggest problem with NetSurf is its GTK frontend. That brings in a huge pile of dependencies; NetSurf itself depends only on a handful of packages. The GTK frontend also has some unavoidable problems, like aborting in low‐memory situations. Luckily, NetSurf is not tied to any particular frontend. Besides the GTK frontend, there are Cocoa, Haiku, AmigaOS, and SDL frontends. (If I recall correctly, the bug mentioned earlier than this thread where text overlaps is limited to GTK/Cairo, and doesn’t affect other frontends.) There’s also ongoing work to abstract the browser core into a library to make new frontends even easier to develop. One project I hope to get around to is trying to make a libagar frontend. This would remove the need for all those GTK sub‐dependencies. Quote:
__________________
Many thanks to the forum regulars who put time and effort into helping others solve their problems. |
|
||||
The xombrero brower seems to no longer be under development.
https://forums.freebsd.org/threads/45232/ See my post and the one under it. It may still work, but doesn't seem to be getting updates (unless whoever maintains it for OpenBSD is doing so, which I didn't check.) |
|
|||
I use an old i386 to follow -current. In the code base leading up to OpenBSD 6.0, Xombrero was working fine. I'm planning on using xombrero in OpenBSD for 6 more months.
Xombrero's developers worked for Conformal and coded several original projects. Sadly, Conformal's web site no longer exists. |
|
|||
Quote:
|
|
||||
Thanks a lot for all the input so far! I mean it.
I've tried three more. 1) otter-browser Let the numbers speak for themselves: 100 packages total, plus 6 new system groups & users respectively. This is one whale of an otter. Truly impressive. Unfortunately it coredumped right away, but being gtk3-based I was already expecting that. So no surprise there. I'm still trying to wrap my head around the fact that a single browser can command the installation of one hundred packages. Now on to the surprises: 2) Firefox Despite a coredump I ran into, Firefox actually runs. Something I didn't really anticipate after having read several discussions about it in the past. Although 'running' may be something of an overstatement, it's more of a crawl. I've dubbed it the Zen-Browser. You need to be in an absolutely serene state of mind to use it on an older system such as mine. Even a click on any of the preference pane items has a response time of at least six seconds or more. You have no idea how long six seconds can actually feel until you've tried it. Afterwards when I read on misc@ that even people with 16gigs of ram can run into problems with the occasional coredump, it made me feel totally bad-ass to operate this beast with my puny 256* megs of memory. It should be noted that Firefox seems to have switched to gtk3 during the run-up to 6.0. This may mean no more zen-browsing on older machines then. [* down to 256 after re-shuffling some components, but I may be able to max out at 768 for nil in a couple of weeks] 3) Surf Surf is extremely unstable. It wouldn't even open daemonforums (immediate coredump). Still, when it works it not only works quite nicely but also pretty fast. I wouldn't say it's as fast as dillo but it didn't seem that far behind. It's almost like a glimpse of what could be possible, if developers were more mindful of limited resource scenarios. My guess is, that the older webkit may be just less ressource hungry(?). I'll have to compare this to Surf2 which supposedly is just Surf with a newer version of webkit under the hood. I still have a few more on my list before I embark on round 2. With all the suggestions so far it'll probably take some time before the next update. Cheers everybody! |
|
|||
Quote:
|
|
||||
Quote:
Firefox is slow on my old machine with Athlon 64 X2 2.6Ghz and 2GB of RAM. It takes forever to start up, there are occasional coredumps and unless I use script blocking, it's unusable on javascript heavy pages where there's lots of ads. I also have an old 1.2GHz netbook with 1GB of RAM and that's also underpowered when it comes to modern browsers - the experience is painful enough to just shutdown and use something else. I've tried surf, netsfurf and midori in the past and it's either lack of javacript support or consistent crashes which have resulted in me giving up. (and it's not just an OpenBSD thing - I have installed various Linuxes and it's not much better.) Mozilla and Chromium based browsers have moved on to take advantage of modern hardware and Firefox in particular will easily use your 256MB of RAM for storing the current browsing session (cache). |
|
|||
Quote:
Full disclosure: the port was made due to this thread!
__________________
Many thanks to the forum regulars who put time and effort into helping others solve their problems. |
|
||||
I'm not sure if "counting dependencies" is a good way to count the "code footprint". Both Chromium and Firefox are huge, and include some components that other "light weight" browsers outsource to a dependency.
__________________
UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things. |
|
|||
Compile time might be a better metric. Last time I tried, NetSurf took five minutes, Firefox took about an hour, and Chrome took about nearly three hours (and then failed to link), with make -j4 on a quad‐core amd64.
__________________
Many thanks to the forum regulars who put time and effort into helping others solve their problems. |
|
||||
Quote:
Quote:
As for netsurf-fb, it's really great! Quick installation, very fast startup, and fairly quick rendering. No comparison with the other version of Netsurf that I tested earlier on 5.9. I wasn't able to log into daemonforums, maybe that doesn't work yet. But I'll need to play around with it a bit more and give it some stress testing. Just wanted to give you my first impressions. A great addition. Most excellent work, backrow! Thank you. |
|
|||
Quote:
In fact, this post was made using netsurf-fb, so can confirm that the forums works just fine (but I already knew it would, since it works fine with the gtk-frontended netsurf). |
|
||||
Quote:
If it works for you I must obviously be doing sth. wrong. Did you perform any special configuration steps, any command line options? |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Security Zero day Java exploit being used in the wild | jggimi | News | 7 | 20th January 2013 07:18 AM |
Security New Adobe Reader zero-day in the wild | J65nko | News | 1 | 8th December 2011 08:22 PM |
daemonforums in Midori | Mr-Biscuit | Off-Topic | 3 | 8th January 2011 10:35 PM |
Midori port | roddierod | OpenBSD Packages and Ports | 18 | 6th January 2011 04:01 PM |
Dev goes 'Wild' with H.264 Firefox | J65nko | News | 0 | 19th May 2010 09:43 PM |