Mechanic’s Toolsets in Service Manuals

I have yet to come across a service manual for a car, truck or motorcycle which includes a comprehensive list of tools required for each maintenance or repair procedure. The manuals will most definitely include Special Service Tools (SST), but when it comes to listing whether the case cover bolts require a 1/4″ ratchet and 8 mm socket, you are left on your own to determine this fact. I can easily see why technical writers and publishers would have to draw this line when creating a service manual, as it may be assumed that the manual is being read in a workshop fully stocked with all the generic tools one would hope a mechanic would have, but what if you are adventure touring on a motorbike, or privateering in the Dakar rally? Without a truck bed, trunk, or a mobile workshop following you, it’s absolutely necessary to know which tools you need specifically for the kind of maintenance and repair you plan (or don’t plan) on performing.

I’ve only been riding 4 and a half years, but I quickly had to redefine what it meant to be mechanically prepared. I had once been used to heaving a large, heavy toolbox in the back of the Land Cruiser, prepared for just about anything happening (and enjoying that nothing ever did). Then with my first Yamaha dual-sport, a small 350 cc, lacking any form of storage besides an 8″ x 6″ x 2″ tail bag, I had to learn how to pack minimally and hope for only the most basic problems to occur, if any. Riding with friends helps, when some coordination is made ahead of time to split the tools amongst each other, but it’s not always guaranteed that the tools required to remove the carburetor on one bike would allow for the same thing to be done on another bike.

This is where many people simply draw a line for themselves and sign up for roadside assistance, carry cash for a tow, or are one of those types who touch their seat, grips and footpegs and simply sell it the moment something else requires touching.

Who actually goes to this length, to determine precisely what type of tools they require, if say, a tire tube is punctured, or a spark plug needs to be removed, or the valve clearances need to be adjusted? Who has actually performed all the repairs on their bike and made note of which tools are needed for which tasks?

Happenstance Guidance

If Google were to tell you what I search the most… it would be dictionary definitions and encyclopedia articles.

From a young age, I remember being drawn to words and meaning. I’m still obsessed with understanding, and it’s for the most part why I’m so drawn to what the internet has to offer. I enjoy my silent habit of going about my day and taking a word I see or hear and casually putting it under the microscope. The most satisfying words to me are the words that are most commonly used which we happen to be least conscious of using. For example, “wiktionary this” and “wiki that“.

I wonder… how many people can say they’ve looked up “this” in a dictionary? Or noticed that the wiki page for beards rivals most Wikipedia articles for depth of content? Only Google knows, I guess. I should probably write about all the benefits this simple habit brings me one day, but what I want to specifically lead into now is this: nothing has brought me closer to understanding myself in relation to the world than by-chance looking up the noun “medium“. That may be a dramatically embellished statement… but let me try to unpack it.

Like most cases when I look up seemingly random words in the dictionary; I’m first, struck at how flexible words can be in English, and second, amazed that I take satisfaction in looking up what feels like the obvious. This is, after all, a word I’ve used countless times throughout my spoken life. But this word got me seriously thinking… Of all the detailed definitions, the two that impressed upon me most were “The means, channel, or agency by which an aim is achieved.” and “A format for communicating or presenting information.

This is precisely what I’ve been attempting to figure out for the majority of my life; what my medium is. This is why we go to school, this is why we find a job, this is what makes us individuals with purpose and how others may find value in us. This is the interface between each one of us and the world; where individuality is born. But has anybody ever actually put it this way? Does everyone realize this early enough? Do we see each other by the means which we achieve our aims or the way we communicate information? I don’t think we do consciously, but I believe it certainly defines us unconsciously.

This makes me consider my portfolio, which happens to simply be a placeholder on the website at the moment, if anyone’s actually noticed. I have delayed posting anything until I’ve determined what sort of format I want it to be; the kind of content that I wanted to include and who it is that I want to tune it for. I have kept revisiting this hesitation with the questions, “who”, “what”, “when”, “where”, “why”, and “how?”… when I believe I should instead just be defining “the medium”. What could offer myself and those who view it more guidance? What will interface with the rest of the world in a way that displays content consciously while subconsciously hints towards that unique and identifiable “me”?

