Results tagged “Fvwm” from CLICK

I've been using OpenBSD for a few months now, and one of the problems I've had is the inability to find the master configuration file for .fvwmrc. I've read the man page for fvwm but didnt' read it closely enough. The answer was there all the time.

I've grown quite fond of the Fvwm window manager. These days I prefer it to Fluxbox, even, and I have OpenBSD to thank for introducing me to it. (Note: I didn't have the same feeling about Twm, the default window manager in FreeBSD. Even though Fvwm is based on Twm, the former is way, way better than the latter.)

I, for the life of me, couldn't find the master Fvwm configuration file. As the man page said, the .fvwmrc file in the user's home directory is the first place Fvwm looks for its configuration file. That enables every user on the system to have his or her own customized desktop. If ~/.fvwmrc is not present, then the window manager looks in /usr/X11R6/lib/X11/fvwm/ for a configuration file.

Here's where I didn't read closely.

I plainly see system.fvwm2rc, system.fvwm2rc-sample-1 and system.fvwm2rc-sample-2. Changes made in any of these three do not change the default Fvwm configuration. Copying any of these three into your home directory as .fvwmrc does provide a usable Fvwm configuration file, but they're all radically different than the default version, which I prefer for a number of reasons; the people rolling OpenBSD out for us are very good at what they do.

But where -- WHERE? -- is the master Fvwm configuration file? Read the man page more carefully:

During initialization, fvwm will search for a configura- tion file which describes key and button bindings, and a few other things. The format of these files will be described later. First, fvwm will search for a file named .fvwmrc in the user's home directory, then in ${sysconfdir} (typically /usr/X11R6/lib/X11/fvwm). Fail- ing that, it will look for system.fvwmrc in ${sysconfdir} for system-wide defaults. If that file is not found, fvwm will be basically useless.

I always did a standard ls command while in /usr/X11R6/lib/X11/fvwm. That didn't give me the dot-files. Doing ls -a shows the dot-files, too, and I see that there is a file called .fvwmrc in /usr/X11R6/lib/X11/fvwm/.

Problem solved.

I made a copy of the original /usr/X11R6/lib/X11/fvwm/.fvwmrc file so I'll always have it in its original state. Now I can copy it into my home directory as .fvwmrc and have only my own account's configuration set by it, or I can, as root, modify /usr/X11R6/lib/X11/fvwm/.fvwmrc and have the window manager configured the same way for all users who don't have their own .fvwmrc in their home directories.

Note: Make sure you copy .fvwmrc over to your user account while logged on as that user and not as root. Otherwise you won't have write privileges in your own .fvwmrc file. I only know this because I did it that way. I used sudo (I gave myself sudo privileges awhile ago) to copy .fvwmrc as temp.fvwmrc (call it whatever you want), and then made a copy as .fvwmrc instead of monkeying around with the permissions:

$ sudo cp .fvwmrc temp.fvwmrc
$ sudo rm .fvwmrc
$ cp temp.fvwmrc .fvwmrc
$ sudo rm temp.fvwmrc

Remember, you only have to do this if you screwed up like me. If you make the backup of /usr/X11R6/lib/X11/fvwm/.fvwmrc as root, then copy the /usr/X11R6/lib/X11/fvwm/.fvwmrc file to your home directory as your user, all the permissions will be right as the proverbial rain.

Fun facts from the fvwm man page:. While Fvwm comes configured with nine virtual desktops, you are free to add more. But how many can you have? "Approximately 4 billion," says the man page. Also, Fvwm is extremely flexible. Just about every parameter can be adjusted by the users -- hence Fvwm can be whatever you want it to be, only limited by your knowledge of the program and the time you have. One thing that's great is the ability to configure where on the various desktops (and where exactly on each individual desktop) a given application will launch, as well as exactly how big a window the application will open in.

Flexible, powerful and efficient. That's what OpenBSD and Fvwm are all about.

I haven't begun to scratch the surface yet, but I now have a Fvwm configuration to begin with that I like (the default one) much better than the other samples provided in the system. Again, thanks to the entire OpenBSD team for rolling out such a fine OS.

An observation: Deciding to use OpenBSD as a desktop operating system isn't a slam dunk in any way. While the quality of the system is high, and the security aspects -- most designed to protect servers -- are very much attractive on the desktop, using the stable version of OpenBSD isn't at all like running Debian, Ubuntu, Slackware, or even FreeBSD.

