Re: OpenBSD speed on desktops

2007-03-20 Thread Tor Houghton
On Mon, Mar 19, 2007 at 03:59:06PM +0100, Karel Kulhavy wrote:
 
 I have also a feeling that deleting huge files or large directories with
 loads of tiny files in subdirectories is slower.
 

I have a different feeling. 

/t
--
Tell me about your mother.



Re: OpenBSD speed on desktops

2007-03-19 Thread Karel Kulhavy
On Sat, Feb 17, 2007 at 10:06:43PM +0100, Joachim Schipper wrote:
 On Sat, Feb 17, 2007 at 12:36:00PM -0500, R. Fumione wrote:
  Hello,
  
  I am using OpenBSD on server since few years now, and I am very happy
  with it's easy maintenance and it's stability. I want to try on
  desktop, and I am having trouble.
  
  Everything is much slower than existing Linux system. For example,
  Firefox takes 3-5 seconds to start on Linux but ~10 seconds on
  OpenBSD on same machine!
  
  I tried compiler optimizations but those didn't help. Any suggestions?
  Please cc replies to me also as I am not on misc. Thanks.
  
  Fumione
  
  (Note: please do not tell me change to lighter window manager. I
  would like to use same environment or stay with Linux. Thanks.)
 
 I believe the standard response to any comparison use Linux if you're
 happy with it. Since you've already received that, here is an attempt
 to do the question a little more justice. (However, it boils down to 'it
 doesn't matter if FF loads a little slower, as long as it runs equally
 fast').
 
 Most modern Linux distributions optimize dynamic library load using
 prelinking; 4.0 and later have a comparable idea implemented
 ('prebind'), but in a way that does not interfere with OpenBSD's
 security features. This is not enabled by default (I'm not sure why not,
 and would be very grateful if anybody would tell me, BTW), but can be
 enabled using `ldconfig -P /usr/bin /usr/sbin /usr/local/bin
 /usr/local/sbin /usr/X11R6/bin'. This should result in a noticeable
 speed increase, especially on programs with lots of loaded libraries -
 and look in /usr/local/mozilla-firefox to see that FF does have 'lots of
 loaded libraries'!
 Of course, it would be a good idea to know why it's not the default
 first. Also note that, if I remember correctly, prebind won't help if
 you use a nonstandard LD_LIBRARY_PATH, as FF does... so the command
 listed before is likely to work for just about every *other* program.
 
 Another aspect is that Linux is much more aggressive in caching data
 from disk; if the amount of data read, the amount of work done in
 between, and the amount of RAM is such that Linux can get most data from
 its memory cache while OpenBSD has to read most of it from disk, Linux
 will be a *lot* faster. Of course, you would only see this effect if you
 started Firefox twice without doing much in between.
 
 Both of those could explain why FF loads slower. If either of those is
 the big culprit, though, FF should run just as fast (slow) as it ever
 did, and since you're not likely to start it that often, I'd be inclined
 to say it isn't that big an issue.
 
 If a comparable slowdown is found in running FF, that would be a
 problem. There are many variables there, of course... a dmesg might be
 helpful, for instance.
 
 Aggressive compiler optimizations are not generally a good idea. The
 developers believe they are an unnecessary source of bugs, and since

I would like to point out here that the idea of optimization is that an
equivalent code that executes faster is produced. Optimizations don't
permit generating code that is not equivalent, unless specifically stated
in the flag description (-ffast-math).

It's therefore not the responsibility of the programmer to check whether the
result of optimization is correct. Therefore it's not the optimizations that
are source of bugs, but bugs in GCC.

CL
 many optimizations are not enabled by default, there is not quite as
 much opportunity to find bugs in them. Plus, no amount of fiddling is
 likely to double speed.
 
 Since you didn't mention what you are using at the moment, I can't very
 well tell you to switch to a lighter window manager, can I? Ion *is*
 nice, though... ;-)
 
   Joachim



Re: OpenBSD speed on desktops

2007-03-19 Thread Claudio Jeker
On Mon, Mar 19, 2007 at 01:48:44PM +0100, Karel Kulhavy wrote:
 On Sat, Feb 17, 2007 at 12:36:00PM -0500, R. Fumione wrote:
  Hello,
  
  I am using OpenBSD on server since few years now, and I am very happy
  with it's easy maintenance and it's stability. I want to try on
  desktop, and I am having trouble.
  
  Everything is much slower than existing Linux system. For example,
  Firefox takes 3-5 seconds to start on Linux but ~10 seconds on
  OpenBSD on same machine!
 
 I have the same problem. The FFS doesn't seem to be as fast as ext2.
 

On the other hand I never lost data on ffs while a crashing linux box
likes to eat up file systems. If you like to get ext2 speed just mount
your filesystems async and hope for the best (that's what linux is doing).

-- 
:wq Claudio



Re: OpenBSD speed on desktops

2007-03-19 Thread Jason Beaudoin
snip


  Everything is much slower than existing Linux system. For example,
  Firefox takes 3-5 seconds to start on Linux but ~10 seconds on
  OpenBSD on same machine!

 I have the same problem. The FFS doesn't seem to be as fast as ext2.


The issue is not filesystem speed, but rather prelinking and the differences
in how libraries are loaded. Trying comparing transfer times for a given set
of (differing) files on both filesystems..


Regards,

~J


-- 
IEEE Student Branch President
Wentworth Institute of Technology
550 Huntington Ave.
Boston, MA. 02115
401.837.8417
[EMAIL PROTECTED]



Re: OpenBSD speed on desktops

2007-03-19 Thread Karel Kulhavy
On Sat, Feb 17, 2007 at 10:23:28PM +0100, Vim Visual wrote:
 Agreed. It's not the lawsuit that makes people use Linux instead of the
 BSD's; it's the holier-than-thou,
 fuck-'em-if-they-dare-question-our-judgement attitude.
 
 Jeff
 
 indeed...
 
 actually, I was curious to see what answers fumione would get
 
 Mine is: I have been using GNU/Linux for years and I have also noticed
 that o'bsd is a _bit_ slower on the desktop, sometimes. But no that
 slower.
 
 In any case, I'd recommend you that you try to think in a different
 way. Don't try to make OpenBSD be like your linux, because it isn't
 (it's much better ;) ) Look for other possibilities.
 
 For instance: Have you tried to go back to mozilla? In my case firefox
 was behaving very buggy and consuming too much cpu. It's supposed to
 be a light-weight version of mozilla but I find that mozilla itself is
 much faster than firefox and doesn't consume almost anything (and the
 fonts are looking better too)

It goes like this for me: I want to google something, start up Firefox, then
realize it will take long. So while Firefox is loading I start Links, type
www.google.com, type the query, read the answer, close Links. Then Firefox pops
up and I just kill it. Seriously.

I can recommend using Links for general browsing and firing up Firefox only
when Javascript or CSS is needed, if you are concerned about Firefox execution
speed. Extra benefit: Links has an image autoscale feature which is perfect for
viewing online pictures. You can also calibrate Links for your monitor gamma,
aspect ratio and LCD optimization, and Links has a fast bilinear rescaler, so
the result are much better pictures than Firefox.

CL
 
 Let us (at least me) know
 
 Cheers,
 
 Pau



Re: OpenBSD speed on desktops

2007-03-19 Thread Timo Schoeler
In epistula a Karel Kulhavy [EMAIL PROTECTED] die horaque Mon, 19
Mar 2007 13:53:00 +0100:

 On Sat, Feb 17, 2007 at 10:06:43PM +0100, Joachim Schipper wrote:
  On Sat, Feb 17, 2007 at 12:36:00PM -0500, R. Fumione wrote:

(...)
 
 I would like to point out here that the idea of optimization is that
 an equivalent code that executes faster is produced. Optimizations
 don't permit generating code that is not equivalent, unless
 specifically stated in the flag description (-ffast-math).
 
 It's therefore not the responsibility of the programmer to check
 whether the result of optimization is correct. Therefore it's not the
 optimizations that are source of bugs, but bugs in GCC.
 
 CL

so, it's not the rain that makes you wet, but the water, right?

(ges)



Re: OpenBSD speed on desktops

2007-03-19 Thread Marco Peereboom
 I have the same problem. The FFS doesn't seem to be as fast as ext2.

Since OpenBSD sucks so hard it might be time to upgrade to something
much more feature rich.  I suggest Linux or OSX or Vista.

Suggesting things is fun!



Re: OpenBSD speed on desktops

2007-03-19 Thread Timo Schoeler

Karel Kulhavy wrote:

On Sat, Feb 17, 2007 at 12:36:00PM -0500, R. Fumione wrote:

Hello,

I am using OpenBSD on server since few years now, and I am very happy
with it's easy maintenance and it's stability. I want to try on
desktop, and I am having trouble.

Everything is much slower than existing Linux system. For example,
Firefox takes 3-5 seconds to start on Linux but ~10 seconds on
OpenBSD on same machine!


I have the same problem. The FFS doesn't seem to be as fast as ext2.

CL


Most interestingly, after I moved from NetBSD to FreeBSD 
(performance-wise) on my Web cluster, I found that FreeBSD, being 
_faster_ than GNU/Linux, was not that much faster.


Being totally pissed off of FreeBSDs and NetBSDs opinion about 'free' 
software and selling themselves as cheap whores to companies (read: 
deploying BLOB) I moved (again) to OpenBSD (on _all_ machines, not just 
on the crucial ones like firewalls etc).


Surprise: Performance is on par. Security is much better. Karma is 
perfect :)




Re: OpenBSD speed on desktops

2007-03-19 Thread Darrin Chandler
On Mon, Mar 19, 2007 at 01:53:00PM +0100, Karel Kulhavy wrote:
 It's therefore not the responsibility of the programmer to check whether the
 result of optimization is correct. Therefore it's not the optimizations that
 are source of bugs, but bugs in GCC.

But if you write a program and the user finds it full of bugs, are they
going to care that you can say that it's GCC's fault? The burden falls
on the developers to make code that works, including working around
problems in the compiler. Sad, but true.

-- 
Darrin Chandler   |  Phoenix BSD Users Group
[EMAIL PROTECTED]  |  http://bsd.phoenix.az.us/
http://www.stilyagin.com/darrin/  |



Re: OpenBSD speed on desktops

2007-03-19 Thread Open Phugu

On 3/19/07, Karel Kulhavy [EMAIL PROTECTED] wrote:

On Sat, Feb 17, 2007 at 12:36:00PM -0500, R. Fumione wrote:
 Hello,

 I am using OpenBSD on server since few years now, and I am very happy
 with it's easy maintenance and it's stability. I want to try on
 desktop, and I am having trouble.

 Everything is much slower than existing Linux system. For example,
 Firefox takes 3-5 seconds to start on Linux but ~10 seconds on
 OpenBSD on same machine!

I have the same problem. The FFS doesn't seem to be as fast as ext2.


Instead of making vague, unprovable statements like that, we would
like to see some solid benchmarks (bonnie, bonnie++), to back this up.
Making such statements helps nobody.



Re: OpenBSD speed on desktops

2007-03-19 Thread RedShift

Claudio Jeker wrote:

On Mon, Mar 19, 2007 at 01:48:44PM +0100, Karel Kulhavy wrote:

On Sat, Feb 17, 2007 at 12:36:00PM -0500, R. Fumione wrote:

Hello,

I am using OpenBSD on server since few years now, and I am very happy
with it's easy maintenance and it's stability. I want to try on
desktop, and I am having trouble.

Everything is much slower than existing Linux system. For example,
Firefox takes 3-5 seconds to start on Linux but ~10 seconds on
OpenBSD on same machine!

I have the same problem. The FFS doesn't seem to be as fast as ext2.



On the other hand I never lost data on ffs while a crashing linux box
likes to eat up file systems. If you like to get ext2 speed just mount
your filesystems async and hope for the best (that's what linux is doing).



That's what transactional filesystems like ext3 and reiserfs are for. I 
can highly recommend reiserfs.


Glenn



Re: OpenBSD speed on desktops

2007-03-19 Thread Artur Grabowski
Karel Kulhavy [EMAIL PROTECTED] writes:

 It's therefore not the responsibility of the programmer to check whether the
 result of optimization is correct. Therefore it's not the optimizations that
 are source of bugs, but bugs in GCC.

Good thing we're not just programmers, but actually developers. It's
our job to make system that works, not just write code.

//art



Re: OpenBSD speed on desktops

2007-03-19 Thread Karel Kulhavy
On Mon, Mar 19, 2007 at 07:23:43AM -0700, Darrin Chandler wrote:
 On Mon, Mar 19, 2007 at 01:53:00PM +0100, Karel Kulhavy wrote:
  It's therefore not the responsibility of the programmer to check whether the
  result of optimization is correct. Therefore it's not the optimizations that
  are source of bugs, but bugs in GCC.
 
 But if you write a program and the user finds it full of bugs, are they
 going to care that you can say that it's GCC's fault? The burden falls

When I write a program then I specify the language - say ISO/IEC 9899:1999. If
the compiler is buggy then it doesn't conform to ISO/IEC 9899:1999 - the
compiled program behaviour breaches the ISO/IEC 9899:1999 spec. Then it's the
user's problem that he compiled with a compiler that doesn't meet requirements
I clearly stated.

CL

 on the developers to make code that works, including working around
 problems in the compiler. Sad, but true.
 
 -- 
 Darrin Chandler   |  Phoenix BSD Users Group
 [EMAIL PROTECTED]  |  http://bsd.phoenix.az.us/
 http://www.stilyagin.com/darrin/  |



Re: OpenBSD speed on desktops

2007-03-19 Thread Karel Kulhavy
On Mon, Mar 19, 2007 at 09:26:56AM -0400, Nick ! wrote:
 On 3/19/07, Karel Kulhavy [EMAIL PROTECTED] wrote:
 On Sat, Feb 17, 2007 at 10:06:43PM +0100, Joachim Schipper wrote:
 
  Aggressive compiler optimizations are not generally a good idea. The
  developers believe they are an unnecessary source of bugs, and since
 
 I would like to point out here that the idea of optimization is that an
 equivalent code that executes faster is produced. Optimizations don't
 permit generating code that is not equivalent, unless specifically stated
 in the flag description (-ffast-math).
 
 It's therefore not the responsibility of the programmer to check whether 
 the
 result of optimization is correct. Therefore it's not the optimizations 
 that
 are source of bugs, but bugs in GCC.
 
 But the practical fact is that GCC has these bugs and so optimizations
 are an unnecessary source of bugs.

But the proper way to handle these bugs is not work around them, but report
them to the GCC developer so they can fix it. Otherwise we'll never get rid
of them.

CL
 
 -Nick



Re: OpenBSD speed on desktops

2007-03-19 Thread Manuel Ravasio
Really?
I have a completely different experience: I never managed to completely loose
a filesystem, except by on OpenBSD...

I've been using slackware linux on reiserfs and xfs for many years now, on my
home PCs and company laptop (so, no real production environment) and I'm
happy with both their speed and reliability. I caused many crashes, mostly by
suddenly turning the PCs off in the middle of data transfer and I never lost
a single file.
Recently I decided to give OpenBSD a try, just to taste something different,
and I'm really enthusiastic about it as firewall/proxy/DNS/DHCP server as
well as desktop environment for my laptop. I really love the solidity and
internal coherence of the system, its ease of management and the general
impression of good, old, solid computing for real men that most current
linux distributions completely lack (that's why I stick to slackware :-) ).

The only shortcomings I found up to now are FFS fragility with respect to
sudden poweroffs (I've already lost root filesystem twice, beyond fsck
recovery capabilities, so I had to reinstall/restore from scratch), and a
general sluggishness of X11 lacking DRI support.

Probably it all depends on my lack of experience, so maybe my boxes are far
from perfectly tuned up; I hope that spending more and more time tampering
with OpenBSD and following this mailing list, I will eventually get
proficient enough to tune up my systems as well as I got to do with linux :-)
.


Thank you all,
byee

Manuel



--- Claudio Jeker [EMAIL PROTECTED] wrote:
 
 On the other hand I never lost data on ffs while a crashing linux box
 likes to eat up file systems. If you like to get ext2 speed just mount
 your filesystems async and hope for the best (that's what linux is doing).
 
 -- 
 :wq Claudio



 

8:00? 8:25? 8:40? Find a flick in no time 
with the Yahoo! Search movie showtime shortcut.
http://tools.search.yahoo.com/shortcuts/#news



Re: OpenBSD speed on desktops

2007-03-19 Thread Nick !

On 3/19/07, Karel Kulhavy [EMAIL PROTECTED] wrote:

I have also a feeling that deleting huge files or large directories with
loads of tiny files in subdirectories is slower.


A feeling?? Entirely subjective readings like this mean nothing and
are at best noise and at worst FUD. Come on, be scientific now. Stop
trolling.

-Nick



Re: OpenBSD speed on desktops

2007-03-19 Thread Marco Peereboom
If you like losing data ext3 and reiserfs work just fine.  I manage to
lose Linux installations pretty often by doing crazy things like
rebooting.

On Mon, Mar 19, 2007 at 03:41:05PM +0100, RedShift wrote:
 Claudio Jeker wrote:
 On Mon, Mar 19, 2007 at 01:48:44PM +0100, Karel Kulhavy wrote:
 On Sat, Feb 17, 2007 at 12:36:00PM -0500, R. Fumione wrote:
 Hello,
 
 I am using OpenBSD on server since few years now, and I am very happy
 with it's easy maintenance and it's stability. I want to try on
 desktop, and I am having trouble.
 
 Everything is much slower than existing Linux system. For example,
 Firefox takes 3-5 seconds to start on Linux but ~10 seconds on
 OpenBSD on same machine!
 I have the same problem. The FFS doesn't seem to be as fast as ext2.
 
 
 On the other hand I never lost data on ffs while a crashing linux box
 likes to eat up file systems. If you like to get ext2 speed just mount
 your filesystems async and hope for the best (that's what linux is doing).
 
 
 That's what transactional filesystems like ext3 and reiserfs are for. I 
 can highly recommend reiserfs.
 
 Glenn



Re: OpenBSD speed on desktops

2007-03-19 Thread Karel Kulhavy
On Mon, Mar 19, 2007 at 07:23:43AM -0700, Darrin Chandler wrote:
 On Mon, Mar 19, 2007 at 01:53:00PM +0100, Karel Kulhavy wrote:
  It's therefore not the responsibility of the programmer to check whether the
  result of optimization is correct. Therefore it's not the optimizations that
  are source of bugs, but bugs in GCC.
 
 But if you write a program and the user finds it full of bugs, are they
 going to care that you can say that it's GCC's fault? The burden falls
 on the developers to make code that works, including working around
 problems in the compiler. Sad, but true.

We can analogically use this argument for ocassional errors in memory, too. If
I write a program and the user finds it crashing all the time, are they going
to care that you can say that their hardware may be unstable?

OpenBSD then should be written with Hamming, Golay, or Reed-Solomon codes in
all the internal structures, to automatically recover from flipped bits in data
structures. Similar protection should be done to the code. The code should be
periodically CRC-ed and the process image snapshotted. If it were revealed the
code is corrupted, a rollback would be done and the process restarted.

CL
 
 -- 
 Darrin Chandler   |  Phoenix BSD Users Group
 [EMAIL PROTECTED]  |  http://bsd.phoenix.az.us/
 http://www.stilyagin.com/darrin/  |



Re: OpenBSD speed on desktops

2007-03-19 Thread Nick !

On 3/19/07, Karel Kulhavy [EMAIL PROTECTED] wrote:

On Mon, Mar 19, 2007 at 09:26:56AM -0400, Nick ! wrote:
 On 3/19/07, Karel Kulhavy [EMAIL PROTECTED] wrote:
 On Sat, Feb 17, 2007 at 10:06:43PM +0100, Joachim Schipper wrote:
 
  Aggressive compiler optimizations are not generally a good idea. The
  developers believe they are an unnecessary source of bugs, and since
 
 It's therefore not the responsibility of the programmer to check whether
 the
 result of optimization is correct. Therefore it's not the optimizations
 that
 are source of bugs, but bugs in GCC.

 But the practical fact is that GCC has these bugs and so optimizations
 are an unnecessary source of bugs.

But the proper way to handle these bugs is not work around them, but report
them to the GCC developer so they can fix it. Otherwise we'll never get rid
of them.


I agree, but in the meantime we have to make do.

-Nick



Re: OpenBSD speed on desktops

2007-03-19 Thread Timo Schoeler
In epistula a Manuel Ravasio [EMAIL PROTECTED] die horaque Mon,
19 Mar 2007 07:47:46 -0700 (PDT):

 Really?
 I have a completely different experience: I never managed to
 completely loose a filesystem, except by on OpenBSD...
 
 I've been using slackware linux on reiserfs and xfs for many years
 now, on my home PCs and company laptop (so, no real production
 environment) and I'm happy with both their speed and reliability. I
 caused many crashes, mostly by suddenly turning the PCs off in the
 middle of data transfer and I never lost a single file.
 Recently I decided to give OpenBSD a try, just to taste something
 different, and I'm really enthusiastic about it as
 firewall/proxy/DNS/DHCP server as well as desktop environment for my
 laptop. I really love the solidity and internal coherence of the
 system, its ease of management and the general impression of good,
 old, solid computing for real men that most current linux
 distributions completely lack (that's why I stick to slackware :-) ).
 
 The only shortcomings I found up to now are FFS fragility with
 respect to sudden poweroffs (I've already lost root filesystem twice,
 beyond fsck recovery capabilities, so I had to reinstall/restore from
 scratch), and a general sluggishness of X11 lacking DRI support.
 
 Probably it all depends on my lack of experience, so maybe my boxes
 are far from perfectly tuned up; I hope that spending more and more
 time tampering with OpenBSD and following this mailing list, I will
 eventually get proficient enough to tune up my systems as well as I
 got to do with linux :-) .
 
 
 Thank you all,
 byee
 
 Manuel

interestingly, i just had an experience at a customer's site i want to
share in this respect:

they use *cough* GNU/Linux *cough*, RHEL. and XFS. XFS is pretty cool.
however, they lost data. but it was not only about 'losing' data, it
was about a hidden data loss. some data was lost, some not. some had
weird ctime, some not. this is surely thanks to the most perfect
implementation of an *opened* FS (here: XFS) by the GNU/Linux guys.
pretty well done. what happened? a server had a backplane crash, an
externally mounted XFS volume was shut down 'unclean'. although it was
not that big (1TByte), the desaster happened.

in more than ten years of using IRIX (and thusly, XFS) i never lost one
single sucking file.

:)



Re: OpenBSD speed on desktops

2007-03-19 Thread Artur Grabowski
Karel Kulhavy [EMAIL PROTECTED] writes:

 On Mon, Mar 19, 2007 at 07:23:43AM -0700, Darrin Chandler wrote:
  On Mon, Mar 19, 2007 at 01:53:00PM +0100, Karel Kulhavy wrote:
   It's therefore not the responsibility of the programmer to check whether 
   the
   result of optimization is correct. Therefore it's not the optimizations 
   that
   are source of bugs, but bugs in GCC.
  
  But if you write a program and the user finds it full of bugs, are they
  going to care that you can say that it's GCC's fault? The burden falls
 
 When I write a program then I specify the language - say ISO/IEC 9899:1999. If
 the compiler is buggy then it doesn't conform to ISO/IEC 9899:1999 - the
 compiled program behaviour breaches the ISO/IEC 9899:1999 spec. Then it's the
 user's problem that he compiled with a compiler that doesn't meet requirements
 I clearly stated.

Can you please try to loudly say: I think, therefore I am?

//art



Re: OpenBSD speed on desktops

2007-03-19 Thread RedShift

Marco Peereboom wrote:

If you like losing data ext3 and reiserfs work just fine.  I manage to
lose Linux installations pretty often by doing crazy things like
rebooting.

On Mon, Mar 19, 2007 at 03:41:05PM +0100, RedShift wrote:

Claudio Jeker wrote:

On Mon, Mar 19, 2007 at 01:48:44PM +0100, Karel Kulhavy wrote:

On Sat, Feb 17, 2007 at 12:36:00PM -0500, R. Fumione wrote:

Hello,

I am using OpenBSD on server since few years now, and I am very happy
with it's easy maintenance and it's stability. I want to try on
desktop, and I am having trouble.

Everything is much slower than existing Linux system. For example,
Firefox takes 3-5 seconds to start on Linux but ~10 seconds on
OpenBSD on same machine!

I have the same problem. The FFS doesn't seem to be as fast as ext2.


On the other hand I never lost data on ffs while a crashing linux box
likes to eat up file systems. If you like to get ext2 speed just mount
your filesystems async and hope for the best (that's what linux is doing).

That's what transactional filesystems like ext3 and reiserfs are for. I 
can highly recommend reiserfs.


Glenn





Do you have some evidence to back up your pretty bold statement?



Re: OpenBSD speed on desktops

2007-03-19 Thread Jason George
  It's therefore not the responsibility of the programmer to check whether 
  the
  result of optimization is correct. Therefore it's not the optimizations 
  that
  are source of bugs, but bugs in GCC.
 
 But if you write a program and the user finds it full of bugs, are they
 going to care that you can say that it's GCC's fault? The burden falls

When I write a program then I specify the language - say ISO/IEC 9899:1999. If
the compiler is buggy then it doesn't conform to ISO/IEC 9899:1999 - the
compiled program behaviour breaches the ISO/IEC 9899:1999 spec. Then it's the
user's problem that he compiled with a compiler that doesn't meet requirements
I clearly stated.

I remember back in university there were computing assignments where 50% of 
the marks were whether or not the program compiled or not.  There were lots of 
student submissions that came in syntactically-correct, compiled but did 
not solve the actual problem that was the purpose of the assignment.  50% 
guaranteed rate of return on basically no effort?  That's what the economics 
students might call an optimization, especially so if you knew that the prof 
or TA wasn't going to look at the source.  Make the program core out 
immediately after execution and they'd optimize their own time, give you the 
50% and move on.

So following in that line of thought, what about bugs that are procedural in 
nature but are otherwise syntactically-correct?  Just because code compiles 
doesn't mean that it isn't wrong because of the methods used to come up with 
it...

Since I answered my own rhetorical question, no one else needs to respond.

Man, the signal-to-noise ratio of this list sure is bad lately



Re: OpenBSD speed on desktops

2007-03-19 Thread Timo Schoeler
In epistula a Karel Kulhavy [EMAIL PROTECTED] die horaque Mon, 19
Mar 2007 15:59:06 +0100:

 On Mon, Mar 19, 2007 at 09:15:16AM -0400, Jason Beaudoin wrote:
  snip
  
  
   Everything is much slower than existing Linux system. For
   example, Firefox takes 3-5 seconds to start on Linux but ~10
   seconds on OpenBSD on same machine!
  
  I have the same problem. The FFS doesn't seem to be as fast as
  ext2.
  
  
  The issue is not filesystem speed, but rather prelinking and the
  differences in how libraries are loaded. Trying comparing transfer
  times for a given set of (differing) files on both filesystems..
 
 I have also a feeling that deleting huge files or large directories
 with loads of tiny files in subdirectories is slower.
 
 CL

Y slower than JFS2, XFS, ext3 or X than ReiserFS 4, HPFS or what?
'feeling'? huh? this is about zeroes and ones, or what happened to IT?



Re: OpenBSD speed on desktops

2007-03-19 Thread Timo Schoeler
In epistula a Karel Kulhavy [EMAIL PROTECTED] die horaque Mon, 19
Mar 2007 16:00:49 +0100:

 On Mon, Mar 19, 2007 at 09:26:56AM -0400, Nick ! wrote:
  On 3/19/07, Karel Kulhavy [EMAIL PROTECTED] wrote:
  On Sat, Feb 17, 2007 at 10:06:43PM +0100, Joachim Schipper wrote:
  
   Aggressive compiler optimizations are not generally a good idea.
   The developers believe they are an unnecessary source of bugs,
   and since
  
  I would like to point out here that the idea of optimization is
  that an equivalent code that executes faster is produced.
  Optimizations don't permit generating code that is not equivalent,
  unless specifically stated in the flag description (-ffast-math).
  
  It's therefore not the responsibility of the programmer to check
  whether the
  result of optimization is correct. Therefore it's not the
  optimizations that
  are source of bugs, but bugs in GCC.
  
  But the practical fact is that GCC has these bugs and so
  optimizations are an unnecessary source of bugs.
 
 But the proper way to handle these bugs is not work around them, but
 report them to the GCC developer so they can fix it. Otherwise we'll
 never get rid of them.
 
 CL

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30785

no comment required, as 'it rains outside -- you get wet'. ;D



Re: OpenBSD speed on desktops

2007-03-19 Thread Darrin Chandler
On Mon, Mar 19, 2007 at 04:19:11PM +0100, Karel Kulhavy wrote:
 We can analogically use this argument for ocassional errors in memory, too. If

We can, but we won't.

Yes, the GCC bugs should be fixed. Yes, it's important to communicate
with the GCC people that -O2 breaks things sometimes.

This is a separate issue from producing code that works right in the
real world, which is where MY code has to run. If there are memory
errors nothing else will run, either. If I report an error, do I sit
around and not write code until it's fixed? Or do I continue to write
broken code and tell the users it's not my fault?

You're being stupid arguing things like that. How many more people are
going to have to tell you?

-- 
Darrin Chandler   |  Phoenix BSD Users Group
[EMAIL PROTECTED]  |  http://bsd.phoenix.az.us/
http://www.stilyagin.com/darrin/  |



Re: OpenBSD speed on desktops

2007-03-19 Thread Nick !

On 3/19/07, Karel Kulhavy [EMAIL PROTECTED] wrote:

On Mon, Mar 19, 2007 at 07:23:43AM -0700, Darrin Chandler wrote:



 But if you write a program and the user finds it full of bugs, are they
 going to care that you can say that it's GCC's fault? The burden falls
 on the developers to make code that works, including working around
 problems in the compiler. Sad, but true.

We can analogically use this argument for ocassional errors in memory, too. If
I write a program and the user finds it crashing all the time, are they going
to care that you can say that their hardware may be unstable?


Yeah but see, you can try it on different hardware and show that it
works. GCC is the only option for compiling we've got, so your analogy
fails.


OpenBSD then should be written with Hamming, Golay, or Reed-Solomon codes in
all the internal structures, to automatically recover from flipped bits in data
structures. Similar protection should be done to the code. The code should be
periodically CRC-ed and the process image snapshotted. If it were revealed the
code is corrupted, a rollback would be done and the process restarted.


What do you want?? You must be being sarcastic in some of these posts
but I can't tell which.

-Nick



Re: OpenBSD speed on desktops

2007-03-19 Thread Marco Peereboom
Yes but since these are production machines in a lab that requires
clearance I can't share.  We keep backups around for all these machines
since every now and then we lose one for no good reason.  In contrast
the windows  and openbsd machines we have deployed do not share this
behavior.

You are the one making bold statements based on a non representative
sample.

production server != home computing != desktop

On Mon, Mar 19, 2007 at 05:31:11PM +0100, RedShift wrote:
 Marco Peereboom wrote:
 If you like losing data ext3 and reiserfs work just fine.  I manage to
 lose Linux installations pretty often by doing crazy things like
 rebooting.
 
 On Mon, Mar 19, 2007 at 03:41:05PM +0100, RedShift wrote:
 Claudio Jeker wrote:
 On Mon, Mar 19, 2007 at 01:48:44PM +0100, Karel Kulhavy wrote:
 On Sat, Feb 17, 2007 at 12:36:00PM -0500, R. Fumione wrote:
 Hello,
 
 I am using OpenBSD on server since few years now, and I am very happy
 with it's easy maintenance and it's stability. I want to try on
 desktop, and I am having trouble.
 
 Everything is much slower than existing Linux system. For example,
 Firefox takes 3-5 seconds to start on Linux but ~10 seconds on
 OpenBSD on same machine!
 I have the same problem. The FFS doesn't seem to be as fast as ext2.
 
 On the other hand I never lost data on ffs while a crashing linux box
 likes to eat up file systems. If you like to get ext2 speed just mount
 your filesystems async and hope for the best (that's what linux is 
 doing).
 
 That's what transactional filesystems like ext3 and reiserfs are for. I 
 can highly recommend reiserfs.
 
 Glenn
 
 
 
 Do you have some evidence to back up your pretty bold statement?



Re: OpenBSD speed on desktops

2007-03-19 Thread RW
On Mon, 19 Mar 2007 16:26:12 -0500, Marco Peereboom wrote:

Yes but since these are production machines in a lab that requires
clearance I can't share.  We keep backups around for all these machines
since every now and then we lose one for no good reason.  In contrast
the windows  and openbsd machines we have deployed do not share this
behavior.

You are the one making bold statements based on a non representative
sample.

production server != home computing != desktop

On Mon, Mar 19, 2007 at 05:31:11PM +0100, RedShift wrote:
 Marco Peereboom wrote:
 If you like losing data ext3 and reiserfs work just fine.  I manage to
 lose Linux installations pretty often by doing crazy things like
 rebooting.
 
snip rest of long thread we have all read

Here is a quote from Theodore Tso (http://thunk.org/tytso/ for bio) a
few months back in kerneltrap:
quote
The fact that reiserfs uses a single B-tree to store all of its data
means that very entertaining things can happen if you lose a sector
containing a high-level node in the tree.  It's even more entertaining
if you have image files (like initrd files) in reiserfs format stored
in reiserfs, and you run the recovery program on the filesystem.

Yes, I know that reiserfs4 is alleged to fix this problem, but as far
as I know it is still using a single unitary tree, with all of the
pitfalls that this entails.

Now, that being said, that by itself is not a reason not to decide not
to include reseirfs4 into the mainline sources.  (I might privately
get amused when system administrators use reiserfs and then report
massive data loss, but that's my own failure of chairty; I'm working
on it.)  For the technical reasons why resierfs4 hasn't been
integrated, please see the mailing list archives.
/quote

Enough said? I think that backs up Marco pretty well, given that Tso is
a Linux kernel dev since '91.

I used to be an IBM Linux instructor until a few years ago and we
always warned about Reiser FS being too bleedin' edgy. Seems it hasn't
matured yet.

From the land down under: Australia.
Do we look umop apisdn from up over?



Re: OpenBSD speed on desktops

2007-02-18 Thread Nick Nauwelaerts
On Sat, 17 Feb 2007 22:06:43 +0100
Joachim Schipper [EMAIL PROTECTED] wrote:

Since prebind has already been explained in detail, I want to add that
does indeed work, but if you use it on your ports it will invalidate
all of the hashes used by pkg_add  (which is most likely one of the
issues theo mentioned). With prebinding my firefox starts in 4 seconds
or so, half of what it needs without prebinding.

 Another aspect is that Linux is much more aggressive in caching data
 from disk; if the amount of data read, the amount of work done in
 between, and the amount of RAM is such that Linux can get most data
 from its memory cache while OpenBSD has to read most of it from disk,
 Linux will be a *lot* faster. Of course, you would only see this
 effect if you started Firefox twice without doing much in between.

We're all hoping for UBC to come back in a working form, but hopefully
some are doing the actual work :)
If your box has memory to spare it will infact load firefox a lot
faster the second time, if it still has the libraries cached in memory.
A fixed size of memory is reserved for filesystem caching. What linux
does (and UBC) is remove this fixed limit and let you use all your
memory for buffer cache when it's not mapped to another application.

 Both of those could explain why FF loads slower. If either of those is
 the big culprit, though, FF should run just as fast (slow) as it ever
 did, and since you're not likely to start it that often, I'd be
 inclined to say it isn't that big an issue.

On last thing that might add to openbsd's startup overhead is the
aggresive security stance. I don't know if library randomization has
anything to do with it, but w^x  propolice have been stated to give a
5% to 10% performance impact in certain cases. I've noticed this mostly
in applications that map  unmap a lot of memory.

I'm using openbsd on my systems, desktops  laptops included, since
release 2.7. It might not be equal to a current linux kernel
performance wise, but it's not lagging that much behind. I'll take the
cleanness, easy of use  stability any day over a 10% performance
difference. And that's not even going into the free code debate, it's
hard to get more free than openbsd.

// nick



Re: OpenBSD speed on desktops

2007-02-18 Thread Jacob Yocom-Piatt
Joachim Schipper wrote:

 Since you didn't mention what you are using at the moment, I can't very
 well tell you to switch to a lighter window manager, can I? Ion *is*
 nice, though... ;-)

   

ion whips a giraffe's ass with a belt from a balcony [0].

[0] wesley willis ( http://en.wikipedia.org/wiki/Wesley_Willis )

cheers,
jake

   Joachim



Re: OpenBSD speed on desktops

2007-02-18 Thread Theo de Raadt
 On last thing that might add to openbsd's startup overhead is the
 aggresive security stance. I don't know if library randomization has
 anything to do with it, but w^x  propolice have been stated to give a
 5% to 10% performance impact in certain cases. I've noticed this mostly
 in applications that map  unmap a lot of memory.

Oh really, it has been stated.  By who?  Overall, I doubt that all
of our security technologies add more than about 2% of a performance
hit.  Even a 'make build' on most architectures did not add that.  I
think you need to go back and read my slides again.  Spreading lies
about 5-10% performance hits is just not kind to our efforts.



Re: OpenBSD speed on desktops

2007-02-18 Thread Nick Nauwelaerts
On Sun, 18 Feb 2007 10:03:37 -0700
Theo de Raadt [EMAIL PROTECTED] wrote:

 Oh really, it has been stated.  By who?  Overall, I doubt that all
 of our security technologies add more than about 2% of a performance
 hit.  Even a 'make build' on most architectures did not add that.  I
 think you need to go back and read my slides again.  Spreading lies
 about 5-10% performance hits is just not kind to our efforts.

I've reread the slides again. I stand corrected when it comes to w^x 
propolice, but I'm still not in the clear when it comes to randomized
malloc  mmap. The slides from bsdcan 2004 state: still failry
expensive, the slides from opencon 2005 no longer mention anything
about performance.

// nick



Re: OpenBSD speed on desktops

2007-02-18 Thread Jon Drews

On 2/17/07, R. Fumione [EMAIL PROTECTED] wrote:

Hello,

I am using OpenBSD on server since few years now, and I am very happy
with it's easy maintenance and it's stability. I want to try on
desktop, and I am having trouble.

Everything is much slower than existing Linux system. For example,
Firefox takes 3-5 seconds to start on Linux but ~10 seconds on
OpenBSD on same machine!


Hi:

 Slowdowns for large applications for Firefox and Gimp can
beaccompanied by the following warning:

Gdk-WARNING**: shmget failed: error 28 (no space left on device)




This can fixed by setting
sysctl kern.shminfo.shmseg=128
sysctl kern.shminfo.shmall=32768

In /etc/sysctl.conf

See:
Re: dillo - Gdk-ERROR ?
http://monkey.org/openbsd/archive/ports/0309/msg00164.html

Another cause of the slowdowns mayy be that /etc/login.conf class
default does not not allow enough files to be open at the same time.

in /etc/login.conf change:

   :openfiles-cur=64:\
to
   :openfiles-cur=256:\

I have used OpenBSD as a desktop for several years and the slowdowns
are not caused by a defect in the OS. In fact I use 4.0 on an ancient
Pentium I with 96 MB of ram and it's load speed is satisfactory.

--
Kind regards,
Jonathan



Re: OpenBSD speed on desktops

2007-02-18 Thread Theo de Raadt
  Oh really, it has been stated.  By who?  Overall, I doubt that all
  of our security technologies add more than about 2% of a performance
  hit.  Even a 'make build' on most architectures did not add that.  I
  think you need to go back and read my slides again.  Spreading lies
  about 5-10% performance hits is just not kind to our efforts.
 
 I've reread the slides again. I stand corrected when it comes to w^x 
 propolice, but I'm still not in the clear when it comes to randomized
 malloc  mmap. The slides from bsdcan 2004 state: still failry
 expensive, the slides from opencon 2005 no longer mention anything
 about performance.

Well, we never measured it again.  Because we didn't feel any slowdown
or feel any effect.  Otto did speed something up a few weeks ago, but
these are totally minor effects, honestly.

But since we didn't bother measuring it, we should probably all assume
a 10% slowdown.  That's easier.  It explains everything, including
spring coming earlier every year.

In the future, if you don't measure it yourself, please just withhold
comment.



Re: OpenBSD speed on desktops

2007-02-18 Thread Travers Buda
* Travers Buda [EMAIL PROTECTED] [2007-02-18 14:42:34]:

 * Jon Drews [EMAIL PROTECTED] [2007-02-18 11:17:08]:
 
  On 2/17/07, R. Fumione [EMAIL PROTECTED] wrote:
  Hello,
  
  I am using OpenBSD on server since few years now, and I am very happy
  with it's easy maintenance and it's stability. I want to try on
  desktop, and I am having trouble.
  
  Everything is much slower than existing Linux system. For example,
  Firefox takes 3-5 seconds to start on Linux but ~10 seconds on
  OpenBSD on same machine!
  
 
 So?  For all practicality's sake, you're only starting firefox a
 few times a day (in my normal usage.) Basically, once you start
 getting around to about 10 seconds for a massive program to start
 up, you're really not going to see any more efficiency in your work
 by an increased speed-up.
 
 IMHO, more speed than today's modern sorts of computers (hammer,
 core) is really not going to improve the user experience.  Likewise,
 a slight speed-up in the OS is really not going to do much for you.
 
 But, after all, you are getting something out of that minute launch
 time disparity.  The return is much greater than the cost.
 
 By the way...  I'd imagine the slowness attributed to OpenBSD in
 this case actually lies with this: 
 $ grep Os /usr/ports/www/mozilla-firefox/Makefile
 $ --enable-optimize=-Os 
 And and thank god for it. I remember how
 firefox totally hosed my memory on a bunch of linux systems with -O2.  It
 didn't matter if the box had 256 or a gig of ram, somehow firefox
 managed to misuse all of it and played havoc with the swap--other
 running applications suffered. All for 5 seconds faster startup.
 
 -- 
 Travers Buda

-- 
Travers Buda



Re: OpenBSD speed on desktops

2007-02-17 Thread Jeff Quast

On 2/17/07, R. Fumione [EMAIL PROTECTED] wrote:

Hello,

I am using OpenBSD on server since few years now, and I am very happy
with it's easy maintenance and it's stability. I want to try on
desktop, and I am having trouble.

Everything is much slower than existing Linux system. For example,
Firefox takes 3-5 seconds to start on Linux but ~10 seconds on
OpenBSD on same machine!

I tried compiler optimizations but those didn't help. Any suggestions?
Please cc replies to me also as I am not on misc. Thanks.

Fumione

(Note: please do not tell me change to lighter window manager. I
would like to use same environment or stay with Linux. Thanks.)




You can just stay with linux. Really, we won't mind.

Take care,
jdq



Re: OpenBSD speed on desktops

2007-02-17 Thread Jeff Rollin
On 17/02/07, Jeff Quast [EMAIL PROTECTED] wrote:

 On 2/17/07, Jeff Rollin [EMAIL PROTECTED] wrote:
 
 
 
  On 17/02/07, Jeff Quast [EMAIL PROTECTED] wrote:
   On 2/17/07, R. Fumione [EMAIL PROTECTED] wrote:
Hello,
   
I am using OpenBSD on server since few years now, and I am very
 happy
with it's easy maintenance and it's stability. I want to try on
desktop, and I am having trouble.
   
Everything is much slower than existing Linux system. For example,
Firefox takes 3-5 seconds to start on Linux but ~10 seconds on
OpenBSD on same machine!
   
I tried compiler optimizations but those didn't help. Any
 suggestions?
Please cc replies to me also as I am not on misc. Thanks.
   
Fumione
   
(Note: please do not tell me change to lighter window manager. I
would like to use same environment or stay with Linux. Thanks.)
   
   
  
   You can just stay with linux. Really, we won't mind.
 
  Why not try optimizing OBSD for desktop use?
 
  Jeff


 I am porting x86-linux games to work on more architectures and more
 operating systems:
 http://www.flickr.com/photos/jquast/335431160/in/set-72157594443198409/

 what are you doing?

 this person clearly didn't care to take the time(1) to back his
 opinion, or provide any sort of information that we could help him on.
 He just wanted to complain, and threaten us that he'll move to linux
 unless we help him find a mysterious magical fine-tuning knob that
 will make his firefox load faster?


Strange, you had the time to explain that to me,  but not to him?

For all we know he's no longer using his accellerated binary nvidia driver.

 I havn't got the fucking time. fuck him, let him use linux.


Agreed. It's not the lawsuit that makes people use Linux instead of the
BSD's; it's the holier-than-thou,
fuck-'em-if-they-dare-question-our-judgement attitude.

Jeff



Re: OpenBSD speed on desktops

2007-02-17 Thread Vim Visual

Agreed. It's not the lawsuit that makes people use Linux instead of the
BSD's; it's the holier-than-thou,
fuck-'em-if-they-dare-question-our-judgement attitude.

Jeff


indeed...

actually, I was curious to see what answers fumione would get

Mine is: I have been using GNU/Linux for years and I have also noticed
that o'bsd is a _bit_ slower on the desktop, sometimes. But no that
slower.

In any case, I'd recommend you that you try to think in a different
way. Don't try to make OpenBSD be like your linux, because it isn't
(it's much better ;) ) Look for other possibilities.

For instance: Have you tried to go back to mozilla? In my case firefox
was behaving very buggy and consuming too much cpu. It's supposed to
be a light-weight version of mozilla but I find that mozilla itself is
much faster than firefox and doesn't consume almost anything (and the
fonts are looking better too)

Let us (at least me) know

Cheers,

Pau



Re: OpenBSD speed on desktops

2007-02-17 Thread Jeff Rollin
On 17/02/07, Jeff Quast [EMAIL PROTECTED] wrote:

 On 2/17/07, Jeff Rollin [EMAIL PROTECTED] wrote:
 
 
 
  On 17/02/07, Jeff Quast [EMAIL PROTECTED] wrote:
   On 2/17/07, Jeff Rollin [EMAIL PROTECTED] wrote:
   
   
   
On 17/02/07, Jeff Quast [EMAIL PROTECTED]  wrote:
 On 2/17/07, R. Fumione [EMAIL PROTECTED] wrote:
  Hello,
 
  I am using OpenBSD on server since few years now, and I am very
  happy
  with it's easy maintenance and it's stability. I want to try on
  desktop, and I am having trouble.
 
  Everything is much slower than existing Linux system. For
 example,
  Firefox takes 3-5 seconds to start on Linux but ~10 seconds on
  OpenBSD on same machine!
 
  I tried compiler optimizations but those didn't help. Any
  suggestions?
  Please cc replies to me also as I am not on misc. Thanks.
 
  Fumione
 
  (Note: please do not tell me change to lighter window manager. I
  would like to use same environment or stay with Linux. Thanks.)
 
 

 You can just stay with linux. Really, we won't mind.
   
Why not try optimizing OBSD for desktop use?
   
Jeff
  
  
   I am porting x86-linux games to work on more architectures and more
   operating systems:
  
  http://www.flickr.com/photos/jquast/335431160/in/set-72157594443198409/
  
   what are you doing?
  
   this person clearly didn't care to take the time(1) to back his
   opinion, or provide any sort of information that we could help him on.
   He just wanted to complain, and threaten us that he'll move to linux
   unless we help him find a mysterious magical fine-tuning knob that
   will make his firefox load faster?
 
  Strange, you had the time to explain that to me,  but not to him?
 
   For all we know he's no longer using his accellerated binary nvidia
  driver.
  
   I havn't got the fucking time. fuck him, let him use linux.
  
 
  Agreed. It's not the lawsuit that makes people use Linux instead of the
  BSD's; it's the holier-than-thou,
  fuck-'em-if-they-dare-question-our-judgement attitude.

 This sentance doesn't make any sense. What lawsuits? question my
 judgement? Who questioned my judgement?

  Jeff
 


Is it  or is it not the case that some people feel the ATT vs USL lawsuit is
what scares people off BSD? And as to questioning your judgement, why
couldn't you give the user who started this thread the information you gave
me?

Why bother writing good documentation when we can just complain about
 our experiences and help each other out instead? You are more than
 welcome to hold that user's hand.

 I won't stop you.


What's stopping YOU? And even if something is stopping you, why do you feel
it necessary or wise to tell that user to use Linux instead of working to
improve OBSD and/or help him with his problem?

Jeff



Re: OpenBSD speed on desktops

2007-02-17 Thread Jeff Rollin
On 17/02/07, Joachim Schipper [EMAIL PROTECTED] wrote:

 On Sat, Feb 17, 2007 at 12:36:00PM -0500, R. Fumione wrote:
  Hello,
 
  I am using OpenBSD on server since few years now, and I am very happy
  with it's easy maintenance and it's stability. I want to try on
  desktop, and I am having trouble.
 
  Everything is much slower than existing Linux system. For example,
  Firefox takes 3-5 seconds to start on Linux but ~10 seconds on
  OpenBSD on same machine!
 
  I tried compiler optimizations but those didn't help. Any suggestions?
  Please cc replies to me also as I am not on misc. Thanks.
 
  Fumione
 
  (Note: please do not tell me change to lighter window manager. I
  would like to use same environment or stay with Linux. Thanks.)

 I believe the standard response to any comparison use Linux if you're
 happy with it. Since you've already received that, here is an attempt
 to do the question a little more justice. (However, it boils down to 'it
 doesn't matter if FF loads a little slower, as long as it runs equally
 fast').

 Most modern Linux distributions optimize dynamic library load using
 prelinking; 4.0 and later have a comparable idea implemented
 ('prebind'), but in a way that does not interfere with OpenBSD's
 security features. This is not enabled by default (I'm not sure why not,
 and would be very grateful if anybody would tell me, BTW), but can be
 enabled using `ldconfig -P /usr/bin /usr/sbin /usr/local/bin
 /usr/local/sbin /usr/X11R6/bin'. This should result in a noticeable
 speed increase, especially on programs with lots of loaded libraries -
 and look in /usr/local/mozilla-firefox to see that FF does have 'lots of
 loaded libraries'!
 Of course, it would be a good idea to know why it's not the default
 first. Also note that, if I remember correctly, prebind won't help if
 you use a nonstandard LD_LIBRARY_PATH, as FF does... so the command
 listed before is likely to work for just about every *other* program.

 Another aspect is that Linux is much more aggressive in caching data
 from disk; if the amount of data read, the amount of work done in
 between, and the amount of RAM is such that Linux can get most data from
 its memory cache while OpenBSD has to read most of it from disk, Linux
 will be a *lot* faster. Of course, you would only see this effect if you
 started Firefox twice without doing much in between.

 Both of those could explain why FF loads slower. If either of those is
 the big culprit, though, FF should run just as fast (slow) as it ever
 did, and since you're not likely to start it that often, I'd be inclined
 to say it isn't that big an issue.

 If a comparable slowdown is found in running FF, that would be a
 problem. There are many variables there, of course... a dmesg might be
 helpful, for instance.

 Aggressive compiler optimizations are not generally a good idea. The
 developers believe they are an unnecessary source of bugs, and since
 many optimizations are not enabled by default, there is not quite as
 much opportunity to find bugs in them. Plus, no amount of fiddling is
 likely to double speed.

 Since you didn't mention what you are using at the moment, I can't very
 well tell you to switch to a lighter window manager, can I? Ion *is*
 nice, though... ;-)

 Joachim



