The Fifth Path Magazine

The days of magazines, especially ones covering very-specific musical genres, is long past now. But back in the early ‘90s, years before most people became aware of the internet, these magazines were our primary source of information about bands and topics that were otherwise difficult to find.

There were plenty of punk 'zines around in the '80s and '90s, and we had Propaganda Magazine for goth stuff, but those of us into the growing post-industrial scene didn’t have anything talking about our (somewhat questionable) interests. We mostly had to just wait for the occasional band profile in Propaganda or new volume by RE/Search.

The Fifth Path was a short-lived magazine out of Sacramento, California that filled this niche. Only five issues were ever published, coming out sporadically between 1991 and 1994. The founder, Robert Ward, died in 2004. Michael Moynihan of Blood Axis was a contributing writer to issue 3 and is credited as Associate Editor in issues 4 and 5.

×

This magazine was unique in its time, being the first US-based magazine (that I was aware of, anyway) to primarily cover the post-industrial genre that later came to be known as “neofolk”. At the time this style was commonly referred to as “apocalyptic folk” or simply “World Serpent” — so called after World Serpent Distribution, who put out most of these releases.

Any editorial flaws the magazine had were more than made up for by the quality of the material. Ward scored interviews with most of the major artists of the time: Death in June, Sol Invictus, Fire + Ice, and more. Alongside the music was the usual selection of countercultural topics such as Satanism, Charles Manson, social darwinism, and so on.

I bought all five issues as they came out but these copies have long since vanished into time. I was reminded of the magazine recently and, after fruitlessly watching Ebay for a while, I got in touch with Fred Berger, founder and editor of Propaganda Magazine, who generously agreed to part with the copies in his library.

The feature articles are all very good, and it’s interesting to look at these as a snapshot of this subculture in the early '90s, particularly the ads and short news items included at the beginning of each issue (for example, Varg Vikernes’s arrest for church burning in Norway is covered in issue five).

×
×

I’ve scanned all five issues and you can now download them right here. Each issue contains a selection of music articles, news, music and book reviews, and articles on topics such as survival, occultism, etc.

The Fifth Path: Issue One
Foetus Inc, Death in June, Robert Anton Wilson, Zeena LaVey, Jack Chick, Throbbing Gristle bootleg reviews, An Introduction to Urban and Wilderness Survival
The Fifth Path: Issue Two
Rozz Williams, Kodo, Skinheads in East Germany, live show reviews of Death in June, Current 93, Sol Invictus, Survival: Shelters and Tools
The Fifth Path: Issue Three
Boyd Rice, Sol Invictus, Freya Aswynn, Blood Axis, Yukio Mishima, Carl Orff, Skinheads in East Germany part II, Survival: Fire Starting Tools
The Fifth Path: Issue Four
Swans, Sol Invictus part II, Adam Parfrey, Crash Worship, The Electric Hellfire Club, Thomas Lyttle, Odinism in Heavy Metal
The Fifth Path: Issue Five
Fire + Ice, In the Nursery, Ordo Equitum Solis, Somewhere in Europe, David E. Williams, Will, Bathory, Odinism in Heavy Metal part II, Third World Black Magic Dictators

The magazines are not in pristine condition, as they were used as source material for articles in Propaganda. Some pages have margin notes and highlighting by Fred Berger, and a Death in June photo was cut out of issue one for use in a Propaganda layout. Apart from these minor things, they are all complete and readable, and should be an enjoyable read for anyone interested in this scene.

Wanted to Buy

×

I’m also looking for a copy of Wake, the magazine/paper published by Boyd Rice’s Abraxas Foundation, also in the 1990s. If you have a copy you’d like to part with, or know someone who does, please get in touch.

Update: Got one. Thanks RN Taylor!

Wanted to buy: Nurse With Wound's Soliloquy for Lilith

A while back I stumbled upon a copy of Nurse With Wound’s Soliloquy for Lilith vinyl box set in the new arrivals bin at one of my local record stores. This was pretty exciting, but the price tag was even more so, as it was selling for less than 30% of the usual selling price for this hard-to-find album.

But then I discovered the reason for the low price: The first of the three LPs in the box was missing. The rest of the set was in great condition though, and it included the two original paper inserts as well, so I didn’t let this missing disc stop me from snapping it up.

Which brings me to the reason for this post: I’m looking for that missing record and haven’t had any luck finding it through the usual channels. My saved search alerts on Ebay have been silent for months, and the few copies available on Discogs are all complete sets, starting at $150 and going up from there. So I’m hoping that search engines will do their magic and someone will find this post and get in touch.