Before I Say CAD, Let Me Just Say This

Continuing on from CAD Applications on Linux:

Before I chime in on what I think would make a CAD application successful on Linux… perhaps I should back it up. I’d like to clear the air on what it is I’m talking about when I say “CAD”. I believe this is the most important definition for the Linux community to grasp hold of and understand clearly.

CAD stands for Computer-Aided Design or Computer-Aided Design and Drafting (CADD), and CAD software uses computer technology to create, assist and manage a design and its documentation.

An easy question to ask yourself, if you’re wondering whether or not CAD software is required, is, “Am I creating something?” Typically, if something’s being created, it will be subject to a level of designing. And if something is to be designed, it’s likely to change. And it’s precisely the changing, which calls for the use of computer technology. Computers can manage the change of a design much more efficiently than we humans can, but for computer technology to efficiently aid us, we must consider the kind of designing we’re performing. After all, someone has to tell the computer what to do. How you design a road isn’t the same as designing a bridge. Designing a house isn’t the same as designing an automobile. It’s these differences in the type of designing we do which brings us an overwhelming amount of software applications divided by industry and tasks, targeted for specific design methods.

If categorizing CAD software by tasks, we’d recognize 2D vector (or drafting) applications, 3D modelling applications, animation applications, analysis, GIS server software, etc. If categorizing CAD software by industry, we’d recognize the architectural, engineering, construction and manufacturing industries, among others. And if you take the manufacturing industry alone, think of all the different things that could be manufactured and the specialized software that may exist because of the differences between these things. Further, not all software is tuned for just one industry or one task. Often, many tasks are utilized within an industry, or many industries rely on one or two specific tasks.

This plethora of “CAD” can be a good thing as well as a bad thing. The Good? CAD technology can be harnessed and tuned to do so many different things; affording us a quick way to build something, a way to communicate a complicated design, a way to determine whether or not something is safe or a way of proving that an idea will work in the real world, and of course managing how these ideas change along the way. The Bad?


People have been known to bastardize the acronym in ways such as, “I need someone to CAD this up.” or “Yeah, I do CAD.” We’re placing too much meaning on the acronym and it’s leading to too much confusion. And rightfully so! It’s easier to say “CAD” than it is to describe what finite element analysis is in the context of parametric solid modelling in the manufacturing industry. It’s easier to say “CAD” than it is to describe what grading is in the context of pattern making for the fashion industry. It’s easier to say “CAD” than it is to describe a graphics pipeline in the context of rendering for the animation industry. And really, by saying “CAD”, it is actually describing these things correctly; just very generally.

So… not so much a problem with the technology itself; more to do with humans, right?

Right. We all have this little switch in our head that flicks off the moment we become disinterested in the information we’re receiving, and it causes our ears to work less with our mind. (Here’s where I thank you if you’re still following me.) So I’ve learned that I have to tune the way I communicate what I do to the ears that are listening. The way I describe what I do to my mother isn’t going to sound the same as how I describe my craft in a job interview. And on the flip side, from an interviewer’s point of view; just because I may be an expert in 2D drafting, doesn’t necessarily mean I’d be hired as a Render Wrangler, but both applicants may be CAD Technologists.

In other words, a certain type of attention needs to be paid to the way CAD is communicated because it’s capable of being received in so many different ways; its capable of meaning so many different things. I believe the same level of attention needs to be paid within the Linux community.

What’s the context?
What is being performed?
For who?

The more effort placed in communicating precisely what form of CAD technology is being done, the greater chance there is for the Linux community to do what they do best, hopefully leading to a true suite of CAD software available on Linux.

Installing Bitwig on the openSUSE Linux Distribution