Now that's what I call a helpful answer

Jeff



Re: OpenBSD speed on desktops

2007-02-17 Thread Greg Thomas

On 2/17/07, Jeff Rollin [EMAIL PROTECTED] wrote:



What's stopping YOU? And even if something is stopping you, why do you feel
it necessary or wise to tell that user to use Linux instead of working to
improve OBSD and/or help him with his problem?



Because in general it's a waste of time to help a user to get his
OpenBSD install to work just like his Linux install, performance-wise,
looks-wise, functionality-wise, etc.  If the guy had given any
concrete info beyond oooh, Firefox is slow to start up on OpenBSD he
would probably receive some good suggestions on figuring out what the
problem is, if any.

Personally my attitude is he can stick with Linux, not because he's
looking for a similar experience on OpenBSD but because he doesn't
seem to be able to formulate a reasonable request for help.

Greg



Re: OpenBSD speed on desktops

2007-02-17 Thread Theo de Raadt
 Most modern Linux distributions optimize dynamic library load using
 prelinking; 4.0 and later have a comparable idea implemented
 ('prebind'), but in a way that does not interfere with OpenBSD's
 security features. This is not enabled by default (I'm not sure why not,
 and would be very grateful if anybody would tell me, BTW),

The pkg tree is not yet ready to do the right thing for this, heck,
even the base is not fully prepared for this to be on by default.
Prebind appends an information block to the end of libraries, and
there are some more details which need to be considered, and handled.