The record labels don’t say which disc is which, so the way to figure it out is to look at the runout etchings. The three records all read “MIRRORONE”, followed by the disc number, followed by a letter indicating the A or B side of the record.

So the one I’m looking for will be marked “MIRRORONE 1”.

Do you have a copy of Soliloquy for Lilith disc one for sale? Get in touch!

David Tibet's Sing Omega

Yesterday I received my copy of Sing Omega, the long-awaited book of the collected lyrics of David Tibet of Current 93. I preordered this book when it was first announced, back in early 2003 (that’s not a typo). I’ve moved six times since then so I’m also a little amazed it found it’s way to me at all. Honestly, I had pretty much forgotten about it until Tibet began mentioning it again in the Coptic Cat newsletter some time last year.

The book is 540 pages of collected lyrics from Current 93’s 30 years of recorded history, from 1983 through the end of 2013. Presented in reverse chronological order, it begins with last year’s I am the Last of All the Field that Fell and continues backward in time until 1983’s LAShTAL.

Based on the number of pages in this edition, if it had been published in 2003 it would have come in at about 310 pages, so we can see that Tibet’s writing has gotten a bit more verbose over the years (averaging ~150 pages per decade for the first 20 years, then 230 for the third). But then, that’s hardly news to anyone who’s been following along. It opens with brief introduction and thank you pages, and closes with a two page afterword written by Thomas Ligotti.

As for the book itself, it’s beautifully cloth-bound and printed on nice paper with high-quality glossy endpapers, with the cover embossed in black with simple artwork on the front and the title on the spine. It came with a cardstock insert printed with a quote from Pomegranate (from the 2011 album Honeysuckle Æons; page 70) and hand signed by David. The pages are all text, with a single black and white photo opposite the title page.

The book’s production is limited to a run of 930 copies, and those of us who preordered when it was first announced also received a limited edition CD consisting of previously unreleased tracks and spoken/read pieces. A line following the credits on the back of the CD slipcover reads, “This CD accompanies all those copies of David Tibet’s Sing Omega that were purchased in the first decade of the Twenty-First Century.”

You can buy copies here while supplies last.

Update: It looks like this book is now sold out and discontinued.

In search of a better Adobe workflow

Our team at Colette HQ has grown from two to five people this year. Having people dedicated to pattern development and graphic design has been a huge help where production is concerned. Having a larger team also introduces complications, of course, but nothing we haven’t been able to work with, so for the most part things are running smoothly.

The one issue we haven’t been able to figure out yet is a reasonable workflow for dealing with our various Adobe files. Most of our pattern production work happens in Illustrator and InDesign, with three different people working on the files at various stages of development. This, needless to day, necessitates a good, trusted system to ensure that everyone’s changes are tracked and preserved.

Software developers solved this problem ages ago with version control but, as far as I can tell, designers and others users of Adobe products have no reasonable equivalent, despite having the same needs. At one time Adobe had a product called Version Cue which seems like it filled this need, but it was discontinued with the release of CS5 in early 2010. Now, with Creative Cloud, Adobe promises some sort of versioning for files stored on their “cloud” service but this is obviously a non-starter for companies and teams that prefer to manage their own file storage.

I recently found a product called Timeline that looks promising: It provides plugins for Photoshop, Illustrator, and InDesign that talk to your own Subversion backend. But the last product announcement on the company’s blog was about adding CS6 support nearly a year ago and contains no mention of Creative Cloud support at all. A comment on their blog asking about this has gone unanswered for four months and their Twitter account hasn’t been used since June 2012 so I have to assume this is a dead project as well.

The basics of what we need are trivial: a) simple updating to the latest or earlier revisions of a file, and b) the ability to check in changes with notes. I’d just set up a central Subversion repository for these files myself but I’m not convinced that’s the best way to handle files like this.

I know our needs are not unique – surely every design team of more than a few people has run into this. How do teams at larger companies and agencies manage this?

Host your own remote Git repositories

Originally written and published elsewhere in June, 2011.

As more and more developers are moving to Git for their version control needs, one important use case is being left behind: that of the development team who wants a single official repository but prefers not to rely on a third party such as GitHub to host it. Unlike Subversion, the distributed nature of Git means that maintaining a single authoritative copy isn’t as easy as it should be. GitHub’s paid plans ease this pain but third-party hosting isn’t always the best answer, or even possible in some cases. Here’s how you can do it yourself.

First, a few assumptions

