Re: FreeBSD 7, DragonFly's status
Dmitri Nikulin wrote: At the risk of sounding like a troll, may I ask, if FreeBSD 7 has high performance, high stability and remains reasonably clean and maintainable, doesn't that partly invalidate the reasons DragonFly was created? 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
Re: rsync vs. cvsup benchmarks
Vincent Stemen [EMAIL PROTECTED] wrote: I have some benchmark test results comparing rsync to cvsup. I did 12 client side tests over the last week. 5 against TheShell.com, 3 against AllBSD.org, and 4 against chlamydia.fs.ei.tum.de. All tests were mirroring the DragonFly BSD source repository. The tests were done with various aged repositories at different times of the day and night, some with compression on and some with it off. Each test was done by unpacking two identical copies of a given aged repository, one to run the cvsup test on and one to run the rsync test on. As I understand, cvsup maintains state between updates using checkout files in a separate sup directory. If you are missing that directory, or it does not correspond to your aged tree, cvsup won't do very well. You should test cvsup by checking out the tree, waiting a week (or whatever the time is) to age it, and then updating it. Likewise for rsync (though it doesn't require a checkouts directory). Rahul
Re: rsync considered superior (was: Re: rsync vs. cvsup benchmarks)
Simon 'corecode' Schubert [EMAIL PROTECTED] wrote: Thank you for these thorough tests! We finally have some hard numbers to work with. I think it is obvious that rsync should be the preferred update mechanism if you want to download the cvs repository. To download, yes, to update, that's not so clear. To repeat my earlier mail: Vincent appears only to have installed a tarball of recent (but not current) sources and used cvsup / rsync to update them. But to operate efficiently, cvsup needs checkout files, which it would have only if it was run previously on those sources. See the FAQ: http://www.cvsup.org/faq.html in particular, numbers 37 and 38: In order to update your files efficiently, CVSup needs to know what you've already got. It stores this information in files called checkouts files... If CVSup can't find a checkouts file that it needs, it falls back on other methods of determining which files you have. One such method is to compute checksums (MD5 file signatures) for each of your files, and use those to figure out which file revisions you have. This is perfectly safe, but it is inefficient. It slows down your update and also puts a heavier load on the server. To compare cvsup minus checkout-files to rsync seems quite misplaced. Most people will never use cvsup merely to download sources: they will use it to keep them regularly up-to-date. Rahul
Re: Plans for 1.8+ (2.0?)
Matthew Dillon wrote: Believe me, I think about this all the time. I frankly have no idea whether 'DragonFly The OS' itself will survive the test of time, but I guarentee you that everything we develop for 'DragonFly The OS', especially more portable entities such as filesystems and cluster protocols, *WILL*. The moment you leave the context of the operating system codebase and enter the context of userspace, you guarentee code survivability. But isn't there a lot of kernel infrastructure in DragonFly that you have done, to allow this stuff to run in userspace? So won't any other operating system need to have that infrastructure too? Or will it be fairly straightforward to, say, run MattFS under FUSE on Linux? There would certainly be great interest in the Linux world in a robust filesystem with the features you describe and a BSD licence. Uptake of ZFS has been slow because its licence conflicts with the GPL, so it can't be put in the kernel. The other filesystems on Linux don't do anything revolutionary. I've been running Linux for a while now, since a sane distro (Debian/Ubuntu) lets me focus on work rather than struggling with ports/pkgsrc everytime I want to install a package, but I seriously want to install DragonFly on my next computer some weeks/months from now... perhaps dual-booting with FreeBSD or NetBSD, so that I can share my /home partition. Rahul
shutdown on BSD and Linux
I've long had a question on the shutdown process. Linux systems run a separate shutdown script for every process that was started at boot, and can take a minute or two to shutdown. FreeBSD and Dragonfly, as far as I can tell, just kill all processes, flush buffers, unmount filesystems and shutdown/poweroff, which takes about 5 seconds. So what's up? Is BSD-style shutdown dangerous, or are the Linux people stupid? The question came to my mind again when I saw Ubuntu's specification for shutdown in their future versions: https://wiki.ubuntu.com/Teardown Basically, it says the majority of init scripts needn't be called at shutdown because the processes can just be sent signals and trusted to do the right thing. However, some controlled shutdowns *do* need to be done. Why can the BSDs get away with not doing these controlled shutdowns? BTW - the poweroff on my laptop, with Dragonfly and FreeBSD (last I checked), is also accompanied by a rather alarming and short-lived whine, as if a spinning disk or fan was suddenly stopped. I don't get this sound with linux or windows. Rahul
Re: shutdown on BSD and Linux
Bill Hacker wrote: Rahul Siddharthan wrote: The question came to my mind again when I saw Ubuntu's specification for shutdown in their future versions: https://wiki.ubuntu.com/Teardown Basically, it says the majority of init scripts needn't be called at shutdown because the processes can just be sent signals and trusted to do the right thing. However, some controlled shutdowns *do* need to be done. Why can the BSDs get away with not doing these controlled shutdowns? Because the *BSD's are complete *Operating Systems* - with a very long history of refinement as well as imrovement. I don't see how that answers the question. A *BSD variant is NOT a 'distro'. It is developed and tested as a whole-cloth exercise. Th core components are know in advance, and tested together. If you include ports/pkgsrc, it IS a distro. And decidedly flaky, at that, compared to most linux distros. No BSD comes with Apache or PostgreSQL in the base system, and only NetBSD includes Postfix, to give the three examples in Ubuntu's teardown wiki article. Think of *BSD as the refined 'whole system' characteristic of a Mercedes - auto or truck. Linux, by comparison, is any of a brazillion varieties of garage-built hot-rod - motorcycle to 'bigfoot' pickup truck - kitted together out of whatever bits of kit the 'distro' packagers happens to hold in high regard. I'd have taken that seriously at one time -- in fact I did -- but one too many crashes that completely trashed my UFS+softupdates filesystem changed my mind. When I reported that on FreeBSD, the answer is yeah, ATA does write-caching and lies about it and sucks generally, tough, use SCSI. (And I'm not the only one to have had trashed filesystems, there are plenty of unexpected softupdates inconsistency errors reported on lists. Some bugs were found and fixed by Matt, IIRC, but it looks like only Kirk McKusick really understands softupdates.) Yes, I use cheap ATA hardware, and don't always notice when my laptop battery is going to die, and sometimes plug in unstable devices, so I have occasional crashes and unclean poweroffs. On Linux ext3, held in near-universal scorn by BSD types, I have NEVER had a trashed filesystem, and only ever lost data in a couple of open files (usually system logs). In fact, the only problem I ever remember having on linux is poor VM behaviour, exhibited when a runaway process eats all available RAM. And these days that's much better too. Distro's aside, Linux' Kernel is nothing to write home about, either, so it is starting off handicapped. It's way better than BSD kernels on modern hardware, that need to handle devices that may appear or disappear without notice -- USB, PCMCIA, firewire I have NEVER panicked a Linux system by removing a USB device, no matter whether it was in use or not. I can panic FreeBSD or Dragonfly in a few seconds that way. And if it doesn't panic immediately, it spews absurd messages about being unable to detach the device because it is in use, and then panics half an hour later. And, again, I'm not the only person to have seen this. In fact, I have only ever panicked a Linux system in years by using a ndiswrapper driver, and that too went away after I recompiled a kernel with 16K stack space (which Windows has and NDIS drivers assume). But it is free and available, and 'has lots of drivers...' .. and WORKS. BTW - the poweroff on my laptop, with Dragonfly and FreeBSD (last I checked), is also accompanied by a rather alarming and short-lived whine, as if a spinning disk or fan was suddenly stopped. I don't get this sound with linux or windows. Rahul Sounds more like a CPU-fan or HDD spun UP, not down, as needed in a burst of intensive activity (putting stuff away properly before shutdown..) Nope... if the burst of activity happens while (as I said) the machine is powering off, something is seriously amiss. On linux, the sounds die away and the machine is silent for a second or two BEFORE poweroff. Rahul
Re: shutdown on BSD and Linux
Joerg Sonnenberger wrote: On Thu, Sep 07, 2006 at 10:28:44AM +, Rahul Siddharthan wrote: I've long had a question on the shutdown process. Linux systems run a separate shutdown script for every process that was started at boot, and can take a minute or two to shutdown. FreeBSD and Dragonfly, as far as I can tell, just kill all processes, flush buffers, unmount filesystems and shutdown/poweroff, which takes about 5 seconds. If you use shutdown to reboot, it runs the scripts from /etc/rc.d as well, but most simply don't do anything. Thanks Joerg (and Oliver) for your answers. I'm still puzzled because in the linux case, too, most scripts don't do anything (or just send a signal). And the startup time for BSD is faster than Linux but not that much faster, compared to the shutdown time. If the fork/exec of a shell is what causes the overhead, then---for a similar number of scripts---the systems should take similar time to shutdown. Or maybe it's just that /bin/sh is much faster than /bin/bash... and startup has other overheads so it's not so noticeable. Rahul
Re: shutdown on BSD and Linux
BTW - the poweroff on my laptop, with Dragonfly and FreeBSD (last I checked), is also accompanied by a rather alarming and short-lived whine, as if a spinning disk or fan was suddenly stopped. I don't get this sound with linux or windows. I had an older system that would do this with the fans; I never saw a negative effect. I assumed it was some setting that was tripped as systems were shutdown, which made the fans react as if the temperature was too high - perhaps the equivalent of a burst of static. I never saw a negative effect either. It was just an alarming sound. I have a computer on which the fan-controls does not start working until somewhere post BIOS, before that they run for full. Might be something like that but in reverse, the fan-control is disabled and the fans run for full by default. How does the computer sound when it starts? My fans are pretty noisy and come on full blast on power-on, die away initially, and come on again after a bit. Then they stay on. It's an old Pentium-IV based HP laptop and runs pretty warm (and I live in a tropical city). I'm not totally sure this poweroff-time sound is the fan though. Rahul
Re: shutdown on BSD and Linux
Justin C. Sherrill wrote: PS: By the way, recently someone suggested in a FreeBSD mailing list that start scripts could be run in parallel if they don't depend on each other (which rcorder(8) can easily find out). It would probably speed up booting. However, I don't know if anyone is actually working on implementing that. As I recall, Apple's launchd is a replacement for rc (and init and inetd), and runs in parallel. (My Mac does start up very fast indeed, though launchd is not the only reason) http://developer.apple.com/documentation/Darwin/Reference/ManPages/man8/launchd Ubuntu too is starting on a replacement for init, called upstart https://wiki.ubuntu.com/ReplacementInit The developer says he would have started with launchd if it had had a free licence to begin with, and even now they don't seem happy with the licence. I tried upstart on my laptop and got the fastest console login I have ever seen: within a couple of seconds of the kernel loading, I could log in to my home directory, even as it continued to probe other hardware, connect to the network, etc. The graphical login (kdm in my case) takes much longer, I think about as long as with old-fashioned init. Rahul
Re: D-BUS, anyone?
Ivan Voras [EMAIL PROTECTED] Something like that has been done, for example on FreeSBIE livecd of FreeBSD (using devd(8) IIRC). But there's a major problem when devices get disconnected (i.e.: the device gets pulled from under the mounted filesystem). Actually it's easy to panic DragonFly (or FreeBSD, last I checked, which was early 5.x) by pulling out any USB device while it's in use -- not necessarily a storage device, it happens for me with a USB-to-serial convertor too, and used to happen under FreeBSD with a USB audio device. Annoyingly the USB audio device was often not actually in use (no audio playback/recording happening, no mixer program running), but the kernel still believed it was in use and refused to detach it even though it was physically gone. The panic happened if I plugged it in again. AFAIK, this problem was considered too complex to deal at this time because it involved re-architecting portions of VFS. The response I got on the FreeBSD lists at that time was it would involve major rearchitecting of something else (not VFS) since the kernel assumes that a device, once detected, will always be there and will not be abruptly yanked out... I don't know if this has changed lately. Rahul
Re: Partially fixed Re: Xorg / pkgsrc problems
Joerg Sonnenberger wrote: On Mon, Nov 07, 2005 at 07:21:01AM +, Rahul Siddharthan wrote: It turns out this pkgdbdir seems to conflict with Joerg's and drhodus's packages. Using /var/db/pkg (having nuked existing pkg install) fixed it. Should the wiki be fixed? Yes, please. It is seriously out of sync with reality. Ok, done :) Also fixed links to prebuilt packages. Will mail you privately about xorg core file/log. Thanks Rahul
Re: metamail on pkgsrc - patch
Steve O'Hara-Smith wrote: If this is a bad idea please let me know what to do with any other patches for pkgsrc I amy come up with. Since pkgsrc is becoming official, how about a dragonfly.pkgsrc list/group where users' patches can be submitted? Joerg et al can then review them and feed them further upstream. Rahul