Furthermore, anytime you did a 'make build' of your system, the prebind
information changes in that information block, and when any of it is
invalid, it ignored, and you are right back in the un-optimized mode.
That's safe, and fine, but there are issues.

Like everything else in OpenBSD, we make it available early, and then
we turn it on when we are confident.  You don't even need to know the
above details -- just trust we are making the right decisions.



Re: OpenBSD speed on desktops

2007-02-17 Thread Greg Thomas

On 2/17/07, Jeff Rollin [EMAIL PROTECTED] wrote:



On 17/02/07, Greg Thomas [EMAIL PROTECTED] wrote:
 On 2/17/07, Jeff Rollin [EMAIL PROTECTED] wrote:
 
 
  What's stopping YOU? And even if something is stopping you, why do you
feel
  it necessary or wise to tell that user to use Linux instead of working
to
  improve OBSD and/or help him with his problem?
 

 Because in general it's a waste of time to help a user to get his
 OpenBSD install to work just like his Linux install, performance-wise,
 looks-wise, functionality-wise, etc.  If the guy had given any
 concrete info beyond oooh, Firefox is slow to start up on OpenBSD he
 would probably receive some good suggestions on figuring out what the
 problem is, if any.

 Personally my attitude is he can stick with Linux, not because he's
 looking for a similar experience on OpenBSD but because he doesn't
 seem to be able to formulate a reasonable request for help.

 Greg