I’ve been successfully running Bitwig on openSUSE for about a year now. I have been able to successfully install upgrades for Bitwig, and have even switched from openSUSE 13.2 to openSUSE Tumbleweed successfully. Frankly, I am downright amazed by the fact that this is all working.

Bitwig is arguably a game-changer as far as digital audio workstation (DAW) software goes, and impressively, it’s available for Linux. Ubuntu Linux, that is.

So… if it is only released for the Debian-based Ubuntu Linux distribution… how was I able to install it on the RPM-based openSUSE Linux distribution?

Meet Joey Hess, and figure out how to buy him a beer. He authored the Perl script called alien which converts software packages (like a .deb package to an .rpm package!). Following me? Ensure it’s installed on your machine.

Head to Bitwig’s website and download the demo for the Ubuntu platform.

Open up your terminal and get cracking!

Switch to the root user and enter your password:


Run the following to convert the Debian-based software package to an RPM-based software package which openSUSE can work with:

alien -r bitwig-studio-1.x.x.deb

Depending on your machine, it may take a while. Perhaps look up Brian Bollman in the mean time. He offers a plethora of video tutorials which will get you up to speed with Bitwig quickly and confidently, regardless of your experience with digital audio workstations or audio in general.

When alien is done, you’ll see something like:

bitwig-studio-1.x.x-x.x86_64.rpm generated 

With the .rpm generated, we can check the dependencies of the package by running the following:

rpm -i --test bitwig-studio-1.x.x-x.x86_64.rpm

Now, the following is going to depend on what you already have installed on your machine. The machine I am testing on is set up in a fairly bare-bones manner, so I anticipate that the majority of people will experience the same:

error: Failed dependencies: is needed by bitwig-studio-1.x.x-x.x86_64 is needed by bitwig-studio-1.x.x-x.x86_64 is needed by bitwig-studio-1.x.x-x.x86_64 is needed by bitwig-studio-1.x.x-x.x86_64 is needed by bitwig-studio-1.x.x-x.x86_64 is needed by bitwig-studio-1.x.x-x.x86_64 is needed by bitwig-studio-1.x.x-x.x86_64 is needed by bitwig-studio-1.x.x-x.x86_64 is needed by bitwig-studio-1.x.x-x.x86_64 is needed by bitwig-studio-1.x.x-x.x86_64

This essentially means… for the Bitwig .rpm to install and work correctly, it’s going to depend on the above packages. So, open your YaST and look up these packages. Try searching for libavcodec, libavformat and libbsd. It’s been confirmed that they aren’t there, but maybe you’ll learn something in the process of searching.

Here’s what I found:




With a few basic searches, I learn that libavcodec and libavformat are part of the FFmpeg library, and it looks like openSUSE has a few libavcodec and libavformat packages installed, though not the same ones that Ubuntu uses which Bitwig expects. Another thing I notice is that the failed dependency error we received earlier didn’t explicitly name the package as we’d expect to see in YaST. It looks as though where we are told we require, when we actually need to look for a package that is named libavcodec53. Lastly, it looks like the libbsd0 package is available in our standard openSUSE repositories, so taking care of this dependency is as easy as checking the box and installing. So go ahead and do that while YaST is open… or close YaST and be explicit in your terminal:

zypper install libbsd0

Now, because I’m not interested in hosting Linux packages, and neither do I want to encourage people to blindly download and install packages from a source they’re not 100% familiar with (including my website), this is where I tell you to spread your wings and fly. Your homework is to find the libavcodec53, libavcodec54, libavformat53 and libavformat54 packages and ensure they are manually and properly installed on your machine.

After completing your homework, run:

rpm -i bitwig-studio-1.x.x-x.x86_64.rpm

And revel in the typing of your final command:


Voila!! Bitwig will load, step you through the EULA and prompt you to install any content packages, if you’re interested.


Did you experience problems finding and installing the libavcodec53, libavcodec54, libavformat53 and libavformat54 packages? No biggie. As a last resort, you could simply forget about ’em and force Bitwig to install anyways… Not recommended, but on a test machine I was able to successfully run Bitwig even without these dependencies. There are likely to be features of Bitwig which fail to work, but I wasn’t able to find them.