Every six months, the OpenBSD team issues a "stable" release -- now version 4.2, with 4.3 coming out in May. In the interim, you need to monitor the security mailing list or check the errata on the Web site for possible problems with the base system. As far as applications go, the binary packages are generally not updated at all between releases. And there's really no mechanism in OpenBSD to do periodic updates of precompiled binary packages. So if you're used to getting a new version of Firefox every couple weeks or so, it's not going to happen.

Some would argue that OpenBSD's difference from most other operating systems, and its emphasis on security, makes it less vulnerable to things such as Firefox breaches. I can't really say whether or not this is true. And the OpenBSD team encourages users to install the -current branch instead of -stable. -Current is updated all the time, but such updates require users to continually compile the source updates into executable binaries for your system.

It's not all that difficult, but it can be time-consuming. My short experience using ports in FreeBSD made me, at first anyway, wonder how long I could stand all that compiling, especially when it's so much quicker to download and install a precompiled package, if your architecture has the package you need. I know that many architectures in OpenBSD, FreeBSD and NetBSD have few, if any binary packages, and everything must be installed from ports.

There's a bit of a tempest brewing on the OpenBSD mailing lists right now over whether users of OpenBSD -stable (i.e. 4.2) are subjecting themselves to undue risk by running Firefox 2.0.0.6 instead of 2.0.0.13 or wherever it's at right now. Users of -current can roll in the newer version from ports. Again, since I'm running 4.2-stable, I haven't done it.

And again, I don't know exactly how necessary it is to do all of these updates in OpenBSD. I do know that I will install 4.3 when it comes out, and for awhile at least, I'll have more up-to-date packages all around. And I'll probably take the plunge eventually and install -current.

One more thing: I've been doing a few tests, and OpenBSD is a bit slower on the desktop than, say, Debian and Ubuntu. Once again, I have no idea why. But the added security and stability of OpenBSD, as well as its overall quality, gives the user something in exchange for somewhat slower performance. OpenBSD is certainly not as quick as Slackware, but OpenBSD starts out in much better "shape" as far as the default configuration goes -- for me anyway. The package management in OpenBSD makes it much easier for me to customize my system than does Slackware. In OpenBSD, there are over 4,000 packages for i386 in the repositories, and dependencies are taken care of. While I can grab packages and figure out the dependencies, or use Slackbuilds for Slackware, it's a much more time-consuming process. Of course Debian has apt, and a barebones installation can be quickly built up.

It all depends on what floats your geekish boat. And for now, it's a combination of Debian and OpenBSD, with a smattering of Ubuntu on the side. And I've still got one Wolvix Hunter 1.1.0 installation that I enjoy using. Wolvix manages to take a Slackware 11 base and add all the applications that I like to use, while taking away all the KDE stuff -- including the KDE desktop itself -- that I really prefer not to have on my system. Wolvix's Xfce/Fluxbox combo is much better equipped than plain Slackware, which also has Xfce and Fluxbox but doesn't have enough non-KDE apps to make the lighter desktop usable.

For now I'm having a lot of fun with OpenBSD. Figuring out how the ACPI works for my Gateway laptop's CPU fan would be a major step forward for me, but I fear I will never get there. That's why I'm running only Linux on the $0 Laptop. In Linux, I've got fan management down pat. In FreeBSD it's pretty flaky, and in OpenBSD, I have no idea where to begin. Since the $15 Laptop (Compaq Armada 7770dmt) doesn't have ACPI, it's the perfect machine on which to run OpenBSD, and that's exactly what I'm doing. The same goes for my VIA C3 Samuel-based test box. I'd love to tame the laptop with OpenBSD, but I just don't think I'll ever get there.

While I was all set to slap the Ubuntu 8.04 beta on the $0 Laptop (the Gateway Solo 1450 with 1 GB of RAM), I had the FreeBSD 7 install CD already burned ... and while it didn't work so well on the $15 Laptop (Compaq Armada 7770dmt), it booted right up on the Gateway.

After a few OpenBSD installs, during which I followed the well-written FAQ religiously (and as a result had no trouble whatsoever), I felt I was more than ready to throw FreeBSD on the laptop.

And while the FreeBSD Handbook is legendary for its comprehensiveness, I figured I could just fly by the seat of my proverbial pants.

And so I did.

Things were going well before I did a thing: the FreeBSD 7 installer automatically managed the Gateway's CPU fan. I'm able to get most Linux distros to do this with some easy configuration work once the install is done, but I have no clue whatsoever how to accomplish this very task in OpenBSD and NetBSD, no matter how hard I've tried. But having FreeBSD do it automatically is a great thing, indeed.