None of you seem the slightest bit interested in telling him HOW to
formulate a reasonable request for help.



Damn, you're right.  I forgot how hard it is to see this:

http://www.openbsd.org/mail.html

when looking for the mailing lists.

But, here, I'll cc him with this message since it appears he didn't
read the above:

Do your homework before you post
   If you have an installation question, make sure that you have read
the relevant documents such as the INSTALL.* text files in the FTP
installation directories, the FAQ and the relevant man pages (start
with afterboot(8)), and check the mailing list archives. We want to
help, but we wouldn't want to deprive you of a valuable learning
experience, and no one wants to see the same question on the lists for
the fifth time in a month.

Include important information
   Don't waste everyone's time with a hopelessly incomplete question.
No one other than you has the information needed to resolve your
problem, it is better to provide more information than needed than one
detail too little. Any question should include at least the version of
OpenBSD (i.e., 3.2-stable, 3.3-current as of July 20, 2003). Any
hardware related questions should mention the platform (i.e., sparc,
alpha, etc.), and provide a full dmesg(8). Hardware model numbers,
unfortunately, don't indicate much about the actual content of a
particular machine or accessory, and are useless to anyone who doesn't
have that exact machine sitting where they can easily recognize it.
The dmesg(8) tells us exactly what is IN your machine, not what
stickers are on the outside.

