Date: Sun, 22 Dec 2002 21:25:32 +0100 From: Miguel Mendez <flynn@energyhq.homeip.net> To: Rahul Siddharthan <rsidd@online.fr> Cc: keramida@ceid.upatras.gr, jcm@FreeBSD-uk.eu.org, chat@FreeBSD.ORG Subject: Re: FreeBSD's momentum and future prospects Message-ID: <20021222212532.4de28aae.flynn@energyhq.homeip.net> In-Reply-To: <20021222190153.GA2873@papagena.rockefeller.edu> References: <20021222034806.GA34537@dogma.freebsd-uk.eu.org> <20021222064026.GA421@papagena.rockefeller.edu> <20021222065216.GA468@papagena.rockefeller.edu> <20021222172853.GC16833@gothmog.gr> <20021222190153.GA2873@papagena.rockefeller.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 22 Dec 2002 14:01:54 -0500
Rahul Siddharthan <rsidd@online.fr> wrote:
Hi,
> Regarding the filesystem, well softupdates-enabled ufs is more
> crash-resistant than linux. But even there it's not black and white.
More resistan than Linux what? :)
I've never heard anything good about reiserfs, played a little bit with
jfs, but I can tell you that XFS smokes any other filesystem, except,
perhaps, Veritas filesystem, which is the de facto for large arrays
on Sun servers. I understand UFS+S is very nice, but if the risk of
losing data is there anyway, I'll take a 2 sec crash-recovery vs 2 hour
fsck anyday. The Linux version is still lacking some features that were
in the original IRIX implemenation, but it's IMHO a very impressive FS.
> for PR reasons...(I turned off write-caching after a crash messed
> up my drive, and I haven't noticed any significant performance
> loss.)
Depends on load, applications running, etc. My guess is most people
won't notice much, and those who really need the performance on a server
are probably using SCSI anyway.
> 2. FreeBSD people like to diss the journalling filesystems on linux
> ("it's a 'bandaid' in case of crashes, and our filesystem is
> crash-resistant and don't need a bandaid"). This misses the major
I don't think they think of it as a bandaid, it's just a different
solution to the metadata consistency problem. None of these systems will
guarantee data integrity in case of a system crash. A log replay is
orders of magnitude faster than fsck.
> hour while it checks the FS before rebooting. 5.0 has background
> fsck to alleviate the problem, but people's experience with that
> seems, well, mixed (judging by the mailing lists...)
I've personally had good experiences with bgfsck, but you're right,
others have had problems.
> Regarding other things, I think linux may actually be *more* stable
In which case? A desktop? A server? VM performance in the 2.4 series has
been horrible, unacceptable for something you could call 'production
ready'.
> we're less aggressive about marketing it (eg, linux people will say
> "such and such works fine, well ok there are these problems and these
> things don't quite work, but basically we do support it" where freebsd
> people will say "support is very preliminary, use at your own risk").
Exactly, it's a case of perception, how do you rate the maturity of a
driver.
> There are even older problems with FreeBSD. At least one such problem
> went unresolved for literally years. (I don't know whether it's fixed
> now.) Basically, mount a write-protected floppy in read-write mode,
> try to write to it, then try to unmount it -- instant panic.
Yes, I remeber that one :) Too bad I no longer have floppies on my
computers :)
> fundamentally I think they're more responsive to users because they
I've found both the FreeBSD and NetBSD communities to be quite
responsive to people's needs, as long as it fits the project's goals, of
course. OpenBSD, well, we all know Theo :)
> carry less historical/ideological baggage. For example -- gentoo
> linux has a ports-like system which was conceptually borrowed from
> FreeBSD's ports, but is now much better than FreeBSD's in my opinion.
It still has a long way to go too, I've heard many good things about,
but many ebuilds break quite often.
> Now, FreeBSD does have something which solves many of the problems of
> the basic ports system -- namely, portupgrade -- but it's written in
> ruby so it's never going to make it to the base system. And now perl,
> too, is out of the base system; so until someone writes something
> better in plain C or sh, we're going to be stuck with the basic ports
> infrastructure...
Getting perl out of the system was a very good move IMHO. About
portupgrade being written in in ruby, well, nobody else has done
anything similar in C (I also think C is not the best choice for such as
task), so we're stuck with this. FWIW, portupgrade works very well for
me. Maybe we could do something like pkg_hack does on NetBSD. It's
written in C, and it seems to do the trick.
> There are lots of other things I could say, but it all comes down to
> this: I think FreeBSD people could learn to be more tolerant of the
> "linux way". Linux is a fast-evolving, highly mutating ecosystem,
I think most FreeBSD people don't care about Linux that much, they like
BSD and they use it.
> there is no standard "base system" and not even a standard kernel:
Well, now there's this LSB thing, but that alone has been a reason for
quite some people to prefer BSD. There's only one {Free,Net,Open}BSD,
not a myriad of different distros.
> components aren't as stable as they should be. But they also come up
> with a lot of good ideas, which then make it somewhere (if not in
> Linus's tree, in Alan Cox's or somewhere else; if not in Red Hat's
> distribution, in SuSE's or Gentoo's). I think that's why people are
> attracted to it.
Of course there are good ideas, and those are not to be ignored. I think
that those Linux-hating BSD users a just a few, but quite vocal. I don't
think that represents the general thinking of the community.
Cheers,
--
Miguel Mendez - flynn@energyhq.homeip.net
GPG Public Key :: http://energyhq.homeip.net/files/pubkey.txt
EnergyHQ :: http://www.energyhq.tk
Of course it runs NetBSD!
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021222212532.4de28aae.flynn>