This article assumes you have a dedicated Linux server, physical or virtual, with root or sudo access. These instructions will not work on shared hosting or Windows servers, but they will work on BSD or other Unix variants with very little modification. I’m using Ubuntu for these examples. It also assumes a basic level of familiarity with managing user accounts and using SSH keys, as well as familiarity with Git itself.

A note about terminology

When referring to your server, I use the hostname server.example.com. You’ll want to replace this with your own server’s hostname. Likewise, when I refer to GitHub URLs, I use username in place of the account name. Be sure to use your own here as well. Finally, repository.git should always be changed to the actual name of your own Git repository.

Sound good? Ok, let’s get started.

Server Setup

I shouldn’t need to mention this step, but just in case:

$ sudo apt-get install git

We’re going to use the GitHub model for our Git server — a single user account that’s used to access all the repositories on the server. Logins are allowed with SSH keys only, and even then only to run Git commands. For consistency, we’ll call this account git and give it a home directory of /var/git.

We’re giving this account a Bash shell initially so we can more easily run the setup commands as this user. When we’re finished we’ll change it to the more restrictive git-shell, a shell included in the Git package that restricts commands to those used for Git interaction.

$ sudo useradd -m -d /var/git -s /bin/bash -c 'Git' git

Now become the git user. Unless otherwise noted, the rest of these commands will be run as this user.

$ sudo su - git

The next step is to collect SSH keys from your developers and place them in a single authorized_keys file in the git user’s ~/.ssh directory. Note that this directory must be readable only by this user.

$ mkdir /var/git/.ssh
$ touch /var/git/.ssh/authorized_keys
$ chmod 700 /var/git/.ssh

Now add the SSH keys you collected to this new authorized_keys file, one key per line.

Your Repositories

Now that you have a Git account and your developers can access it, it’s time to give them something to work with. We’ll cover copying existing repositories from GitHub and also creating new, empty ones and pushing your own code into it.

But first, we need to actually create a repository. The initial steps are the same regardless of how you’ll be adding your code to it. So create the directory to work with, initialize it as a bare Git repository, and set the appropriate ownership. You’ll naturally want to use your own repository name instead of repository.git, as I use here.

$ mkdir /var/git/repository.git
$ cd /var/git/repository.git
$ git --bare init

Now, where is your code coming from?

Scenario 1: Copy an existing repository from GitHub

In this first example, we’re going to migrate an existing repository from GitHub to our own server. In this example, replace username with your own GitHub username and repository.git with the name of your own repository.

$ git --bare fetch https://username@github.com/username/repository.git master:master

The output of the above should look something like this:

$ git --bare fetch https://kennwilson@github.com/kennwilson/asset-helper.git master:master
Password: 
remote: Counting objects: 20, done.
remote: Compressing objects: 100% (19/19), done.
remote: Total 20 (delta 7), reused 0 (delta 0)
Unpacking objects: 100% (20/20), done.
From github.com:kennwilson/asset-helper
 * [new branch]      master     -> master

If that looks like what you got, you’re done and ready to move on.

Scenario 2: Create a new repository

In our second example, we’re creating a remote repository for some code that only exists on your local development machine. This is also very easy, but it requires some steps to be done locally. Open another terminal window and move into your local Git repository directory, then run the following lines to add the new remote repository URL and push up your code. In this example, dev.example.com will be replaced with the hostname of your own development server.

$ git remote add origin git@dev.example.com:repository.git
$ git push origin master

When pushing your code, you’ll see something similar to this:

$ git push origin master
Counting objects: 5, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (5/5), 4.49 KiB, done.
Total 5 (delta 0), reused 0 (delta 0)
To git@dev.example.com:repository.git
 * [new branch]      master -> master

Look good? Let’s move on.

Finishing Up

You now have a fully functional Git repository on your server, and a dedicated account your developers can use to access it. Our final step is to log out of the git account and change its shell to git-shell. This will ensure that users can’t run arbitrary commands with this shared user account.

$ logout
$ sudo chsh -s /usr/bin/git-shell git

To begin working, just clone your new repository and get started:

$ git clone git@dev.example.com:repository.git

Managing Changes

If you’ve been using GitHub, you already know what to do. But if remote Git repositories are new to you, you’ll need to adjust your workflow a bit to push your changes to the server and pull down changes made by the other developers on the team.

As we saw in the previous step, pushing up your code is as easy as:

$ git push origin master

Syncing changes committed by other developers is similarly easy: you’ll use either git fetch or git pull. The two are similar except that git pull essentially does git fetch && git merge, so use git fetch if you prefer to handle merging yourself. Explaining that in more detail is beyond the scope of this article but there are a lot of good tutorials out there for basic Git usage and workflows.