Run the following:

rpm -Uvh bitwig-studio-1.x.x-x.x86_64.rpm --nodeps



Merry beat-making!!

“That’s All Right”…

…I say to myself; in that moment of eternity when I realize I just did something I didn’t mean to do that can’t be undone.

And then I correct whatever irrationality rolls through my mind to sound something like, “I’ll simply do it again.

Persistence is a recipe:

  • One part breathing-in-and-out
  • One part accepting-what-just-happened
  • One part realizing-what-you-did-can-be-done-again, and
  • One part not-being-so-hard-on-yourself, because you know exactly what needs to be done to get past this point now

Beat that shit in a bowl until it feels good, and try not to delay the repeat performance. The longer the re-attempt is delayed, the more exposed you become to distraction and the easier it is for the thing you did to truly become a failure.

It’s not that you’ll do it better next time around, it’s that you’ll gain the experience of truly finishing the job.

Mushroom Field Guides

My current selection of reference material for mycology and mushroom identification:

*The Audubon Society Field Guide to North American Mushrooms, Gary H. Lincoff
Alfred A. Knopf, 1981
ISBN 0-394-51992-2

I don’t know how I managed to score this book for a buck at a yard sale. It can be found on Amazon selling for $2,730.68! I don’t know of a more detailed field guide. The photographs are in full colour and are of excellent quality and detail. It’s my go-to book.

Mushrooms of Western Canada, Helene M.E. Schalkwijk-Barendsen
Lone Pine, 1991
ISBN 0-919433-47-2

If something isn’t making sense in the Audubon book I turn to this one. It’s specific to my region. While the illustrations are hand-drawn, they are well depicted and in colour. Handwritten notes of the specific park or lake where the mushroom was found impressed me.

Mushrooms, Kent H. McKnight/Vera B. McKnight
Peterson Field Guides, 1987
ISBN 0-395-42102-0

Another book with hand-drawn illustrations, some in colour, some in black and white. Format and font remind me of a Dostoyevsky novel, and the publisher wished to make it clear which mushrooms are “used for ‘recreational’ purposes by the drug cult”. I’m hard pressed to reach for this book.

Mushrooms, Patrick Harding
Collins Gem, 2012
ISBN 978-0-00-718307-4

Small pocketbook, covering all the basics, although I believe it’s more specific for Europe or Britain. Suitable children’s bedtime story book.

*The only book I’d replace in a heartbeat



Amanita or Agaricus?

This is probably the most exciting mushroom I have come across in my exploration of mycology so far.


I say exciting… but perhaps it’s more accurately described as challenging, or dangerous, to identify. Just about every mushroom I gaze upon inspires awe and causes me to wonder… but I do admit that if I come across a mushroom which I can quickly identify, I feel less excited.

I find this mushroom a challenge to identify for a number of reasons… 1) most significantly, it has the potential to be edible or deadly, 2) the identification really comes down to true mycological analysis; uprooting, handling, dissecting, spore printing, and 3) if it is what I think it is, by sight, it’s atypical for the region I found it in. So I thought it would be valuable to write my thoughts down. My big question is whether it is of the Agaricus or Amanita genus.

Apparent features:

  • Large white mushroom
  • Wide convex cap with smooth surface
  • Gills appear crowded and free
  • Pendant ring veil

Unobserved features:

  • Stalk base shape, whether equal, bulbous or with a cupped volva
  • Bruising; colour reaction
  • Fragrance
  • True measurements
  • Spore print colour

Thanks to a selection of mushroom field guides, and given the three most prominent features; colour, cap and ring, I’m able to reduce the type down to either a Smooth Lepiota, an Abruptly-bulbous Agaricus, a Wood Mushroom, a Destroying Angel, a Citron Amanita or a Cleft-foot Amanita. Here is my deductive reasoning, stepping through each possibility.

