"Dmitri Nikulin" wrote:Matt disputes the maintainability part of FreeBSD, but that is for the FreeBSD folks to worry about. Speaking for myself, I'd much prefer to use a BSD -- I used FreeBSD and DragonFly for quite a while -- but currently use Linux despite its bloat and other issues. There is one single overriding reason why I don't use FreeBSD: removable media. It is utterly absurd that, in 2008, you can't reliably use USB memory sticks without panicking the system. If you complain on the FreeBSD lists, they'll tell you that it's your own damn fault for not unmounting it first, and not keeping it physically stable so that it doesn't accidentally jiggle, or whatever. They also say the problem runs so deep, and involves so many layers, written over the last 15 years, that it can't be fixed. Says Warner Losh: "If it were easy, one of the dozen or so people that have tried to fix it in the past 8 years would have succeeded." http://lists.freebsd.org/pipermail/freebsd-stable/2007-July/036219.html On the same thread, somebody pointed out that the issue had been fixed in DragonFly, and Matt commented on what was involved. http://lists.freebsd.org/pipermail/freebsd-stable/2007-August/036469.html There was NO follow-up. Nobody in FreeBSD-land is interested in sorting out the issue. Well, that's up to them, but I need my USB media. The "unmount first" advice was ok in floppy days -- it is difficult to accidentally remove a floppy -- but USB is physically much less stable. It's not just USB mass storage media -- I have had problems with USB audio, USB-to-serial converters, etc. The entire USB stack is flaky, and maybe, as Warner says, the flakiness extends deep into the system. Maybe this doesn't apply so much to servers. If you really want to run FreeBSD, you can ensure nobody inserts/removes USB devices or otherwise fiddles with the system. For a desktop/laptop user it's another matter. So to me DragonFly, when it supports your hardware, seems the more stable system. But, as you say, AMD64 is low-priority, and SMP isn't done. (Matt says the infrastructure is all there but someone has to step up and fill in the gaps, ie take subsystems out of the BGL.) That excludes most newer computers, which are at least dual-core (most servers are multi-core now) and nearly always are 64-bit. I'm still keeping an eye on DragonFly, and hope to run it again one of these days. I think the biggest problem in FreeBSD that DragonFly fixes is attitude. Matt, and the others, don't brush aside problem reports saying "it can't be done" or "that's not the true BSD way". Rahul
| Pardo | Re: pthread_create() slow for many threads; also time to revisit 64b context switc... |
| Andrew Morton | 2.6.23-rc4-mm1 |
| Albert Cahalan | JIT emulator needs |
| Jack Stone | [PATCH 5/7] Replace DPRINTK with pr_debug in ncpfs |
git: | |
| Theodore Tso | Re: git on MacOSX and files with decomposed utf-8 file names |
| Johan Herland | [PATCH 0/6] Refactor the tag object |
| Ingo Molnar | [OT] Your branch is ahead of the tracked remote branch 'origin/master' by 50 commi... |
| Johannes Schindelin | [WIP PATCH] Add 'git fast-export', the sister of 'git fast-import' |
| Mark Reitblatt | US Export of Cryptography |
| Rico Secada | About non-free software in OpenBSD |
| Reza Muhammad | Dell PowerEdge 1950 III / R200 |
| Ivo Chutkin | problem installing some packages on 4.2 |
| David Miller | Re: [RFC PATCH 05/13] ip: support for TX timestamps on UDP and RAW sockets |
| Adrian Bunk | [2.6 patch] remove CONFIG_NET_SCH_RR |
| Erik Mouw | Lots of "BUG eth1 code -5 qlen 0" messages in 2.6.24 |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
