Reading non-installed man pages, etc.
I'd occassionally like to be able to read manpages from somewhere other than the MANPATH. Let me give you two concrete examples of things that I can do on linux, that I don't know how to do on FreeBSD $ man /mnt/falco3/usr/share/man/man1/ls.1.bz2 $ man /home/andi/foo/doc/foo.1 In the first case, I'm looking at the manpages exported (over NFS) from a Mandrake linux box; in the second, I'm looking at the manpages for a program I'm trying to get installed. First, FreeBSD's man doesn't seem to accept a full pathname. In the first case, I can get around this with MANPATH or -M (man -M/mnt/falco3/usr/share/man ls), but in the second, that won't help. Second, FreeBSD's man doesn't handle bz2 compression. I suppose I could do something like this: $ bzcat /mnt/falco3/usr/share/man/man1/ls.1.bz2 | groff -man -Tascii -mtty-char | less And I could write scripts to wrap this up (figure out whether to use bzcat, zcat, or cat; whether we're talking to a tty-char-capable terminal or something else; which charset to use; what pager to use; etc.). Basically, it'd do everything man is doing except for finding the page in the MANPATH and dealing with catfiles, which sounds like a bit of a duplication of effort. So, if this is already done somewhere, or there's an way that I've missed to make man or some other tool do what I want, I'd rather not reinvent the wheel. Also, I seem to remember installing GNU's *roff stuff onto a Solaris box and having a program that let me do 90% of what I want to do. The groff(1) manpage has a reference to groffer that sounds like it might be what I'm remembering, but I can't find any more information about it (or the program itself). Another alternative would be porting the GNU man (with the bzip2 patches), but I'm not sure this is a good idea (I don't know if it would require other stuff to be ported, for example; also, the name gman is already taken for a Gtk+ xman-type program). Any ideas? Thanks. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: which linux? (not flame bait, thank you)
On Tue, 2003-11-04 at 00:20, DavidB wrote: My question is this, I would like to have a little exposure to linux and am wondering which distro to run, I used redhat back at the same time I started with FreeBSD3~ , not sure if I should check them out. My personal favorite distro is Mandrake--not because it's easy to use, but because it's easy to use as a development box. My next choice is Debian, for all the usual reasons. Mandrake and Debian also have by far the best user/community support networks. As for what's best for you, it really depends on what your goal is. Are you looking to get exposure as a user, an admin, or a developer? Is this to flesh out your resume, or to make you a better open source contributor, or just for fun? Without knowing all that, the best I can do is list the pros and cons of the distros I've ever played with that aren't defunct (I'll start with the ones you mentioned): Slackware, Debian, Gentoo, Redhat, Mandrake, SuSE, Crux, Elfstone, Conectiva, TurboLinux, Lindows. Also, you may want to take a look at http://www.linux.org/dist/index.html before making a decision. Apparently, there are 146 English-language, i386-platform, currently-maintained distros, and I've only tried a little over a dozen Slackware - Slackware is the most FreeBSD-like in administration. However, for my taste, it's too barebones. Not barebones as in secure by default, but as in missing things you need. You have to know exactly what you want to install, and how to configure it, to get into Slackware. The advantage is that if you _do_ know all of this, it's easier to get a slimmed-down system (to run as fast as possible, in as little disk space as possible). The disadvantage is that you probably don't know all of this. Still, some of the problems that linux people have with Slackware probably won't affect a FreeBSD user as much. For example, last I checked, they still don't follow the FHS, so nothing's where you expect it to be--but then that's going to be true on _any_ linux for a FreeBSDer. Similarly for initscripts, again irrelevant to a newcomer from the FreeBSD world. Also, some of the admin tasks that I found difficult and poorly documented turned out to be pretty close to the FreeBSD way (which _is_ well documented--plus, you already know it). So, if you already know how to administer a FreeBSD box, you'll probably have less to learn on Slackware, although there will be less guidance in learning it. Overall, I wouldn't recommend Slackware to anyone who hasn't already been using Slackware. Debian -- Debian is the most FreeBSD-like in philosophy. For example, they have a STABLE branch that always works, period, even if it has to be a bit behind the times to do so. They have the least-patched kernel, gcc, glibc, etc. of all the major distros, and they put the most work into making sure everything integrates properly. Whenever Redhat seems to be going the wrong way, most of the other distros try to copy them and then fix what they screwed up--but Debian instead ignores them and spends the time findind a better solution. They've come up with some unique innovations, like the menu system and update-alternatives, which have turned out to be useful even on top of Redhat-based distros. The main disadvantage of Debian is that it's less like other distros than most distros, so if you're looking for general linux experience, it may not be the way to go. Also, even on UNSTABLE, Debian tends to be further behind some other distros (old versions of some packages, other packages not even there yet, etc.). But, if neither of these issues bothers you, then go with Debian. Supra-Debians --- There are a number of Debian-based distros that will install a complete system ready to go as a workstation, server, etc., but that can be administered from there just like any other Debian system. For example (this is a while back, so it may be out of date), I used Libranet in teaching linux, because it installs a complete KDE workstation out-of-the-box, but whenever you want (or need) to play with something, it's just like a stock Debian box. But don't use Xandros--although it's Debian-based, it's heavily modified in peculiar ways. Gentoo -- Gentoo is the most FreeBSD-like on the surface. It's based around portage (emerge), which is essentially ports without a base system. The fact that everything is a port--even the kernel--seems really nifty at first, but it also seems to lead to serious problems keeping the whole distro in sync. (Or maybe it's just that they don't have as large of a following as FreeBSD?) Also, there aren't nearly as many packages for gentoo as for FreeBSD (much less Redhat or Debian), and portagifying a package given an RPM specfile (or even a FreeBSD port) is generally non-trivial. Plus, I've played with gentoo a few times, and each time I have lots of fun until I run into some dependency problem that takes days to sort out. And, while it's nice to be
Re: Evolution without gnome
Notice that everyone praising Evolution or Kmail used their mailer of choice to compose the message in question, but: Harald Schmalzbauer: User-Agent: KMail/1.5.4 Well, even this incredible slow thunderbird was better than evolution IMHO. Scratch one vote for Thunderbird (leaving 0). Sebastian Smoller: X-Mailer: Ximian Evolution 1.4.3 so i have to install a lot of gnome stuff to be able to use evolution right ? thats bad :( But not so bad that you haven't done it on your other systems, right? And then there's Parv, suggestor of mutt, whose mail contains no agent/mailer header. IIRC, mutt defaults to adding X-Mail-Agent: mutt but I'm sure it can be configured to put anything else, or nothing at all--and I doubt many modern mutt users leave the defaults alone. So I'll assume he's using mutt. To answer Parv's question, why not use mutt? Well, I can't speak for anyone else, but for me, it's because, despite the advertising, mutt is not nearly ELM-like enough--at least not after spending so many years using ELM, much of that over 300 baud connections, so that any deviation throws off my finger-memory. It'd be easier for me to switch to dvorak than mutt. And the fact that more than half the keystrokes are only documented in the manual, outside the software, doesn't help. I really did try, because I realized that otherwise I'd have to go to a graphical MUA or I'd be stuck with elm for life (which means no MIME, no security, no online IMAP...). Eventually, I decided to go to a graphical MUA. And, a few years later, Evolution 1.4 came out, and now I have one I can use happily. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How does FreeBSD calculate disk sizes
I think this is (mostly) a GiB vs. GB confusion. In case you have no idea what I'm talking about, here's some background (if you do, skip the next paragraph): Giga is the metric prefix meaning billion (or thousand million, if you're British)--that is, 10^9. Computer people tend to use it to mean 2^30, which is actually 1.073741824 * 10^9. However, hard disk manufacturers use the metric meaning. So, a hard disk maker's GB is 7% bigger than the rest of the computer industry's GB. To clear up the confusion, the standards people decided that from now on you're supposed to use GiB to mean 2^30 (and MiB for 2^20, KiB for 2^10, etc.--pronounced gibibyte, mibibyte, kibibyte, etc.). And so far, just about nobody has listened So, when fdisk says 69460MB, it means 69460 * 2^20, which is 72,834,088,960 bytes. When your disk manufacturer says 72GB, they mean 72,000,000,000 bytes. (They've given you 834MB for free. How nice.) Meanwhile, when df says your partition is 64GB, it means 64 * 2^30. And your 2GB swap is, similarly, 2 * 2^30. Do the math: 64 * 2^30 = 68,719,476,736 2 * 2^30 = 2,147,483,648 -- 70,866,960,384 In other words, you're not missing 6GB. As for the rest of it: sucks# disklabel -n da0s1a da0s1a is a partition, not a slice. You're asking it for the partitions within a partition; it's bound to get confused. Try this: # disklabel -n da0s1 (without the a) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: color to files
On Mon, 2003-11-03 at 05:51, Lowell Gilbert wrote: andi payn [EMAIL PROTECTED] writes: Was the xterm termcap changed for FreeBSD 5, or have I just done something to fix this and forgotten about it? It's a little more complicated, because the *classical* xterm does *not*, in fact, have color support, but yes, the latest releases on both branches should pick this up just fine. OK, let me restate this to make sure I understand it; please correct me if I get anything wrong. The xterm that comes with XFree86 4.x, and most of the 3.x branch, has ANSI color support. The xterms that come with earlier XFree86 3.x versions and the X11R6.3 reference servers have old-style color support. But in the old days, xterm didn't have any color support (it originally emulated a BW vt100 or something, right?). So, up to FreeBSD 4.8, the terminfo for xterm didn't indicate color support, and you had to specify xterm-color (or xterm-xf86-v40 or whatever). In 4.9 and 5.1, this is no longer an issue; xterm works just fine (unless someone's trying to connect to your FreeBSD box from some box running an ancient xterm...). Should I file a bug report on the ls(1) manpage, then? It says: The default ``cons25'' console has the proper capabilities, but to display the colors in an xterm(1), for example, the TERM variable must be set to ``xterm-color''. This isn't true with 4.9/5.1--and also isn't true for ancient non-color-capable xterms, for that matter. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: color to files
On Sat, 2003-11-01 at 20:28, Malcolm Kay wrote: If you are in X and using xterm then this also has the capability but by default other programs such as ls are not informed of this because the termcap description for terminal type 'xterm' does not declare it. After telling him this same thing, I went and checked, and it appears that on my FreeBSD 4.8 installation, I have to do this (or various other ways of getting the same effect), but on my 5.1 installation, with TERM=xterm, I get color. Was the xterm termcap changed for FreeBSD 5, or have I just done something to fix this and forgotten about it? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: hacking broken ports
The rest of your question has been answered, but: On Sat, 2003-11-01 at 23:00, William O'Higgins wrote: I found that there was only on reference to the filename in the Makefile, so I changed it, and then I generated an MD5 on the file that I had and put it into distfile. Instead of manually generating the MD5 and editing the distfile, you can fix the Makefile, delete the distfile, and do a make makesum and it will be built for you automatically. (Similarly, if for some reason the README.html has to be updated, just delete it an make readme.) Otherwise, you're on the right track. Also, in addition to checking that nobody's already submitted this, reading the Porting handbook, and submitting your fix via send-pr, you should probably email the package maintainer directly. In fact, you might want to do this first--it's possible the maintainer is about to do this, or has already tried and run into problems that she can tell you about before you hit them, etc.--and/or maybe she knows where you can get the previous version of the tarball. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Evolution without gnome
On Sun, 2003-11-02 at 15:50, Harald Schmalzbauer wrote: Well, even this incredible slow thunderbird was better than evolution IMHO. I have a pretty complicated setup--multiple identities, even more IMAP mailboxes, mailing lists that I want to filter into separate folders and auto-purge, a Palm to sync with, etc. If you don't need all this, something simpler should work fine. However, if you need something complicated, I don't think anything can match Evolution 1.4--including Outlook Express, Outlook, and Eudora, and Thunderbird and kmail (and especially including Evolution 1.2). For example, it's the only one that handles filtering IMAP properly (the kmail people refuse to accept a patch to add this)--although the vfolders feature means you might not need to anyway. It's the only one that handles error conditions like mail servers that occasionally go down for hours on end, running out of disk space, incomplete Palm sync'ing, etc. properly. In short, it does everything I need, and it just works. Plus, even on the slowest machine I have (PPro 200), it's still (just barely) usable (at least with a light Gtk 2 theme, running under fvwm2). ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: color to files
On Sat, 2003-11-01 at 06:16, SWIT wrote: Is there a way to make the directories to show in color when doing a ls ? thanks mark Did you try a man ls? It should give you two options: use the -G parameter, or set the CLICOLOR environment variable. If you don't know how to do this (or how to make it permanent--as a hint, try adding export CLICOLOR= in ~/.bashrc, if bash is your usual shell), come back and ask for details. If this doesn't work for you--or if it works on the text console but not in X, or if it only works in some X terminal emulators but not in others--make sure you've read the ls manpage's section on CLICOLOR and dealt with the termcap issue. If you don't like the colors, read the LSCOLORS section of the manpage. You can also install the GNU fileutils port/package (/usr/ports/sysutils/fileutils), and gls --color=auto should colorize things in that vibrant Stallman style that linux people are used to. Then you can alias ls to gls --color=auto in your .bashrc, etc. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: why are theynot updated WAS Re: samba 3.0, FreeBSD 5.1
Meanwhile, on Sat, 2003-11-01 at 12:34, SWIT wrote: I am just curious. But for those that continually sing unix over ms praise you think that matters like this would be looked after so unixes would be easier for the common man/woman to use. Do you think Microsoft always gives you new code as soon as they develop it? Of course not. So, imagine how much more complicated it is for a FreeBSD maintainer to give you new code as soon as some guy he's never met working halfway around the world develops it! Plus, being right at the bleeding edge and being easier to use are often contradictory desires. You want your system to work; you want all of the ports you install to work together; you want to have proper documentation, and a list full of people with experience using the same software on FreeBSD who can help you. All of this is often more important than having version 1.50 instead of 1.48b. Especially for the common man/woman, who enjoys using software more than upgrading it. In essence, this is similar to (part of) the reason Microsoft doesn't give you new code right away--they want to have their QA teams go over it, and their tech support people trained on it, and their marketing people ready to spin the new bugs into features. (Of course they also want to find ways to charge you for upgrades, but that's a side issue; their service packs and hotfixes, and upgrades to IE and OE, and lots of other things, are available at no cost.) Of course any system can be improved. For example, when Mandrake wrote a simple script that scanned Freshmeat every day and emailed package maintainers with messages like, A new version of foo, foo-1.3.21, was released today, at http://www.foo.org/foo/foo-newest.tgz;, that definitely improved the freshness of their contribs repository. I'm sure there are ideas that could help FreeBSD. But I doubt there will ever be a day when every port in the tree has the very newest version available. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: http from command line
On Thu, 2003-10-30 at 16:38, Gregory Stearns wrote: I hate to be a pest but is there a utility to do http web browsing from the command line, and how would I use it? As othes have mentioned, there are many choices--but you probably just want to know which one to use, and how to get started. You probably want elinks. Install it from /usr/ports/www/elinks. Run it like this: 'elinks http://www.google.com'. If you want a graphical browser that works without X, and you have SVGAlib set up, you might want links' graphic mode. Install it from /usr/ports/www/links, and run it like this: 'links -g http://www.google.com'. Or try wb0, or w3m-img. There are a few better options out there, too, but none have been ported to FreeBSD. Here's a brief survey of each of the choices: telnet (or nc, or w3c, wget, or curl): If you can speak http and read html, you can talk directly to the server, if you really want to. www: If you're stuck with a console without curses/ANSI support--or it's 1989--this is pretty spiffy; otherwise, stay away. lynx: The first decent text browser; you want the ssl-patched version. But you probably want elinks instead. links: Essentally lynx plus frames, tables, image maps, ssl, cache management, background downloading, etc. You want 2.1, not 0.98. Or, better, elinks. elinks: Links enhanced with even more cool features. links -g: Adds inline images to links. Works in SVGAlib as well as X. wb0: A graphical browser for SVGAlib, which sometimes works better than links -g, although it's not nearly as complete. netrik: The only real alternative to the links family for text browsing; not as good (especially since it doesn't quite get cons25 or xterm), but if elinks won't work with some site, try netrik. w3m: This is what web browsing would have been like on an Apple ][ or C=64. It does look nice, but it's low on features and has a weird interface. w3m-img: This is w3m with inline image support. emacs-w3m: If you believe that the editor is the operating system, and never leave emacs, you can run w3m from inside emacs. w3: If you really love emacs, wouldn't you rather use a web browser built in emacs-lisp? retawq: Quite cool in some ways, but not complete, not exactly designed for novices, and not up-to-date on features. Oh, and dark blue on black can be a bit hard to read. surfraw: Not a web browser itself, but very handy for text browsing. Instead of navigating to the Webster dictionary site and filling in the forms to look up free, just type webster free and it'll launch your favorite text browser with the answer. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Log every access to a file
On Mon, 2003-10-27 at 03:35, Matthew Seaman wrote: On Mon, Oct 27, 2003 at 11:57:31AM +0800, [EMAIL PROTECTED] wrote: How do you create/add a system log to monitor every access to a specific file (say a database file accessed through samba)? A sample line for syslog.conf would be greatly appreciated ?? :-) Samba has extensive logging capabilities itself -- which generally bypass syslog entirely, although there are options available to use syslog. It will certainly log who is accessing the server and from what machines. I don't think it has the capability to monitor accesses down to the level of a particular file though, but read the manuals carefully to be sure. If you really need to log all accesses to the file, then probably your best bet is to only make the file available via a web interface, which can be set to require passwords before it will allow access and will supply the logs you require. Alternatively, databases such as postgres or mysql can keep detailed logs of all queries run against them. Actually, there are two options that will allow you to monitor accesses of any particular file. The first is to periodically stat that file. This is incredibly simple to do. The disadvantage is that if the file is being accessed very often, you may miss some accesses (if you're checking every second, and two people access in the same second, you'll only see one access); if the file is being accessed very rarely, it's a bit of a waste of cpu and disk time to keep checking it. But, nonetheless, this is sometimes the best way to go. I've attached a script statlog.py (requires python 2.3) that will do it for you. It read a list of filenames (one per line) from /usr/local/etc/statlog.conf, and begins monitoring each one, and outputs to /var/log/statlog.log any time there's been a change to A/M/C time. By default, it checks once/second, but you can change this with the -f flag (./statlog -f 5 means five times/second, ./statlog -f 0.5 means every two seconds, ./statlog -f 0 means as often as you can--which you probably only want to use in conjunction with nice or idprio_. The second is to use fam. I should mention that I've only used fam under linux, and, after a brief glance, it looks like the FreeBSD port (/usr/ports/devel/fam) is not as powerful--in particular, FreeBSD apparently doesn't provide imon support (a way for the filesystem to make a callback to a usermode app like fam--no dnotify or anything similar, either, apparently). Which implies that it's probably just a heavier-weight way of doing the exact same thing--periodically stat'ing a list of files--and that there is no better solution available. But I could be wrong, and it's probably worth testing to see if it works better for you. Also, if the files are stored on nfs-mounted drives (and this may be true for smb also, but I don't know), and the nfs server is running fam, the checks are passed off to the server, which makes them faster (and, if the server is running linux or another imon-capable OS, gets around the worries mentioned above). You should have no problem getting fam itself working if you follow the instructions in the message you get when installing the port/package. Anyway, the second script, famlog.py, is a slightly-modified version of a script that I've used for a similar purpose in linux. It reads the filenames in /usr/local/etc/famlog.conf, tells fam to monitor all of those files, and sends its output to /var/log/famlog.log. If either of these is useful to me, let me know. If you need help automating stuff (making an rc.d/famlog.sh wrapper, and maybe a logrotater), modifying either script to use syslog instead of its own log file (should be a one-line change), etc., just ask. (NOTE: The attachments are scrubbed from the copy of this message sent to the list; if anyone besides the original author wants them, let me know.) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Log every access to a file
On Wed, 2003-10-29 at 02:00, Matthew Seaman wrote: On Wed, Oct 29, 2003 at 01:07:26AM -0800, andi payn wrote: The second is to use fam. I should mention that I've only used fam under linux, and, after a brief glance, it looks like the FreeBSD port (/usr/ports/devel/fam) is not as powerful--in particular, FreeBSD apparently doesn't provide imon support (a way for the filesystem to make a callback to a usermode app like fam--no dnotify or anything similar, either, apparently). Which implies that it's probably just a heavier-weight way of doing the exact same thing--periodically stat'ing a list of files--and that there is no better solution available. Check the kevent(2) man page. It's a generic mechanism for having the kernel message your process when some condition occurs, such as modification of a file. Thanks. This is pretty cool, but it's missing a few things. First, it works only on UFS filesystems. That's no big deal; fam could use kevent on UFS and poll other filesystems. However, that does seem to rule it out for the original poster's purpose (the file he wanted to monitor was mounted via smb). More importantly, kevent apparently doesn't notify you when a file is accessed (or does changing the atime trigger NOTE_ATTRIB? in that case, it does--but to distinguish between an access and a change you'd have to stat the file). This seems to make it unusable for fam, as well as for the original poster's purpose (he wanted to see all accesses to a file). It also doesn't seem to notify you when a file in a directory you're watching is changed. This might would make fam much more complicated. However, I think the same is true of dnotify, so the extra code can probably be borrowed from the dnotify patch Unfortunately other than knowing something happened, it doesn't tell you a great deal else, like who it was that made the alteration. Well, fam doesn't tell you anything more either; neither does imon nor dnotify--or stating a file directly. The OS and filesystem don't keep track of things like who was the last user or process to touch a file. If you want that, you could take fstat snapshots and hope to catch everyone who has the file open (this should work if users tend to access it for a long period of time, say a second or more). Or you could get a lease on a file and see who breaks it (although many programs might try to write the file without breaking your lock first, and just fail and give up--and besides, I don't know if that would work in FreeBSD the way it would in linux). Or you could put a fifo/socket/loopback filesystem/something between the actual file and the pathname people use to access it, and thereby control/monitor all access to it; etc. Even so, fam(1) has apparently not been patched to use kevent(2) under FreeBSD, so, yes, it's probably going to operate by polling the file status every so often. Well, it looks like it would be a pretty easy patch to fam (especially since someone's already generalized the imon code to allow using dnotify instead), but if it can't provide information on accesses, it'd also be a useless patch (which might explain why nobody's done it yet?). Another issue: In linux, you can open a file O_NOACCESS (== O_ACCMODE, if you don't #include anything extra), which gets you an fd to pass to fstat/fcntl/whatever even without read or write access to the file. I assume the dnotify patch to fam uses this. This doesn't seem to work in FreeBSD. If you try to open a file O_ACCMODE, you get EACCES. Therefore, you'd have to open the file O_RDONLY to get an fd for kevent--which means you can't monitor a file that you can't read, which would be another limit placed on fam by using kevent. Plus, kevent doesn't seem to give you information on what's been changed within a directory, so fam would have to do some dirty work on each access (or monitor all files within the directory...). I think the same is true with dnotify; if so the kevent patch could use the same code as the dnotify patch, which is probably fine. Still, it's a good idea; I'll look into this a little deeper. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: X11 and Xfree86
M.D. DeWar: What is the purpose of them exactly. I have read the sites but being alien to the unix world it confuses me. Do they just make unix a windows type enviroment ? Is KDE/GNOME the same or they like themes to X windows. The simple answer is: X plus KDE or GNOME provides Unix with a Windows-type environment. KDE/GNOME are an integral part of that environment. KDE and GNOME themselves _have_ themes, and those are like themes in the Windows world. You want either KDE or GNOME, with all the default stuff that comes with it. In fact, install them both, and play with each for a while. In fact, there's a similar separation in Windows--some of the user environment is provided by Windows itself, and some by separate programs (especially the Windows Explorer program), but this separation is much cleaner under Unix/X. Furthermore, GNOME or KDE themselves separate into a number of separate layers (this is also true to some extent in Windows, but even to the application developer most of this is hidden). This difference has some advantages, and one big disadvantage. The biggest advantage is flexibility. You can run KDE or GNOME, or a few other alternatives, or a more bare-bones X setup with no desktop manager. You can run KDE apps under GNOME, and vice-versa (and so on for the other alternatives). In fact, you can replace almost any piece of the puzzle and everything will work smoothly. The biggest disadvantage is that novices have all these different pieces thrown at them. Instead of just Windows, they have to contend with, say, Unix, X, Metacity, Gtk+, GNOME, Nautilus, Panel, GDM, GConf, and ESD (and that's if you only run GNOME). So, let's look at these pieces briefly: * Unix is the operating system. (Linux people like to further divide this into the kernel and the rest of the OS.) The Windows equivalent is the NT kernel, its Win32 executive, the cmd command-line shell, a slew of command-line tools, a bunch of background services, etc. * X (aka X/Windows, X11, etc.) is the GUI. It's equivalent to part, but not all, of the Windows GUI. You can see what X does by just running X on its own, as Erik Steffl suggested. X also comes with a variety of tools, like xterm, and libraries for building X applications. * Metacity (kwm for KDE) is the default window manager. X plus a window manager is the equivalent to the Windows GUI itself. This is the part of the system that lets you drag windows around, assign hotkeys like Alt+Tab or Winkey+F, etc. You have a wide choice of other window managers, many (but not all) of which are completely compatible with GNOME or KDE. * Gtk+ (Qt for KDE) is a widget toolkit. It's equivalent to (the GUI parts of) the Win32 API. As a user, you never worry about this--you run programs that were built with Gtk+, just as Windows users run programs that were built with the Win32 SDK, and they just run. But unlike Windows, Unix/X has a dozen or so toolkits. You can run apps built against different toolkits together (although they they may not have exactly the same look and feel--a GNOME/Gtk theme only affects Gtk+ apps, etc.). You may have noticed something similar in Windows XP--most applications have XP-style buttons and borders, but some (including the cmd command-line window) have the old-fashioned Win95 style instead. (Maybe it's better to say that Windows XP has 1-1/2 toolkits?) * Nautilus (or Konqueror, for KDE) is the default file manager. It's almost equivalent to Explorer in Windows. Just like Explorer, Nautilus or Konqueror manage the desktop background window and all of its icons, and provide the My Computer and Network Neighborhood browsing, and can even be used as web browsers if you want. * Panel (or Kicker, for KDE) is the program that handles the taskbar and menubar and start menu. It's the rest of Windows' Explorer. * GDM (or KDM, for KDE) is the login manager. This is equivalent to the Login application in Windows. If you set up your system to boot into graphical mode, this is the program that asks you for a username and password (and maybe which desktop environment you want to run, etc.). Or, if you've set things up for autologin, it runs without you ever having to see it (just like in Windows). * GConf (no KDE equivalent) is a preferences warehouse, like the Windows registry. If you've never run regedit, you can probably ignore this. * ESD (or ARtS, for KDE) is a sound server. This lets you handle sound over the network, just as X lets you handle graphics over the network. It also lets old apps that try to monopolize the soundcard work together properly. You may have noticed on Windows that some programs take over the soundcard and nothing else can make any noise, but that this is less true with modern software. The same situation holds in Unix. Plus, like Windows XP, FreeBSD has some tricks to make old software cooperate (sysctl hw.snd.pcm0.vchans). And often, it's not a big deal anyway. So often a sound server is not necessary for local use (and
Re: why is it known as unknown
On Wed, 2003-10-29 at 13:33, M.D. DeWar wrote: for curiosity and exciting dinner banter, why is it I see programs/application etc referring to FreeBSD as i386-unknown-freebsd4.8 system or when doing a configure it shows as that ? The short answer is that 'unknown' means that the applications were compiled to run on (almost) any i386-based platform. If that's not enough of an answer, read on. In most cases, you're seeing what your development tools saw as the target when building the software you're running. So, you're running software (including FreeBSD itself) that was built to run on an 'i386-unknown-freebsd4.8' system. This string is in the format 'cpu-platform-os[-kernel]'. So, the 'unknown' is the hardware platform. There are different i386-based hardware platforms--the 'pc98' platform, for example. But the vast majority of i386 systems out there follow the loosely-defined, de facto PC standard. Knowing that you're building for an 'i386-pc' doesn't tell you much more than 'i386-unknown'. Basically, whenever software for 'i386-pc98' and 'i386-pc' would have to be different, 'i386-pc' doesn't tell you enough anyway. Fortunately, the target string usually gets matched up against a wildcard string like 'i386-*-freebsd*' or 'i*86-*-*bsd*'. So, 'i386-unknown-freebsd4.8' will match the same things as 'i386-pc-freebsd4.8' anyway. So, most of the code you run is going to be for 'i386-unknown', and code that you build locally will probably end up targetted at that platform as well. The same isn't true for all platforms. For example, since a DECstation and an SGI box are quite different (and in consistent, meaningful, and important ways), even though they both use MIPS processors, it's reasonably common to distinguish 'mips-dec-*' vs. 'mips-sgi-*'. Now you're probably wondering where the '[-kernel]' part comes in. After all, there's only one possible kernel that FreeBSD 4.8 could be running on--the FreeBSD 4.8 kernel. Same for Ultrix or Irix (you'll see something like 'mips-dec-ultrix4.1') or any other Unix, right? But linux isn't an OS, it's just a kernel, so you can't have 'i386-unknown-linux' or 'mips-sgi-linux', or rms will sing at you. The OS that you get when you buy/download Redhat Linux or Mandrake Linux is not linux at all, but GNU/Linux--the GNU operating system running on top of the linux kernel--which is compatible with GNU/Hurd--the GNU operating system running on top of the HURD thingy. So, in either case, you should have 'i386-unknown-gnu'. It's a pity about all that old code that checks for 'i386-*-linux' because GNU/Hurd didn't actually exist until recently (assuming you'd call 2006 recent), but what can you do? Unfortunately, GNU/Linux and GNU/Hurd aren't actually compatible in real life, so 'i386-*-gnu' doesn't really help--you need to distinguish between linux and HURD as often as between linux and FreeBSD. For that reason, you have 'i386-unknown-gnu-linux' or 'i386-unknown-gnu-hurd'. And you can then check for 'i386-*-gnu-linux' (plus, 'i386-*-linux' still works). Actually, some tools say 'i386-unknown-gnu-linux2.4.18', just like 'i386-unknown-freebsd4.8', so you really want to check 'i386-*-linux*', just like 'i386-*-freebsd*'. Not that this contradicts the fact that any other Unix only has one kernel to worry about (GNU's Not Unix), but since most Unix programs are built for linux as well (and vice-versa, fortunately, considering where the hype), it affects Unix anyway. If you want to know more about any of this... well, I'm not sure where all the information is, although there is a ton of it. Start by skimming the info pages for autoconf, I'd guess. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: stop the desktops' upgrades
On Wed, 2003-10-29 at 17:01, .VWV. wrote: Hello to all. OK, this is probably a troll (and I notice that it was composed on Outlook Express--I'm guessing not running under WINE), but I'm going to answer it anyway I'm happy for the new release. Otherwise, in my opinion it is necessary to stop this unuseful adoption of the endless upgrades of KDE and GNOME monsters. They still are much better than WIN. Sure, I'd agree that they're both better than Windows. But that's a relatively recent (say, GNOME/Gtk+ 2.0 and KDE/Qt 3.0) development. So, now that they've caught up to Windows, does that mean they should stop? Is the goal to make Unix as good as Windows, or to make it as good as it can be? There is no stable standard for applications' developers, under such environments. GNOME/Gtk+ 2.x is a stable standard. So is KDE/Qt 3.x. I can count on the fingers of one hand how many apps, tools, etc. out there still require GNOME 2.0 or 2.2, or KDE 1.x or 2.x, support. The only exception was the changeover from GNOME/Gtk+ 1.2 to 2.0 (which is why there is still Gtk+ 1.x stuff lying around). As an application developer, I can tell you that upgrading from GNOME 2.0 to 2.2 to 2.4 is pretty much equivalent to going from Win2K to WinXP: Usually, you don't have to do anything. Sometimes, you have to recompile. Occassionally, you have to rewrite a bit of code. Some new features require new code to take advantage of them; some don't. In other words, I don't see the problem you're worried about. After the failure of Motif, I always suggest the adoption of the stable Tcl/Tk for the most important projects. It is necessary a bit of 'peace'. The reason people don't use Motif, even though it's now open, is that it's not very good. The fact is, it's much easier to slap together a GUI for a Python app in Gtk+ than in Motif, and it's also easier to build a powerful, polished GUI in Gtk+ than in Motif--and it'll look better and may even be more functional. And the same is true with Tk. Both Motif and Tk are ugly (and non-themable). Neither provides all the widgets that an application developer is likely to want, and neither makes it as easy to customize widgets, or build new ones out of existing ones. Neither has anything as nice as glade (or MSDev) for rapid GUI development. Also, Motif and Tk are only widget toolkits (like Gtk+ and Qt--and even at that level, they don't proide as much). Neither provides auxiliary libraries like pango, gconf, libxml, etc. And of course neither provides any way to interact with the desktop (e.g., putting up a taskbar notification icon). In short, unlike GNOME and KDE, neither Motif nor Tk is as good as Windows--for users or for developers. As for the upgrades, in addition to the new and improved widgets and tools for developers, there's also the fact that KDE and GNOME keep getting closer together (which is very important to application developers). And don't forget the user applications, sysadmin tools, etc. that are part of KDE and GNOME. For just one example, I think Evolution is the best mail client out there, and kmail is a close second--but a year ago, neither was as good as Outlook Express. My suggestion is that the developers of any project use whichever toolkit they like best that provides the features they need. For me, that's almost always Gtk+ (with or without GNOME), but if you prefer Motif or Tk, well, go ahead. Stop upgrading, keep a working desktop - stop the fashion system! Well, X11R4 worked for me years ago, but I'm certainly glad I'm not still using that. I'm also glad I'm not using GNOME 1.x anymore. (And I can tell you that upgrading from GNOME 1.2 to GNOME 2.0, much less 2.2 to 2.4, was much easier than going from fvwm2 to enlightenment.) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: tar question...
On Wed, 2003-10-29 at 19:56, Xpression wrote: Hi list, the question is: can I tar a hole directory without include the tree ??? I mean when I tar all files in a /dir1/dir2/dir3 path, the tar file includes me the path too and I want to tar only the filenames in dir3: I'm using the syntax tar -czf /path/to/store/myfile.tgz /the/path/where/are/the/files, any clue Thanks... I'm not 100% sure I understand exactly what you want, so I'm going to be extra careful; I apologize if it sounds like I'm talking down to you. The short answer is to use relative paths: cd to where you want to start, and tar from there. If that doesn't immediately answer your question, read on. Let's say your directory structure looks like this: dir1 dir2 dir3 file1 file2 dir4 file3 You want a tarball that contains 'dir3', 'dir3/file1', 'dir3/file2', 'dir3/dir4', and 'dir3/dir4/file3', right? If so, do this: # cd /dir1/dir2 # tar czf /path/to/store/myfile.tgz dir3 If you instead want a tarball that contains 'file1', 'file2', 'dir4', and 'dir4/file3', instead do this: # cd /dir1/dir2/dir3 # tar czf /path/to/store/myfile.tgz * You can do this all in one command with the -C parameter, but it's easier to remember cd than how -C works (globbing gets more complicated, -C works differently on different platforms/tars, and there's extra stuff to worry about if you use it together with -T). If you only want 'file1' and 'file2', and not 'dir4' or any of its contents, do this (the 'n' means to not recurse into subdirectories): # cd /dir1/dir2/dir3 # tar czfn /path/to/store/myfile.tgz * If you want 'file1' and 'file2' and 'file3' but not 'dir4', there's no simple way to do this. You'll have to do something like this (the 'h' means to dereference symlinks and store the original file they point to): # pushd `mktemp -dt tar` # ln -s `find /dir1/dir2/dir3/` ./ # tar czfh /path/to/store/myfile.tgz * # rm -rf `pwd` # popd This isn't perfect (it won't work if there are too many files, and if any of the original files are symlinks they'll be dereferenced too--and if you plan to do this more than once you'll be better off writing a script that wraps this stuff up), but it should give you an idea. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
ATI video questions again
I already asked some of this before, so I apologize. If anyone here doesn't know the answers, but does know where I should go to ask, that would be just as helpful. I have a Mach64 video card (a 3D Rage IIc rev 7a), and I can't get Xv or DRI to work under FreeBSD. I'm using the XFree86-Server-4.3.0_11 port under FreeBSD 5.1. With the XFree86 4.3 packages from Mandrake 9.2, Xv and DRI work fine. Looking at my XFree86.0.logs, I've seen three different things that might indicate the problem, but I don't know which it is, or where to go from here. First, after loading ati_drv.o, whhen it tries to initialize the driver, it goes through the R128 and RADEON drivers only--no Rage/Mach64. Maybe this is the problem? Is FreeBSD's XFree86-Server port missing/disabling the ati.2 drivers? (And yet I see the message For information on using the multimedia capabilities of this adapter, please see http://gatos.sf.net.;, which I think came along with the ati.2 driver?) Second, when initializing the driver atimisc_drv.o, I get the following messages in FreeBSD: (==) ATI(0): Write-combining range (0xa,0x2) was already clear (==) ATI(0): Write-combining range (0xc,0x4) was already clear (II) ATI(0): Primary V_BIOS segment is: 0xc000 (==) ATI(0): Write-combining range (0x0,0x1000) was already clear I get no such messages under linux. However, when I first upgraded to 2.4.22, I got the following messages (and no Xv or DRI, and X slowed to a crawl, too)--which went away (along with the problems) when I fixed the broken ServerWorks code in the kernel: (==) ATI(0): Failed to set up write-combining range (0xa,0x2) (==) ATI(0): Failed to set up write-combining range (0xc,0x4) So, maybe there's a similar problem in FreeBSD causing similar issues? Third, when initializing the vbe sub module, I see this: (II) ATI(0): VESA VBE DDC supported (II) ATI(0): VESA VBE DDC Level none (II) ATI(0): VESA VBE DDC transfer in appr. 2 sec. (II) ATI(0): VESA VBE DDC read failed (==) ATI(0): Write-combining range (0x0,0x1000) was already clear (==) ATI(0): Write-combining range (0xa,0x1) was already clear (==) ATI(0): Write-combining range (0xfe101000,0x1000) was already clear Something is obviously wrong here. Besides the write-combining stuff appearing again (and again, in sub module fb), there's that VBE DDC error (and the fact that all of the results are missing, of course). The equivalent in linux is: (II) ATI(0): VESA VBE DDC supported (II) ATI(0): VESA VBE DDC Level 2 (II) ATI(0): VESA VBE DDC transfer in appr. 2 sec. (II) ATI(0): VESA VBE DDC read successfully (II) ATI(0): Manufacturer: OQI Model: 4a32 Serial#: 1097 ... I have no idea where to go from here (short of tramping through megabytes of XF86 code...). Can anyone help? Thanks. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Linux port.....
On Mon, 2003-10-27 at 05:08, Andrew Humphries wrote: On Mon, 2003-10-27 at 13:51, C. Ulrich wrote: On Sat, 2003-10-25 at 00:43, andi payn wrote: 4. While running a similar set of services, FreeBSD may be using less background processing time. Or maybe not. I definitely see significantly lower CPU usage (idling under X, FreeBSD shows about 2-10% CPU, linux about 15-35%). However, this may just be an artifact of linux's notoriously bad reporting, or the fact that I'm using the O(1) kernel and preemptible kernel patches, or maybe something stupid some GNOME applet is doing because I configured it wrong under linux; who knows Check with top to see which processes are using the CPU. Keep in mind that top is gathering information from the same proc filesystem as gtop, GNOME's system monitor, etc., so it's no more accurate than they are. And, as I mentioned, there are well-known issues with this reporting. For me, 9 times out of 10, it's the X server itself taking up cycles for doing nothing. But for me, 9 times out of 10, the X server is grabbing lots of idle time but won't steal time away from processes that actually need it. This may prevent a laptop CPU from going into low-power mode, but it doesn't affect anything else--even nice 20'd processes run. With a patched kernel, this can get even more extreme (like the interactive kernel patches, which will throw bonus timeslices at X, nautilus, and some other processes): I've seen X using supposedly over 90% of my CPU--and then started a compile, and X immediately dropped to under 10%--and everything remained responsive throughout. Even without unofficial patches, remember that the linux scheduler has been hacked at and even continually rewritten a few times in recent years, so what you see with one version may not be the same with another. However, you may have a memory leak. When I upgraded a Redhat 6 box to XFree86 3.3, I had exactly that problem (IIRC, it ultimately had to do with a bug in the version of gcc that Redhat was distributing)--after a while, X was using 90% of my CPU for real, and sucking up a few hundred megs of memory to boot, and the system slowed to a crawl. (Even then, I just had to kill X; I didn't need to restart.) This is why I said, FreeBSD may be using less background processing time. Or maybe not. Linux sometimes doesn't give you enough (or accurate enough) information to know whether it's wasting your CPU. So, it certainly appears to be more wasteful than FreeBSD, but it may not actually _be_ more wasteful. As a test, rebuilding mozilla takes about the same amount of time under both systems (FreeBSD 5.1 vs. Mandrake 9.1 with kernel 2.4.21 with the preemptible patch). It won't do it right after a fresh boot, but some program along the way usually triggers the siphoning of the CPU usage. I have found this an awful lot whilst running X under Linux. After a fresh boot, with nothing running, it works nicely. Give it a couple open applications, and even when nothing is running except X itself, it will take up extra CPU time and physical memory space until freshly booted again. If this isn't getting too off-topic, what distro, kernel, and X are you using? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How does one record audio?
On Sun, 2003-10-26 at 08:02, RexFelis wrote: I am using FreeBSD 5.1-p10, and recently I have need to record spoken sounds. As DavidB said, the fact that it no longer works in linux implies that you might have a hardware problem--with the sound card, or even with the mic. (Is this the same mic you used in linux? Otherwise, it may just be something simple, like impedance or preamping.) However, there's one more easy possibility to check: Make sure the mic isn't muted. From aumix, or your favorite oss mixer app (I think this is what kmix is, if I remember correctly), and check/play with the level and mute settings for mic, record, line in, or anything else that looks like an input. In addition to the level and mute settings, you may also see a record source setting--with most setups, you can select exactly one recording source, so try selecting each of them in turn; with others, each one can be turned on and off separately. You may also have a master record level and mute setting to play with. While you're at it, see if you can record from the CD (through the soundcard, assuming you have an audio connection--generally a little 2-pin cable--between the two; digital CD audio extraction won't tell you anything useful). You may also want to look at the sysctl settings to see if anything looks fishy. Try sysctl -a |grep snd to look at what knobs you have and what they're set to. I've noticed that when I have hw.snd.pcm0.vchans set to anything 1, this sometimes interferes with audio input (but then I'm not sure my ancient fm801 is full-duplex). If fiddling with the mixer and sysctl produces no effect, you're probably best testing either in Windows, as DavidB said, or with a clean copy of linux (maybe even use a different distro). By the way, if you're not sure which sound card you have, use lspci (/usr/ports/sysutils/pciutils--or run the binary from your linux distro, or reboot to linux) and it should tell you something like this: 00:04.0 Multimedia audio controller: Falcotronic, Inc Komissar 2000 [CHA] (rev b23) This implies (though it doesn't guarantee) that the driver you need is snd_cha--and it provides enough information that some helpful soul can tell you exactly which driver you need. However, most likely this won't help; if the sound output is working, the correct driver is probably already being loaded as a module (scan kldstat's output for snd_*.ko). ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Linux port.....
On Fri, 2003-10-24 at 14:44, Alessio Caffi wrote: dear FreeBSD team: I am a new user to both Linux and FreeBSD. I installed both system (4.8 and slackware 9) under VMware for windows they are working ok. Before parting my HD and do a real installation , without VMware emulator. I am interested to know which of one runs faster. What about Linux program under FreeBSD, will they run slower or same speed as native Linux OS. The short answer is that most linux programs run at about the same speed under linux and FreeBSD. Running linux software on FreeBSD is also about the same speed as recompiling the source for FreeBSD native. This is what you'd expect, and this is _usually_ what you get. There are a few exceptions (all of which have nothing to do with the linux emulation, but which will still affect you). I should mention that I'm certainly not an expert--until the past few weeks, I hadn't used a BSD operating system in years. Also, I'm using FreeBSD 5.1 vs. various Mandrake versions, and (briefly) Redhat 6.2 and 8.1. But I can offer some observations from my (limited) experience. 1. Multimedia may be much slower on FreeBSD, if you have hardware for which acceleration is either non-existent or harder to get working on FreeBSD. On my ATI Rage, for example, I can't get DRI, or Xv, or vidix working on FreeBSD. This means that full-screen games, OpenGL apps, mplayer, etc. all run very slow on FreeBSD. If you don't have hardware for which this is an true, or don't plan to do much multimedia/gaming, this won't affect you; otherwise, it's a huge difference. 2. UFS seems to write significantly faster than ext3 in some cases. Things like squid proxies, mail servers, web browsers, GNOME programs that do too much gconf'ing, etc. seem noticeably faster in FreeBSD. This only matters if you spend a lot of time running apps that don't play well with ext3 (in which case you should be usin Reiser, XFS, or whatever's best for your usage in linux anyway). 3. FreeBSD's swapping may also be smarter or faster. Or maybe not. I know that, e.g., working with gigantic files in gimp seems to be a little faster than under linux, and the memory-leak bug in SMAC doesn't make the game slow to a crawl quite as quickly. This may be a consequence of /tmp, etc. being on UFS, or something completely different. 4. While running a similar set of services, FreeBSD may be using less background processing time. Or maybe not. I definitely see significantly lower CPU usage (idling under X, FreeBSD shows about 2-10% CPU, linux about 15-35%). However, this may just be an artifact of linux's notoriously bad reporting, or the fact that I'm using the O(1) kernel and preemptible kernel patches, or maybe something stupid some GNOME applet is doing because I configured it wrong under linux; who knows CPU-bound processes certainly don't seem to run a whole lot faster (as they should, if this were something real). Other than these cases, for the most part, I haven't seen much speed difference with linux apps--or ports to FreeBSD. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Migrating from Linux: mounting ext2fs
On Wed, 2003-10-22 at 07:03, Miguel Gonalves wrote: How stable is the FreeBSD support for ext2fs? First, if you're planning to migrate your server permanently, you're probably better off reformatting in UFS: it's faster, and better for error recovery. And computers that mount nfs/Samba/whatever shares won't know the difference. If you insist on keeping your partitions in ext2fs: I've seen a couple of problems related to fsck. In particular, when a filesystem is dirty, fsck.ext2 sometimes finds and fixes the problems but then fails to mark the disk as clean (meaning that FreeBSD will refuse to mount it, if you've specified read/write, and it'll be checked again next time you reboot, and so forth). Personally, I've only seen this with ext3 (journaled) filesystems, but I don't know if that's universal. So, to be safe, you'll probably want an rc script that mounts -r any of your ext2 systems that were skipped. (Note that if /mnt/linux fails to mount because it was dirty, /mnt/linux/usr, etc. will also fail to mount.) This way, if the server gets hard-reset somehow, your users will still be able to access their files, even if they aren't able to update them, until you fix things. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
