On Tue, 2 Mar 2010 10:44:38 +0000 (GMT) trustlevel-...@yahoo.co.uk wrote: > Hey all > > Please don't dismiss me because what I have been doing is unsupported > untill you've read a little, I do realise you do far too much for too > little as it is and when I make enough money I'll hopefully become a > donator and regular merchandise/cd buyer. > > Whilst the subject of firefox on current is covered and I understand > to a reasonable degree why firefox only has the bugfixes in current > when the tree is open and don't have the time right now to look into > backporting which I imagine will be rather difficult for such a large > port especially in meeting ports standards. I feel the info currently > in the mailing list archives could be more complete to enable me and > others to make more educated decisions. > > I've been running stable and have had the current firefox running > seemingly without problems (may be for months at a time and then > obviously it will break at some point and you upgrade and then it may > be days, weeks or if your lucky months before the build breaks and > dependencies go too far out of sync. > > I imagine the answer is to install stable keep going for as long as > possible untill firefox breaks get a snapshot and test it. Upgrade to > that snapshot when needed and install the latest firefox port. Or > just sync with current every month and make a backup before upgrading. >
The short answer is painfully simple; if you're running OpenBSD as your desktop/laptop and you have a clue, then run just -current. These days, the -stable branch still exists primarily due to historical precedence for people unwilling to update their thinking. Yes, the above is a bit harsh, but it's self-effacing. I spent nearly a decade as a curmudgeon who would only run -stable on all but a single "dev" box, and I did my own back-porting of required ports. I was actually afraid -current was somehow unstable. This was stupid with OpenBSD, but I had been burned too many times by new, unstable code from other UNIX vendors. It took me a decade and a few thousand hours of therapy to finally get past the bad experiences from other vendors. What happened to me with other vendors, has happened to a lot of people, and the hard earned lessons of not running new code are something you don't easily forget. This really is the only reason why the -stable branch still exists; it gives the curmudgeons a place where they feel "safe" from constantly evolving code. There are plenty of people who run -current on servers in "production" environments (however the hell you want to define "production"), but they are the enlightened ones. > ======================================================================== > === > > I do have a few questions however. > > How much security would you lose by using say the opera linux browser > or linux firefox and installing the linux libs keeping an eye on > libc6 vulns and others compared to the openbsd firefox with pro > police patches etc. How often might these patches protect you from > current vulnerabilities in firefox, usually in javascript so I > imagine not often, but then you can just just turn jscript off?. I > currently disable linux support when I don't intend to use it. It's > quite a good feeling, reading the latest vulnerability measures or > stability problems knowing you avoided it through a necessity policy. > ipv6 + pf springs to mind of many. (happens far less on OpenBSD of > course but just using OpenBSD gives that feeling when reading about > Linux :) > Support for running binaries from other systems exists because it can be very useful when you don't have any other choice. Though it was much more of a problem a long time ago, there are still rare situations where running alien binaries can still be useful. In general, it is extremely rare to find the required "Darn Good Reason" (DGR) to enable compatibility with binaries from other systems, and you should avoid it if at all possible. The only viable reason/excuse to turn on binary compatibility is when you cannot find a suitable replacement for a closed source, proprietary application that you absolutely *must* have. Sorry. A web browser doesn't meet the requirement of having a DGR. Although Opera is a nice browser, there is no compelling reason to run an unknown, untrusted and unaudited binary from them. > Does anyone have any info about the Miros mirzilla firetapir port > which is said to build for openbsd and kept upto date??? Searching > shows up nothing but a few Miros pages and it's not installed on > their livecd, which wouldn't boot anyway. Never heard of it. > I also tried to find what > the dispute between Theo and the Miros project leader was but > Couldn't find much. > Why drag it into a public discussion? --If you really must know, ask them directly and privately, but realize it's probably none of your business so you'll probably be ignored. > What browser (perhaps a simple open source one) would you use for > important stuff fullstop or whilst firefox has vulns. I know this > question has been asked before so have there been any new ones come > on the block. Dillo w3m and lynx seemed popular on the lists. I'm > sure I installed a graphical w3m but haven't really tried it yet. > http://www.openbsd.org/faq/faq8.html#Browsers Try things out to find what *you* like. As for new browsers, you might want to check the new xxxterm. http://marc.info/?t=126707287300003&r=1&w=2 I haven't had a chance to look at it yet, but considering the source, it's probably a winner. > What's the most secure way of running java support occassionally > within a browser on openbsd and making sure it is disabled for the > rest of the time. > The most secure way to run java from the web in a browser is to uninstall java completely. Similar is true for javascript, but it's much more difficult to get rid of it. For those who want to regurgitate the typical lies about supposed "security" being provided by "sandboxes" or "virtual machines," you've got your head up your ass. They can be broken. Worse yet, you don't even need to break out of them to do a whole lot of malicious things. There is really only a single rule in computer security; If someone can run their code on your system, then it's not your system. > Does anyone have any tips on getting good rendering speed in browsers > on graphic laden sites. I read on this list that now the ati driver > has been open sourced it is quite decent on openbsd. I'm guessing > that doesn't include older ati graphics chips in old laptops? > > I thinks that's more than enough questions now, Thanks for your time > KeV > The Intel graphics chips have the best support, and some of the ATI chipsets are catching up, but your question is flawed. The "rendering speed" of a browser on a "graphics laden site" has far more to do with page complexity and the browser itself, than it does the graphics chipset of the system. The major parts of the browser chewing up time are the graphical "toolkit" being used, the complexity and completeness of CSS support, and of course, the supposed javascript "engine". --