Smooth Lepiota, Lepiota naucina of the Agaricaceae family – Matches the above, except cap is normally egg shaped or broad with a slight knob and from all the photos I’ve referenced, the perimeter of the cap fails to match. The Smooth Lepiota’s cap perimeter terminates above the gills, whereas this mushroom’s cap perimeter terminates below the gills. Also, the veil doesn’t appear to match; the Smooth Lepiota veil is described as a moveable ring, whereas this mushroom’s veil is clearly of the down-flaring pendant type, attached on the upside. Edibility of the Smooth Lepiota is considered choice, although with caution, as some people become ill after consuming the grayish variant.

Abruptly-bulbous Agaricus, Agaricus abruptibulbus of the Agaricaceae family – The gills of the Abruptly-bulbous Agaricus are known to transition from pink to white to brown. The description of the ring matches very well along with the reference photos. The cap perimeter and transition of gills matches. Only thing that does not match is the area in which these are typically found; Ontario and Quebec to North Carolina, west to Michigan. Considered an excellent edible, but spore print is considered necessary to differentiate from a poisonous Amanita.

Wood Mushroom, Agaricus silvicola of the Agaricaceae family – Very similar to the Abruptly-bulbous Agaricus. Seen distributed over North America and Europe, often solitary. This variant is known for being slightly smaller though, with a longer, thinner stalk. Edible and popular.

Destroying Angel, Amanita virosa of the Amanitaceae family – The ring strongly matches the description of this type; a non-moveable, flaring, skirt-like ring, although in all reference photos, I find the ring to exist near the cap, much higher than half way up the stalk. The Destroying Angel cap also appears to be shorter in height and flatter as opposed to convex, although I hesitate to judge caps in this way as they are known to develop into different shapes throughout their life. The clear indication of a Destroying Angel is the saclike cup or volva at the base of the stalk and the ring is often torn on the upper stalk.

Citron Amanita, Amanita citrina of the Amanitaceae family – Cap tends to be more yellowish to greenish-yellow than white and sticky when wet. The bulbous base and pendant ring are clear indicators, but again like the Destroying Angel, I find the ring to be higher on the stalk than the mushroom in question. The Citron Amanita should be avoided and is considered inedible due to the variety of colours and overlapping similarities to the deadly Death Cap.

Cleft-foot Amanita, Amanita brunnescens of the Amanitaceae family – Known for its brownish cap and sticky surface, looking very similar to all of the above. It has a bulbous base, not saclike though, and is observed with vertical splits. Pendant ring again, sits high on the stalk. Possibly poisonous.

Sifting through each species of mushroom, I’m finding that in this case, it’s coming down to a number of things I didn’t check when I snapped the photo. The least I could have done is uproot the stalk or clear the moss away so that the base was more apparent. If I were truly interested in feeding myself, I would have performed a spore print, as I believe it would have best determined exactly which mushroom it was. Abruptly-bulbous Agaricus would have been a purple-brown spore print. Wood Mushroom would have been brown. Smooth Lepiota, white. Destroying Angel, white, Citron Amanita, white. Cleft-foot Amanita, white. And in the case of a white spore print, the base of the stalk should clearly differentiate the edible from the non-edible. And if after all this you truly aren’t satisfied, place some gill flesh under a microscope to ensure the gill flesh is never divergent (as is the case with Amanita); the tissue strands should be parallel or interwoven.

Essentially, after stepping through all the details of these different mushrooms, given the fact that I will never know exactly which mushroom this is without the knowledge of what the stalk base or spore print looks like, I would wager to say that this is an Agaricus. I want to believe it’s the Abruptly-bulbous Agaricus, despite the fact that it’s not in the region the book declares it should be in. The thickness of the stalk and cap, the clear and uniform white colour, the proportions of the ring along the stalk, and the detail of the cap perimeter where the gills meet the cap edge… I simply don’t see this in the other mushrooms. If it really weren’t the Abruptly-bulbous Agaricus, I wouldn’t be surprised as there are something like 200 Agaricus species in North America…