Once in fdisk, I deleted the PCLinuxOS partition and replaced it with one for FreeBSD. I created a 500 MB swap "slice," then one big slice for the rest. I followed the instructions for the rest of the install.

I chose the generic "user" array of packages, along with X, and once I went through all the menus and the system was installed from the first CD (I didn't bother to download or burn the ISOs for discs 2 and 3).

The last time I tried a FreeBSD install -- quite some time ago -- I chose a whole bunch of packages (or was it ports?) for my default install, and my partition ran out of space before the whole thing finished.

So this time I figured it would be better to start with the basic install and X. After using OpenBSD with its basic install (Fvwm window manager, Lynx browser ... and quite a bit more), I figured I could get around well enough in the basic FreeBSD install to make things happen.

After the install, I booted to a login prompt. After logging in, I did startx and found myself in the Twm window manager. I needed to test whether or not my static IP was working. I became the superuser and tried to ping google. Nothing. I pinged local machines on the network, and everything was fine.

I thought networking was broken and searched awhile for a solution.

If I even had Lynx (which is in the default install of OpenBSD) I would've tried it first, but even that text-only browser is not preinstalled.

Like I said, after awhile, I suspected that I was having trouble with ping and not with networking.

In OpenBSD, I've always installed packages, never ports, but since I opted in the FreeBSD install to download the ports tree, I figured I'd try to install my first port.

I needed a Web browser. So I started with Dillo.

This time I did consult the FreeBSD Handbook. I followed the instructions, going into the ports directory for Dillo, then running:

# make
# make install
# make clean

I read another paragraph down and learned that I could have just done:

# make install clean

At any rate, I did have Internet connectivity (despite the inability to ping Internet IPs, as root or otherwise), since files began downloading and building. In addition to Dillo itself, I needed GTK plus a bunch of other stuff. It took quite a long time -- for me anyway. The whole process lasted maybe 10 minutes. I'm used to apt-get install dillo ... and a minute later it's done.

But I do understand -- if tentatively -- the whole philosophy behind ports, and while the whole thing looks complicated, it worked perfectly.

I ran dillo from an xterm window and had a working Web browser.

I'm sure someone will enlighten me as to why this doesn't work:

# ping google.com

I imagine it has something to do with the firewall, but at any rate, I did install FreeBSD 7, I do have Internet working, I've got a browser running, and ACPI fan management and automatic configuration of X were perfect without any intervention from me.

Truth be told, it's more than most Linux installs can do.

While I couldn't imagine sticking with Fvwm in OpenBSD, I've grown quite fond of it -- I pretty much like it better than Fluxbox at this point. I'd hazard to say that I won't stick with Twm in FreeBSD, but it could grow on me in much the same way -- especially since, if I'm correct, Fvwm is based on Twm).

Final note: Why didn't I just install DesktopBSD or PC-BSD, you ask? Here's my answer: While I'm OK with running KDE, I'm not exactly comfortable with it. I really wanted to experience FreeBSD in a more, shall we say, "organic" way. After having such a good experience with OpenBSD, I see the value in building your own desktop, adding the apps you want and keeping everything a bit lighter.

If, as in the world of Linux, there was a FreeBSD-based project that allowed for an easy install with a full desktop based on Fluxbox, Fvwm, Xfce, JWM ... or even GNOME, I would be all over it. But the choices in DesktopBSD and FreeBSD (KDE and KDE, although I remember somebody telling me that DesktopBSD does install Fluxbox) don't exactly move me.

And since, like in OpenBSD, the basic FreeBSD install goes so well, I'm happy to start at the beginning.

Absolutely final word: Every time I write about a BSD project, I feel the need to praise the extensive, high-quality documentation that goes with it. The OpenBSD FAQ and man pages, the FreeBSD Handbook and man pages -- both have been and continue to be invaluable resources worth much more than their cost (which just happens to be "free"). It's one area in which the BSD projects are well ahead of their Linux counterparts, which generally feature documentation that is smaller in quantity, often out of date and lesser in quality. I wish it weren't so, but that's what I've seen.

OK, just one more thing: The fact that OpenBSD automatically configured the sound card in the $15 Laptop (the Compaq Armada 7770dmt), something no Linux distribution has ever done, coupled with FreeBSD's instantaneous management of the CPU fan in the $0 Laptop (Gateway Solo 1450), something done as well only by Linux kernel 2.6.18 (and with a little fiddling in subsequent kernels) is nothing short of astounding -- and a sign, in my little world at least, that Linux needs to watch its back.

Yes, competition, even for the hearts and minds of geeks, is a very good thing, indeed.