oscartheduckin’ around

November 7, 2008

Installing memcached gem on Ubuntu intrepid

Filed under: how to — oscartheduck @ 4:58 am

This one took forever to work out. For the second time. If I’d written things down the first time…

Okay. First things first: the memcache gem can only install from rubygems 1.2 or lower. So visit rubygems, and download the source for the relevant version.

Second, memcached gem requires several libraries to be in place to compile against. However, only one version of the libmemcached is compatible with the mecached gem. Where did I get such a ludicrous idea, you ask, when you’ve clearly read other blog posts telling you to check the README file for compatability instructions?

http://blog.evanweaver.com/files/doc/fauna/memcached/files/README.html

There are also compatability issues with memcache itself; various versions of the gem are specifically compatible with various versions of the software.

Anyway, start here:

http://tangent.org/552/libmemcached.html

Download version 0.21, compile and install.

Then read the README that comes with the memcached gem and download and install the appropriately compatible version of memcache. How to read the README if the gem isn’t installed?

http://github.com/fauna/memcached/tree/master/COMPATIBILITY

There y’arr.

Now that you’ve done both of those, you can install the memcached gem.

And after you’ve done that, if you want to be able to use it in development, you have to install the memcache-client gem. The memcached gem is intended to run on your server, the memcache-client gem is meant to run locally in development.

Advertisements

November 6, 2008

Installing rails 2.02 on ubuntu Intrepid with ruby 1.8.6

Filed under: how to, ruby, ubuntu — oscartheduck @ 5:26 pm

I’ve done this too many times to have not documented it somewhere.

Ruby 1.8.7 is the default on Intrepid; 1.8.6 is needed to run rails < 2.1, so it’s useful to know how to do it.

1. Install ruby from source.

http://ruby.mirrors-r-us.net/news/2007/03/12/ruby-1-8-6-released/index.html

2. install rubygems from source

http://files.rubyforge.vm.bytemark.co.uk/rubygems/rubygems-1.3.1.tgz

3. You’ll get the following error:

