Re: dragonfly pdf documentation

[Miguel Filipe <miguel.filipe@xxxxxxxxx>]

Hi all,

On Tue, 29 Mar 2005 22:53:50 +0800, Bill Hacker <wbh@xxxxxxxxxxxxx> wrote:
> Erick Perez wrote:
> 
> > Thanks to all. I've got the PDF, will print and start reading.
> > So far I have heard that BSD is the more robust *nix OS out there. I
> > run a bunch of server in Linux (Whitebox, Redhat enterprise, Suse)
> > running sendmail, squid, sshd, ClamAV, apache, imap and the most
> > recent, an iPBX called Asterisk, a few linux based routers and some
> > other stuff.
> > I need performance and i heard i cant go wrong with bsd.
> > I was reading the design goals of dragonfly and i agree with that, so
> > i'll give it a try.
> >

Thats great!

> > Since all my Linux installations are production servers.....can I
> > switch or 1.0a release is not ready for prime time? (i got the march
> > 27 build)
> >
> If/as/when I feel the urge to run a Linux, it has
> generally been Slackware or a derivative (VectorLinux
> most recently), but, aside from IBM's non-bootable JFS,
> or SGI's XFS, Linux is still in search of a truly robust
> file system.  'Pretty face', but it is a pick-up trick where
> *BSD is a freight locomotive
> 

thats not true.
reiserfs, ext3 and xfs are full production, fast, stable filesystems.
xfs scales pretty well with thounsands io req, on 4cpu smp machine I mantain..
filesystem is around 7 TB..
and no bsd compares to linux on 4 cpus... linux scales better...

I'm loving the direction of dragonflyBSD, I hope and want it to
surpass the scalability of linux in MP machines.. and can't wait for a
SSI system made of clusters of machines..

BSD is a UP locomotive...
linux and solaris are SMP pick-up trucks.. the kinds used in
Paris-Dakar rallies...

For much that I love the "bsd way", saying that BSD is a locomotive
and linux a pretty-face pick-up, is pure surrealism...
Linux isn't the 2.2 anymore, its the 2.6, scaling in O(1) on mostly
anything I can remember, doesn't have GIANT or BKL.. and is used on
512 cpus machines...
thats bigger machines than solaris runs on...
(not to meantion being used on the biggest machine on the planet: BlueGene)



> The thing you will appreciate most in moving up to *BSD
> is that once configured and put into service, the OS
> just doesn't break. Apps - maybe, but not the OS.
> 
> Robust file system, gracefully  chugs along under
> overloads that would down a Linbox OR many of
> the remaining 'commercial' UNIX variants.

never seen a netBSD, freeBSD or other *BSD surpass linux or solaris on
MP machines..
maybe in UP that happens...


> 
> Most of us reboot quarterly or semi-annually just
> to keep up with patches. But now and then ....
> 
> conducive.net had a bad HDD partition locked-out
> several years ago, has been running well over 400
> days since last OS rebuild & reboot, yet would
> need three more years before it could make it into
> the top 50 uptimes. Sometimes all 50 are *BSD's.
> 


Uptime is most times "this is how big my penis is" from the sysadm.
There's a lot of linux and solaris machines with big uptimes.. and
normally... are all rootable because of kernel exploits. Same deal
with BSDs.

Shorter uptime should mean updated kernel. And thats good.

Of course that availability is a top issue, but normally everything
with a high availability requirement have setups with several nodes,
master-server, fail-over server etc.., and nodes can be taken
down/rebooted without any impact on availability of the total system.

At my datacenter, we prefer updated and patched machines instead of
big uptimes, we have solaris, linux and bsd machines..


> It will be running DragonFly 'Real Soon Now', as
> I have spent the last 12 hours wrestling with
> 'another' BSD, during which it has proven to
> me that DragonFly is *already* caught up with
> and in many respects, surpassed, its older
> brethren.
> 
> How so? IMNSHO, it isn't (yet) the new model,
> it is the thoroughness of the code review needed
> to prepare for it.   DragonFly team have been
> pulling together the best parts of all the other
> *BSD's and finding and fixing lots of long-dormant
> issues as they go.
> 
> Bill Hacker
> 

best regards,

-- 
Miguel Sousa Filipe