HTH,
Greg



Re: OpenBSD speed on desktops

2007-02-17 Thread Joachim Schipper
On Sat, Feb 17, 2007 at 05:09:26PM -0700, Theo de Raadt wrote:
  Most modern Linux distributions optimize dynamic library load using
  prelinking; 4.0 and later have a comparable idea implemented
  ('prebind'), but in a way that does not interfere with OpenBSD's
  security features. This is not enabled by default (I'm not sure why not,
  and would be very grateful if anybody would tell me, BTW),
 
 The pkg tree is not yet ready to do the right thing for this, heck,
 even the base is not fully prepared for this to be on by default.
 Prebind appends an information block to the end of libraries, and
 there are some more details which need to be considered, and handled.
 
 Furthermore, anytime you did a 'make build' of your system, the prebind
 information changes in that information block, and when any of it is
 invalid, it ignored, and you are right back in the un-optimized mode.
 That's safe, and fine, but there are issues.
 
 Like everything else in OpenBSD, we make it available early, and then
 we turn it on when we are confident.  You don't even need to know the
 above details -- just trust we are making the right decisions.

Okay, that's about what I expected. Thanks!

And, frankly, if I didn't have a lot of confidence in you guys making
the right decisions, I wouldn't be running OpenBSD. I *do* like
understanding how stuff works, though.

Joachim