A few questions from a current linux user
Krishna Mohan Gundu
gkmohan at gmail.com
Mon Aug 11 11:15:09 UTC 2008
First of all, let me thank everyone who has responded to my questions
on this mailing list.
> I've been meaning to respond to this post for a couple of days, but it
> took me a little longer than I originally hoped...
Thank you for taking time to write a detailed response.
> This may be totally unrelated to the real question, but doesn't Fedora
> use pre-compiled packages by default? I thought that was pretty much
> the One True Way(TM) of updating Fedora systems.
Yes it is. I have friends who are happy doing dist-upgrades with one
command. But I have been using Fedora from the beginning and I have
had a few bad experiences with distribution upgrades leaving me to
spend more time fixing the problems. I have decided not to risk
upgrades after Fedora Core 4 and two years down the line I think it is
a good decision with a few side effects, mainly keeping pace with
newer versions of packages of interest.
>> 1) Is a feature similar to magic SysRq in linux necessary for FreeBSD?
>> (As I understand there is no such feature in FreeBSD)
> Not really. SysRq has a few nice characteristics, i.e. it can unmount
> local filesystems gracefully to avoid `fsck' runs during the next boot.
> It's a nice, handy tool in some cases. But it also comes at a cost: it
> modifies the in-memory state of the running kernel.
> FreeBSD has a kernel debugger that can be enabled, called DDB. When the
> kernel locks up or panics because something bogus happened, the DDB can
> dump the state of the kernel into a preconfigured swap area, and the
> startup scripts of the next boot will pick up the kernel coredump from
> swap, save it in `/var/crash', and let you run post-mortem analysis on
> the kernel core dump.
> If this is combined with something like SysRq, and there's really a bug
> in the parts of the kernel that SysRq has to use to perform its final
> steps, you lose. You may be modifying the parts of the kernel memory
> that actually exhibit the bug, and make the kernel dump unusable.
Should one risk losing the data or should one be able to debug
reliably? I think letting the user decide on this option is a better
solution than not implementing SysRq at all. But after reading the
mailing lists, I got a feeling that most experienced FreeBSD users
don't really need the SysRq feature. However I still don't understand
how the data is safe even if one enables SoftUpdate with disk caching
>> 2) Is it possible to compile multiple versions of gcc? If so what is
>> the best way to do it?
> Yes, of course.
> The "base system" of FreeBSD includes _one_ version of gcc, installed as
> `/usr/bin/gcc', but this does not mean that you are limited to *that*
> version only. You can use the Ports tree to install one or more
> versions. The snapshot of Ports I have on the laptop I am using to type
> this includes 12 different gcc ports (and that does not include the
> Fortran, Objective C, or Java backends GCC supports):
> # pwd
> # ls -ld gcc* | nl
> 1 drwxr-xr-x 3 root wheel - 512 Jul 17 03:01 gcc-ooo
> 2 drwxr-xr-x 3 root wheel - 512 Jul 17 03:01 gcc28
> 3 drwxr-xr-x 3 root wheel - 512 Jul 17 03:01 gcc295
> 4 drwxr-xr-x 3 root wheel - 512 Jul 17 03:01 gcc32
> 5 drwxr-xr-x 3 root wheel - 512 Jul 22 05:03 gcc33
> 6 drwxr-xr-x 3 root wheel - 512 Jul 29 04:46 gcc34
> 7 drwxr-xr-x 3 root wheel - 512 Jul 17 03:01 gcc41
> 8 drwxr-xr-x 3 root wheel - 512 Jul 17 03:01 gcc41-withgcjawt
> 9 drwxr-xr-x 3 root wheel - 512 Jul 22 05:03 gcc42
> 10 drwxr-xr-x 3 root wheel - 512 Jul 17 03:01 gcc42-withgcjawt
> 11 drwxr-xr-x 3 root wheel - 512 Jul 29 04:46 gcc43
> 12 drwxr-xr-x 3 root wheel - 512 Aug 7 02:25 gcc44
> So yes, you can install several different versions of GCC at the same
So I believe each gcc port keeps track of various dependencies and
their versions for a chosen gcc version. However if I need gcc40 (lets
say, not available from ports) or if I need to enable certain features
that ports disable then I guess I am on my own in that there are no
guarantees that it will compile.
>> 3) Is it possible to perform a binary update from one release to
>> another? If so can you please point me to the documentation? How are
>> config files updated in this case? (Could not locate documentation on
> Yes. In recent FreeBSD releases, the "base system" of FreeBSD includes
> freebsd-update. This is a utility authored by Colin Percival, who is
> currently the Security Officer of FreeBSD, and a very smart fellow :)
> What freebsd-update does is described in its manpage
> but the basic idea is that is can do one of the following things:
> * Download binary update packs in `/var/db/freebsd-update'. These
> are not installed immediatelly, so you can periodically pull the
> binary update files and install them later, when you have the time
> for an upgrade.
> The default `fetch' mode of `freebsd-update' downloads binary
> updates for the release & branch of FreeBSD that you have
> installed on the local system. Staying on the same branch has
> various advantages that are nicely described in the online article
> about `
> * Download binary update packs for _upgrading_ to a new release.
> This is slightly different from an update that sticks to a single
> FreeBSD release-branch, and there are official release notes about
> the changes of every major release. They are published online at
> Downloading the binary packs for new release still does *not*
> install or upgrade anything.
> * The final important feature of freebsd-update is that it can use
> the latest snapshots you have fetched in `/var/db/freebsd-update'
> to perform a binary upgrade of the FreeBSD base system.
Coming from linux background, the different way of managing base
system and ports bothers me. I understand the reasons behind the
division but not the necessity to manage them differently. For example
how would I know if a package is in the base system or not? Looks like
for ports this can done with 'make search name=whatever'. Is there an
equivalent of freebsd-update for ports?
>> 4) If a binary update leads to an unstable system, how easy it is to
>> backtrack to an earlier working version along with working config
> That's probably not very easy. But freebsd-update is not really going
> to pull `unstable' stuff because of the way FreeBSD branches work. If
> you are following a ``FreeBSD-X.Y-STABLE'' release branch, it is pretty
> much a given that the source tree should build at all times, and that
> the resulting base system should be backwards compatible with all the
> binary programs that were produced in any version between the time
> ``FreeBSD-X.Y-RELEASE'' was cut and your -STABLE snapshot was built.
Debian seems to do a reasonable job in simplifying rollbacks. However
they clearly point out that things like modifications to databases on
upgrage are very unlikely to be revertible. They have a nice way of
upgrading and doing a rollback on configuration files.
> Having said that, of course, using some sort of backup tool is never a
> bad idea. Even if freebsd-update does nothing to harm your FreeBSD
> installation, there are hardware failures, power outages at the worst
> possible moment, fat-fingered commands that remove or change slightly
> more files that originally intended, and so on.
Yes, of course.
>> 5) Does FreeBSD have support for PCMCIA-USB cards?
> Yes, FreeBSD supports PCMCIA (PC-CARD or Cardbus) and USB devices.
> FreeBSD includes drivers for various devices of these two types, but
> before buying a PC-CARD device you should always check to see if there
> is a `high level' driver for the one you are buying. The generic
> PC-CARD, Cardbus and USB layer of the FreeBSD kernel supports the common
> `base functionality' of attaching and detaching a device, but to get any
> random device to work you need a driver that recognizes it and attaches
> to it.
> This is a long way of saying that ``Yes, we have PCMCIA and USB support
> in the kernel, but you should first check the hardware compatibility
> lists and the manpages of your system to see if a particular device is
> supported at all, partially supported, or completely unsupported''.
> This may be tricky if you can only get hold of the device *after* buying
> it and unpacking it, but I've had various levels of success by asking at
> computer stores for a ``local test'' with my laptop. In some of the
> local places, I've had *very* helpful responses. The local sales people
> have often told me "We don't have an unpacked version of *that* today,
> but if you can wait until Monday, we are getting a new delivery. When
> we unpack a sample / demo of this particular card/adapter/gadget, you
> can definitely try it and see how things work."
Unfortunately I already have a card, I will have to try my luck.
However your idea of taking a device for a test run seems to be a good
>> PS: I am considering Debian as another alternative.
> Debian is a Linux distribution. A very good one too. If that fits your
> job better than FreeBSD does, it's definitely not a shame to use it.
> FreeBSD will still be around if you need it later :-)
Over the last two days I had a very good experience of installing
FreeBSD on one of my disk partitions. Unfortunately the installation
did not go smooth at all. The installation disk itself would stop
short of running sysinstall. But the best part was the documentation
and configurability. I am amazed at what one can do from the FreeBSD
boot prompt, sysctl is amazing.
I will try the Debian system as well. It seems like they share a few
strengths. But if cross compiling works on FreeBSD out of box that
would be icing on cake for me.
> Finally, since you are coming from a Linux background, you should spend
> some time to check out the excellent documentation FreeBSD contributors
> have written over the years. There are lists of books and articles at
> You should probably start with some of these:
>  "The FreeBSD Handbook"
>  "The FreeBSD FAQ (Frequently Asked Questions)"
>  "Choosing the FreeBSD Version That Is Right For You"
>  "Explaining BSD"
>  "FreeBSD: An Open Source Alternative to Linux"
>  "FreeBSD Quickstart Guide for Linux Users"
>  "FreeBSD First Steps"
FreeBSD documentation is incredible. The handbook has been like a
bible for me so far, but I also took a peek into architecture handbook
to read about device drivers.
More information about the freebsd-questions