in `gem_original_require’: no such file to load — zlib (LoadError)

if you try to use rubygems.

To solve this, go into your ruby source directory:

cd ruby-1.8.6/

then:

cd ext/zlib

ruby extconf.rb

make

sudo make install

4. sudo gem install rails -v 2.0.2

May 9, 2008

code -> pdf

Filed under: how to — Tags: , , — oscartheduck @ 2:59 pm

I’m on my way out right now, but I’m going to write up a script tonight called code2pdf, and wanted to write down the history of it before it leaves my head.

I have been taking a CS class this semester, and have been writing code as a consequence. The requirements for submitting this code are twofold:

1. pop all code and a scriptfile proving the code works on a USB stick

2. print out copies of all code and the scriptfile and submit with above.

Now, most of the folks are using some kind of windows kludge to write their code, so they were taking screenshots of command windows and handing that in as a script file. I just used script, because I figured that’s what it’s there for. The problems were twofold:

1. I don’t have a printer in my house.

2. The printers at school are all connected to windows boxes.

So when I come in with a nice raw text file and attempt to print it, it looks _awful_. Same goes for code; my text files looked horrible.

But my instructor is a unix geek, so she didn’t mind at first. However, the driver being used to run the printer has a quirk in it; it has its own definition of what a tab is. I couldn’t believe it; my nice sensible “two spaces to a tab” code was running and running and running over line after line of blank space. Which didn’t worry me, but it made trying to read the code a horrible task for the instructor. True to her form, she mildly pointed this out to me and asked me to work on the issue, no fuss just a pleasant request. Which is the best way to get results.

So, I started thinking about it. First things first, I stopped using tabs and started using spaces. The printouts looked a lot better from that alone.

But I decided not to stop there; my instructor had been polite, and I have the power of FreeBSD available. I installed OpenOffice from the port (which took ages), after which my hard drive killed itself. So I installed anew and installed OpenOffice again, which took forever again. And I copied my code into OpenOffice and output it as a .pdf.

.pdf rules. I format things nicely, go through the file and make sure everything’s pretty and I’m happy as a clam at high tide. The script file was more difficult than the code, funnily enough, as openoffice is smart enough to read the .txt extension, scan the interior and then kindly offer to format everything as a spreadsheet.

Remove the extension and open the file again, and a different preprocessor asks for advice. I told it to use luxi mono as the font, and everything looks pretty. From there to .pdf is as simple as using the filter.

But why stop there? With the ports system at my fingertips, I can do anything! And I don’t want to start up openoffice just to spew out a .pdf file, more importantly. After a couple of creative searches, I foundĀ  a beautiful program called highlight, which takes code in and spews out one of several forms, HTML, rtf, TeX, LaTeX, XML, a few others.

I export everything to .rtf and then open it in openoffice, just to take a look. It looks great; colour code highlighting, the works. Export to pdf, to make sure I have it in time for my deadline, and then get back to work.

I export everything as TeX, then use pdftex and it comes out as a gorgeous looking pdf, but only in greyscale. I wanted to hand in colour, so I didn’t worry about this and instead used openoffice, but tonight I’ll be looking for a .rtf to .pdf filter on the command line so I can deal with everything and get colour output.

Whether I find it or not, I’ll write up a quick script to take in code and output a greyscale pdf file. Then I’ll investigate script files, which I imagine will be as simple as txt2pdf or something named similarly. Then I’ll submit it as a port; it’ll be a front end to other tools, but I think the ability to ensure my code looked gorgeous from any operating system and printed out correctly was sufficiently useful that other students would like the same thing. And lo! It will be called something witty.

I’m thinking it should be a simple thing that offers flags to output colour or greyscale pdfs (eventually), and also can handle script files. Pretty code all day long.

January 15, 2008

EXT2-fs: blocksize too small ramdisk

Filed under: ext2, GNU/linux, how to, linux, ramdisk — oscartheduck @ 3:08 pm

I received this error creating ramdisks, and it was somewhat annoying finding a solution, though the error is perfectly clear.

It turns out that I had created my ramdisk with an ext2 file system and a blocksize of 1024, the default size. However, the kernel has built into it that it wants a size of 4096 for the block.

I couldn’t quite believe that it needed blocks that large, but the kernel guys know better than I do what to do. At first, I had tried a mere 2048 for the blocksize, but that didn’t cut it. Finding out that it wanted something that large was a shock, though.

Especially as the amount of RAM I have in my client is 256 meg. I have a 20 meg or so ramdisk image I am pushing down. Using a blocksize of 4096 resulted in a whopping 300 meg image. Too much for the memory.

Fortunately, you can pass the following as an option to the kernel:

ramdisk_blocksize=1024

or indeed any abitrary ramdisk blocksize, as long as it matches your real blocksize. If you’re using pxe, as I am, put it in your APPEND line. If you’re using grub to do this somehow, then add it in the boot line, I assume.

July 25, 2007

On ports vs pkg_add — a digression into keeping your FreeBSD programs up to date with the latest patches and software

Filed under: freebsd, how to — oscartheduck @ 1:57 pm

Something that confused the hell out of me when I first started using FreeBSD was ports vs pkg_add. It was worth getting used to ports, I think, because these days I use nothing else.

What’s the difference?

The initial difference that struck me was speed. pkg_add installs things a lot faster than ports. Recently, I had to install TeXMacs, a program I hope dies a painful death in a pit full of wildebeest droppings somewhere, and I had to install it fast. To do that, I started building the port, installed the binary package with pkg_add and once my port was finished being made I deinstalled the pkg and installed the port. It took about ten seconds to install the pkg, and about an hour and a half to install the port.

Given that MASSIVE speed difference, why the hell would anyone use ports? The answer is that they’re magically delicious in every single way.

No, but seriously. Once you start using ports rather than pkges, I doubt you’ll ever ever ever go back to the pkg.

Yeah, but what’s the sodding difference?

Okay. A pkg is a prebuilt binary. A port is building the same binary, but doing it from source on the local machine.

So, a pkg is built in a generic kind of way. It runs on most machines. A prebuilt binary is how windows, Mac OS, most linuxes, all distribute their stuff. My linux of choice is Ubuntu. When you do an add/remove programs install, a synaptic install, or (for me) an apt-get install, you’re installing prebuilt binaries. They’re convenient, as they generally have a lot of the fiddly bits they need prepackaged with them. When a pkg just works, it’s a beautiful and fast thing.

The problem is when they don’t. That’s when ports shine.

A port is to a pkg as gold is to brass. Brass is nice, but once you sell a pound of brass and a pound of gold then you’ll never want brass again.

The best way to get familiar with ports is by using them. Do you have a ports tree? If so, and you’ve never used it, it’ll be out of date.

If not, that sucks and you should have one.

It is necessary, absolutely necessary, to have your ports tree always up to date if you’re running on ports. I discovered this in a painful way, by mixing ports and pkges.

A Brief Digression
Back when I first started running FreeBSD, I completely destroyed my system installing the simplest stuff. Eventually, nothing would install. I do mean nothing. I had no idea what was going wrong, I just knew that I was frustrated. So I stopped using FreeBSD for a long time.

When I came back to it, I had no idea what to do. Fortunately, a friend of mine is a FreeBSD guru. So I asked him. And he talked me through solving all my issues.

First, he said, update your ports tree. He left me to work out how to do it. I read things about cvsup, I read things about new tools that had just been developed, I had no idea. I stumbled through the most excellent FreeBSD diary until I discovered the solution, and I updated my ports tree.

Next, he said, you’re fortunate to have installed portupgrade a long time ago. Run this command:

portupgrade -ay

This took about three or four days to run. A long long time. Especially as I did not know what screen was back then. Ouch!

There were options screens occasionally, which I answered as best I could, and eventually it was done. And my god, the system worked! I had to know more!

Digression Digressed

First, become root. This assumes you’re root. If you don’t have a /usr/ports directory, do a:

mkdir /usr/ports

If you don’t have a /usr directory, you are in a world of pain and I pity you.

FreeBSD contains a tool that brings a ports tree up to date in a relatively painless way. This is portsnap. To update your ports tree using portsnap, run:

portsnap fetch

This takes a little time to run. Be patient, brew a cup of tea and drink it.

Now run:

portsnap extract

This takes time to run, too. Maybe five, ten minutes depending on your computer’s speed. Notice what’s being spread across your screen: why, it’s pathnames with packagenames inside!

Once it’s done, execute:

cd /usr/ports

And do an ls.

You’ll notice names of types of packages. Here’s mine right now:

.cvsignore INDEX-6.bz2 Templates audio deskutils ftp java net ports-mgmt textproc x11-fonts
.portsnap.INDEX INDEX-6.db Tools benchmarks devel games korean net-im portuguese ukrainian x11-servers
CHANGES KNOBS UIDs biology distfiles german lang net-mgmt print vietnamese x11-themes
COPYRIGHT LEGAL UPDATING cad dns graphics mail net-p2p russian www x11-toolkits
GIDs MOVED accessibility chinese editors hebrew math news science x11 x11-wm
INDEX Makefile arabic comms emulators hungarian mbone packages security x11-clocks
INDEX-5 Mk archivers converters finance irc misc palm shells x11-drivers
INDEX-6 README astro databases french japanese multimedia polish sysutils x11-fm

Lots of packages. Some indexes, a README, a file named UPDATING and so on.

Good stuff. Damn good stuff.

cd into something! How about this:

cd ports-mgmt

An ls will show a bunch of package names. They’re all tools that manage ports. This is the ports management section of the ports tree.

The first thing I always install is portupgrade.

cd portupgrade

Before going any further, do an ls. You’ll see some neat files. A pkg-descr, a Makefile, a pkg-message, a pkg-plist and distinfo. What are all of these?

Well, it took me a long time to discover, but I know these days.

The Makefile describes everything FreeBSD needs to know to make a binary of this package. It tells FreeBSD where to download the source code from, then what to do with it. It tells FreeBSD what options are available for this port, so that it builds differently, and anything else FreeBSD needs to know to build this file so it will work on your computer.

Do a less on the Makefile and give it a read. You’ll understand some stuff, not others. It’s all shell script, and you’ll eventually get very very very used to reading it if you administer a FreeBSD system.

distinfo contains information for FreeBSD to know that when you download the source code (which FreeBSD will do automatically for you at the right time) it is not corrupt. It contains an md5sum and a SHA256 sum and a size for the package. If you don’t know how these work, it’s interesting reading around and finding out what they do. For now, though, just understand that they GUARANTEE that your package will be built properly.

The pkg-descr is exactly what it almost sounds like. It’s a description of the contents of the package. For this package, the most useful thing to note iniside it is that you’re going to get several cool extra tools, like pkg_deinstall and pkgdb. My god, if I could count the number of times pkgdb has saved my ass, wow.

pkg-mesg is a neat message that’ll pop onto the screen when the port is installed, giving VERY USEFUL information about how to configure it properly. You often have to scroll the screen up a little to see its contents, so bear that in mind. The pkg-mesg for moinmoin, for example, tells you where and how your moin install is and what to do to make it work. Ports are friendly that way, they often tells you what you need to do to make your install work.

pkg-plist contains a list of packages installed by this port, so that when deinstall happens everything is deinstalled properly.

Some of these files may not exist, some different files might be there. The canonical reference is, as ever, the handbook.

So anyway, to install portupgrade from this port, type “make install clean”. You’ll see a bunch of downloading occur, a bunch of making of files, maybe a bunch that you weren’t aware you need to have installed. For example, it’s not uncommon to see ruby on rails be installed by ports managment stuff, a lot of it seems to be written in ruby, or for moinmoin you’ll see python installed because that’s the language python is written in.

The neat thing is for web related stuff. Ports are so damn smart that if you’ve got apache installed and you install moin, it’ll install mod_python for you automatically so that you’re ready to go. If you hadn’t already installed apache, you’ll have to do some manual fiddling, though.

So now you’ve got portupgrade installed, the best thing to do is decide whether you’re going for a ports based system or a pkg based system. YOU SHOULD NOT MIX. PICK ONE AND STICK WITH IT. HELL WILL HAPPEN IF YOU DON’T.

Why Hell?

pkges are built for you at specific version numbers. Ports, on the other hand, you build from the ports tree you download with portsnap. The Makefiles are often at different version numbers than the pkges. But pkg_add will clobber your currently installed ports! So you can install an old version of a package over a new version.

Remember above, I said ports download recursively, satisfying their dependencies? Well, if your version of moin is dependent on python 2.5, and the current pkg was only at 2.4, then when you pkg_add python and destroy your current version, moin will stop working!

Now, stop panicking quite so much, FreeBSD is smarter than this overly simple example. But the principle is true. Minor revisions are actually important numbers.

You will mire your entire operating system in a world of shit by mixing the two different systems.

How To Solve This Issue?

We actually just installed the tool to solve this issue, portupgrade. Run:

“portupgrade -ay”

It will discover all your installed ports OR packages, test their version number against the version in the ports tree and make sure you’re at the appropriate version. Portupgrade is discussed in the handbook, but be aware that it’s simply a completely badass tool.

There are other tools available for keeping your installed packages up to date with the latest packages and patches and so on, but these are the ones I use.

Isn’t There a Catch?

There are a couple of catches to using ports.

First, pkgdb, the database it uses to keep track of everything, occasionally notices conflicts that must be fixed. There is one command to solve this:

pkgdb -F

Last weekend, for whatever reason I had to run this four times in a row. But that’s all I had to do to solve the issue, run that command. That’s ease of use for you, as far as I’m concerned. If you try to install anything with a conflict, the install will fail telling you to run pkgdb -F.

The other is UPDATING. In /usr/ports, there’s a text file called UPDATING. This contains useful information on known security issues, problems with certain installs. Recently, FreeBSD moved to xorg 7.2, and there’s a whole list in UPDATING on how to update to 7.2 using ports. It’s a pain having to follow the steps, but that’s all you have to do. Just follow the UPDATING steps and you’ll be fine. FOLLOW ALL OF THEM.

And that’s that.

This upgrades all your installed ports to be the latest and greatest. It’s the tools that automate everything that make ports so amazing to me. That and knowing that every package is there specifically for my machine.

But I Need It In A Hurry

This was the issue with TeXMacs. I needed it fast. So, what did I do? I cded into /usr/ports/editors/texmacs && make

This started making the binary in the background.

Then I crossed my fingers, prayed, and did a pkg_add -r texmacs.

This installed hte binary which, fortunately, didn’t clash with my system. I used the binary until the port was built (ports are usually fast, incidentally, just not in the case of larger installs) and then did a:

cd /usr/ports/editors/texmacs && make deinstall && make install && make clean

So I deinstalled the pkg, which ports is smart enough to do, then installed my already built binary and cleaned up afterwards.

I’ve ran into versioning issues with pkg_add, but never with ports. And it’s never hard to keep up to date with ports. To find a port to install, simply:

cd /usr/ports

make search name=pkgname

So to locate the latest version of python:

make search name=python | less

Bunches of stuff flies past the screen, so pipe it to less so you can read at your leisure. You’ll find it.

Ports is very very comprehensive. It seems to have, for example, the entire CPAN library for Perl. It doesn’t have all the python packages I’d like, but it has a lot of them. If you find something that ports doesn’t have, consider making a port and submitting it: http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/ is the documentation for how to make a port.

Now that you’ve solved your package maintenance issues, in the future we’ll consider how to make your base distribution up to snuff with the current patches.

P.S I’m Security Paranoid

For those amongst us who TRUST NOTHING, consider the port portaudit port. It’s in /usr/ports/ports-mgmt — go ahead and cd into the portaudit directory and make install clean.

It will email your administrator email address with the results of a portaudit scan against the latest portaudit database every night, telling you about known security issues with anything and how to resolve those issues if any resolution is available. Damn useful! For more information, read the handbook page on portaudit.

June 2, 2007

create new NIS user account and another project

Filed under: freebsd, how to, red hat, Uncategorized — oscartheduck @ 12:55 pm

I need to write this down because I do it maybe once every eight months and it’s a struggle each time.

Okay. It’s simple.

vi /etc/passwd.nis and add the appropriate individual.

cd /etc/sp && make

Yay!

I’m thinking of writing a little script to take a list of file names and grep ’em. I was thinking about calling it something like grepgle and adding a couple of optimisations:

1. when activated with a -1 flag, grepgle uses locate to discover the list of files to grep

2. when activated with a -2 flag, grepgle uses find to discover the list of file names

I’ve got to consider whether it’s worth the time to code it, though.

&title=”> Stumble it!

April 19, 2007

“application/x-httpd-php” downloading instead of being served by wordpress on freebsd

Filed under: apache, freebsd, how to, wordpress — oscartheduck @ 1:12 am

I did a fresh install of apache, wordpress etc for a friend today. Made a slight mistake in the order things were installed, such that instead of delivering WONDROUS wordpress documents, instead I was getting a download link for application/x-httpd-php. I was like “What the fudgemister is this?”

I did the sensible thing and goooooooooogled around a bit and found people saying that they couldn’t fix it except if they increased the amount of swap PHP was accessing.

Now, when I hear something like that I figure that’s a bullshit answer. What the hell does increasing PHP’s swap have to do with whether apache is interpreting the php file properly? And when I read the stats on some of the machines that were complaining about this, hell, they have more RAM available to them than I have swap + RAM on this machine, and some of my friends are running on machines that make my pentium3 500mhz, 128mb RAM machine look positively mighty. Not that that’s a bad machine at all, I’m rather pleased with it as a web server, but it’s nada by modern standards.

Anyway, where was I. Oh yeah, how to solve this issue? Well, as I say, I saw it as apache wasn’t interpreting the page but was instead serving it instead. So I had a lead.

I checked out httpd.conf and discovered that there was no line reading “php5_module”. I thought that was downright odd. It’s a consequence of installing apache after php, it seems.

I added the line “LoadModule php5_module libexec/apache22/libphp5.so”. But libphp5.so wasn’t installed.

The simple answer was to reconfigure php5. I installed it from the port, which is the only way I install software because I have a few custom flags in gcc so that stuff is compiled specifically for the p3 architecture. Anyway, how to solve this is: cd /usr/ports/lang/php5 && make configure —– make sure that the mod_php is checked and reconfigure that sucker.

If that doesn’t work, try out the php swap thing. Googling around will tell you how to do that, but for me the issue was mod_php not being installed. FreeBSD makes it very simple to install mod_php, as you can see. If you’re using OpenBSD, which is a badass OS, I imagine it’s exactly the same procedure, though I’ve never done it. Other OSes? I dunno, but google around for instructions. For example, a simple google for “mod_php install debian” revealed http://www.virtualmin.com/bug-tracker/bug?format=table&f_state=7&bug_number=563&project_id=1697, which tells you how to solve for debian.

But you should just install FreeBSD or OpenBSD, learn those systems and use those. They’re tasty.

April 12, 2007

wordpress on freebsd — mysql install

Filed under: apache, freebsd, how to — oscartheduck @ 11:15 pm

Well, I haven’t finished this one yet, but I wanted to note down my steps thus far.

Then I cded into /usr/ports/databases and installed mysql51. I installed both the client and the server.

I then followed fantastic directions for installing mysql on FreeBSD</a>. Read the comments too.

http://codex.wordpress.org/Installing_WordPress#Using_the_MySQL_Client then starts instructions for using the mysql client. I found that there isn’t a root password for it by default. I couldn’t see how to enter that blank password such that I could change from no password to some password.

I didn’t like that, especially if it’s running as a backend for a website.

February 27, 2007

Moin on Apache on OpenBSD

Filed under: apache, how to, moin, MoinMoin, openbsd — oscartheduck @ 3:41 pm

This one hasn’t been as bad as it could have been.

For some reason, python’s internal networking stuff hasn’t been wroking properly since day one on moin for me. Some computers can access the wiki in firefox but not internet explorer, some are fine and some have no chance at all. So I decided it was time to bite the bullet and throw the whole thing into Apache.

Apache is built into OpenBSD. This makes some things really nice, like not having to install and configure the sucker. However, as it’s built in and as it’s OpenBSD, there are massive security precautions that have been taken. They state in the OpenBSD documents that security and ease of use are often incompatible goals, a harsh warning that is maybe a little too strong.

First, read this and read it again: http://moinmoin.wikiwikiweb.de/HelpOnInstalling/ApacheOnLinux

The paths in OpenBSD are different. It stores Apache in /var/www/, but it’s turned off by default. To turn it on, there are two tricks; either claims to work. The first is to create a file called /etc/rc.conf.local and add the line to activate apache, which is httpd_flags=”” – see http://www.openbsd.org/faq/faq10.html#httpdchroot

The other is to edit /etc/rc.conf directly. For whatever reason, my override file didn’t seem to want to work properly, so I edited rc.conf directly. I’m going to revisit this, though, and get the override file working eventually.

Go ahead and follow the instructions for apache on linux that I linked earlier on. I put the Alias and ScriptAlias in section 2 of httpd.conf

Now, the first thing you’ll notice is that the fucking thing doesn’t work. This document gives a good idea why: http://www.openbsd.org/faq/faq10.html#httpdchroot

The chroot environment prevents apache from seeing outside of its own directories. Grand. So, what’s the solution? Well, right now my solution is to turn the chroot off. This isn’t ideal, but it works reasonably well. Simply add the -u flag to the line in rc.conf or rc.conf.local, thus: httpd_flags=”-u”

That’ll get things up and running. I found that I had a shit ton of path issues after that. Simply tail-f /var/ww/logs/error_log and keep accessing your wiki from a browser. You’ll see errors crop up; fix them as they appear and everything should be tickety boo.

February 20, 2007

install metisse on freebsd

Filed under: freebsd, how to, metisse — oscartheduck @ 5:45 am

Getting metisse installed on FreeBSD was more work than I wanted it to be, but not too painful. Consider this a how to that’ll get you most of the way, with only one or two very minor steps left out that are noted along the way.

First, you need the code for nucleo and metisse. Nucleo is the framework metisse uses. Grab them both from the following link, using the cvs versions of each:

http://insitu.lri.fr/metisse/docs/building.html

Now, you need to create some symlinks for nucleo to build. It’s looking for the auto build tools in linuxy places.
ln -s /usr/bin/autconf259 /usr/local/bin/autoconf
ln -s /usr/local/bin/automake19 /usr/local/bin/automake
ln -s /usr/local/bin/aclocal19 /usr/local/bin/aclocal

and so on. I forget exactly which other auto tools exist, but yer get the idea. This is where I’m not being entirely accurate, as I forget what the other tools were.
Now you’re using aclocal19 and as such need to add a few libraries from aclocal in there. The way to do this is:

echo /usr/local/share/aclocal > /usr/local/share/aclocal19/dirlist

Nucleo should build fine now.

This shows that I didn’t document properly. I have a note that metisse needs to find nucleo-config but can’t – I don’t know entirely how accurate this is. If you get the error that you can’t build without nucleo-config, then another symlink works wonders:

ln -s /path/to/nucleo/nucleo-0.6/nucleo-config /usr/local/bin

Works wonders.

Now, to get metisse working. Before anything else, edit the source code:

vi /path/to/metisse/xserver/mi/miarc.c

replace alloca.h with stdlib.h. They’re the same thing with different names in linux and FreeBSD.

./configure –enable-glx –enable-mmx

make

make install

All done.

Now, that’s installed. Great. But you need fvwm as a window manager to use it. Getting gnome to accept fvwm is simple enough, as long as you know the trick.

Follow the directions here: http://www.fvwm.org/documentation/faq/#2.8

However, instead of relying on gnome to auto save its configuration, call up a terminal in gnome and type “gnome-session-save”.

Should be all done! Now, I just need to work out how to get it working once it’s installed….

Blog at WordPress.com.