On Tue, 2 Mar 2010 10:28:39 -0800
"J.C. Roberts" <list-jcr@designtools.org> wrote:

quoted text
> On Tue, 2 Mar 2010 10:44:38 +0000 (GMT) trustlevel-two@yahoo.co.uk
> wrote:
>

quoted text
> The short answer is painfully simple; if you're running OpenBSD as your
> desktop/laptop and you have a clue, then run just -current.
>

Your right, I must follow the crowd and appreciate how well the current
packages are kept upto date, It was just a let down after managing to apply
updates for nearly a year to have it break just after my new image was
installed. That was a while back. I've been busy. I've already downloaded a
snapshot for my desktop but it shows how much development goes on. I struggled
to get the same checksums from more than one server.

quoted text
> These days, the -stable branch still exists primarily due to historical
> precedence for people unwilling to update their thinking.

I'm still going to stick to stable for my servers, especially now with
port updates for the more maintainable and server oriented packages like php.
I've read a few times you should buy the cd because theo and close friends do
a level of code audit before release. I imagine with many people running
stable they are also more likely to spot activity due to a trojan and it would
be harder to get one onto any server or easier to spot, however unlikely.

quoted text
>
> 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.

To be honest I totally agree, this was more out of interest about
peoples views on the patches effectiveness to browser vulns and possibly
what was best as a stop gap untill upgrade of current or stable.

quoted text
>
> > 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.

Neither had I, I thought it was an official project but theres nothing
to be found aside from on the miros site. All I found was something
about making it easier to port but I got the feeling it may be
antiquated, of course that might be a good thing (simpler) aside from lacking
ogg theora (if you use it but flash is almost always insecure), but I still
have no idea about mirzilla tapir (weird name).

quoted text
>
> > 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.

Fair enough, no need to know. The motivation was to stop me investigating
miros and save me time because of what theo had disagreed with, expecting I
would also disagree. I wouldn't waste his time, if he thinks it's worth me
knowing he could mail me, but I guess, if it was worth knowing, it would be on
the net already.

quoted text
> 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.
>
>
I'll check it out, nice one

quoted text
> > 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.

I couldn't agree more, you may have noticed I'm using yahoo classic
because I don't want to use javascript and want to make sure my non
aliased email address is not printed on the internet (yahoo seems to only
allow my alias out in webmail?). I've ranted about javascript being used for
no reason on sites a few times. w3c should be more vocal on that note and
dreamweaver set better examples.

I go out of my way to stear clear of adobe air, java, microsoft silverlight.
But unfortunately the host I've found which allows me to install openbsd as a
web server at a price I can afford requires a java client to run the console
and upload the image. Ironic isn't it. The guy running it seems pretty clued
up so I imagine it's coded pretty well, it's just my side I want to think
about. I've hardly ever run java before but I'm sure I'll figure the more
secure settings out. All tips welcome of course

quoted text
>
> 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".
>

Intel, okay, I guess ATI will eventually overtake as they're usually dedicated
cards. Thanks for the insight and I'm sure your right for most sites
especially on slow phones etc.. I did make a site which adapted to the screen
resolution on which I had to change the css layout and z-index of (which was
the right thing to do anyway), because of overlapping images and transparency.
Prior to that I needed a post 180 nvidia driver to make the rendering fast at
high resolutions (1600x1200, analogs best when you have room;-), so the gpu
driver must have some effect, bad or good.

Hopefully mozilla will turn their attention to gecko now their jscript engines
been sped up. I swapped my laptop with my sisters old laptop cos she's at uni
and had a greater need for speed (her only system). Openbsd X wouldn't
autosetup and I couldn't get it to run (I didn't try very! hard), so I
installed kubuntu, turned 3d accel off via xorg.conf to get the gui to display
on the old ati chip and opera is far faster than firefox on that, even just
the interface buttons. I should try it on xfce or something to see if it has
anything to do with kde4 though.

I am beginning to itch getting openbsd running on it now, I'm sure it would
speed up then on fvwm, (it has an old mobile ati radeon chip, if anyone knows
an xorg.conf fix. I'm hoping I've got an xorg.conf that may work when I get
around to trying it, should be soon).

--
KeV