Would I eat it? Given that expected purple-brown spore print and abrupt bulb, and perhaps if a mouse hadn’t defecated on it, sure I would.


CAD Applications on Linux

I’m relatively new to Linux. My first experience with Linux was configuring a dual-boot setup with Windows XP and Ubuntu back in 2008. Dissatisfied with what Ubuntu and Linux had to offer then, I attempted again in early 2011. Again, I was dissatisfied. Round three, I’m surrounded by all things Linux. I have a Synology NAS, Nexus 5, Nexus 7, LG G4, my Ultrabook running only openSUSE and my desktop dual-booting openSUSE and Windows 10. Am I, now, still dissatisfied?

Well… that leads to a complicated answer…

I would first need to explain where I was dissatisfied back in 2008. It was a pretty significant year for me, considering my main jam: AutoCAD. I had transitioned my way through AutoLISP and gained traction with AutoVBA programming and had began to peruse the ObjectARX SDK. AutoCAD had a foothold on dynamic blocks for a couple years, and had just introduced annotative objects and data extraction. These were big milestones for Autodesk and it positively impacted my work. And in my opinion, AutoCAD still had its own degree of identity… this was before it had adopted Microsoft’s ribbon user interface. Among all this geeky reminiscing… what I’m trying to express is that if I had any interest or investment in computer technology… it was in the realm of computer-aided design technology.

Actually… it still is, and that’s what makes this Linux satisfaction answer so complicated, because at the time, I couldn’t utilize the same CAD technology I was used to, yet there was a sense of freedom in using Linux.

I am very satisfied witnessing Linux evolve into what it is now, since 2008. Though, I remain dissatisfied to see that CAD applications haven’t evolved much. And it’s this reason why I maintain my desktop workstation with Windows 10; simply to utilize Autodesk software. But even admitting that I continue to run Windows 10 just for Autodesk software causes me to feel shame.

In my 8 years experimenting and familiarizing myself with Linux, I have become more familiar with the kernel concept and the different types of software licenses, and have consequently grown a huge respect and admiration for free and open source software. Throughout the same time, I have witnessed Autodesk products, AutoCAD specifically, evolve in parallel with Microsoft and increasingly bloat their software to a point where it seems adverse to what made AutoCAD so valuable in the first place. Really… what am I holding onto? In principle, I would rather uphold free and open source software. And in logic, I believe the more highly cohesive and loosely coupled software to be more efficient, valuable and functional. So specifically… why am I holding onto Autodesk products?

You could say, perhaps, it’s because my education and experience revolves almost entirely around Autodesk products. I certainly wouldn’t be where I am today if it weren’t for Autodesk doing what they’re doing and me following suit. You could also say it’s because organizations revolve almost entirely around Autodesk products too, and this certainly shouldn’t be taken lightly.

Or you could say it’s simply because Linux CAD applications bite.

And they do.

Not exactly a great way to begin making friendships with Linux developers… I certainly don’t mean to slight anyone or discount the time and energy that’s been placed into the open source CAD applications, but I believe that the Linux community has opportunity to do so much better. I believe the community is already better, and that Autodesk is providing the community a stage, considering the direction they’re moving. I simply wish the CAD FOSS reflected it. In fact, 8 years has shown me I need free and open source CAD software.

I am willing to move away from Autodesk products. I am so close. And that statement I made above, that shouldn’t be taken lightly; I really do believe organizations too, large or small, can transition to open source software in the right conditions.

If I’ve Learned Anything…

…it’s that I am alive when I am engaged.

I truly learn when I explore; when I ask honest questions. I find my passions this way, and it’s this performance which I believe best defines who I am.

I struggle with managing my array of interests and even more-so I’ve neglected the value of taking time to communicate my work.

So with my best intention to change that… here it comes.

© 2017 Drew Merryman

Theme by Anders NorenUp ↑