This is admittedly a niche need, but it comes in handy at times. For example, when running a headless install, or in a constrained environment such as a continuous integration server. In such cases, there's no need to have the overhead of the GUI and all of the processes it starts up.

I'm trying to set up a continuous integration farm with VMs for each major OS revision and memory gets pretty tight on my Mac Mini "server". Since I'll be running the builds unattended, there's no real need for anything other than SSH or terminal access. The default VMWare settings for 10.9 are a 40GB disk and 2 GB of memory. Once more than one VM is running, things really start to slow down because of swapping and the like. Perhaps disabling the GUI will free up some memory and CPU cycles.

For example, on my fairly vanilla macOS 10.12 VM with a user logged in and a terminal running:

1927M used (432M wired) 120M unused.

And on the same machine with a user logged in but without the GUI running:

 1348M used (279M wired) 698M unused.

That's a significant amount of additional free space (let's not get into why a base OS should use so much memory in the first place… it's likely a case of death by a thousand cuts).

Enabling terminal mode login

The process is pretty basic: we need to disable the graphical login interface and turn on a standard UNIX terminal login process. Somewhere around OSX 10.5, Apple introduced launchd, which changed the way the system manages daemons and the login interface, so a lot of the tutorials that described this process on 10.4 and earlier will no longer work.

Luckily for us, it's not so hard to get working with newer versions, and Apple has provided a launchd definition for this that just has to be enabled:

• com.apple.getty

    <key>Disabled</key>
    <true/>

to

    <key>Disabled</key>
    <false/>

Turning the graphical login interface off is almost as straightforward. The following services need to be disabled:

• com.apple.logind
• com.apple.loginwindow

• /System/Library/LaunchDaemons/com.apple.logind.plist
• /System/Library/LaunchDaemons/com.apple.loginwindow.plist

    <key>Disabled</key>
    <true/>

Once you've done this, restart your system and it should come back up with a text mode login prompt.

Note: On systems running 10.12 and 10.11, SIP will prevent you from modifying these system files, even as root. To get around this, you need to do the following:

1. Boot into Recovery mode with a Cmd-R at startup (or boot from an install DVD) and run

    csrutil disable

2. Restart and make the modifications above.

3. Boot back into Recovery mode and run

   csrutil enable

4. Finally, boot back normally.

Note: I've verified that this works beautifully on MacOSX 10.9 Mavericks and 10.10 Yosemite. It does not seem to work on 10.12; the login prompt is displayed but no input is accepted from the keyboard. I think this is a system bug because the old trick of using >console as the username to get a text terminal behaves the same way in 10.11 and 10.12. I am certain that if Apple fixes the problem with getty, this technique will work here as well.

Update: I spent some time on this and it seems that if you disable com.apple.configd and com.apple.hidd, the login works. I noticed that a lot of commands (such as ps and who) hang, so it's possible something else needs to be disabled.

On a final note, it's probably best to assume that all kinds of services won't work properly in this setup, such as software updates and iCloud syncing. But really, you were likely not interested in such things anyway, right?

In order for the computer interface to work properly, it needs to know when the casting machine is ready for a signal. As originally designed, the computer control system for ’Monotype‘ composition casters used a reed switch to detect the machine's cycle position. A reed switch closes, or turns "on", when a magnet moves close. Similarly, the switch opens, or turns "off" when the magnet moves away. In keeping with my somewhat arbitrary rule of "no caster modifications", this reed switch is (quite literally) clamped on the caster's air tower, and activated by a magnet attached to the rod that activates the air bar clamp. When the caster is in good operating condition, and none of the fancy attachments are being used, this system works fairly well.

Students of ’Monotype‘ equipment know that the engineers at Lanston Monotype were incredibly precise, and they left very little room for error when they designed the equipment that we're now effectively hacking. As a result, the extra length of air line that the computer interface introduces to the system is just enough that the machine isn't always able to respond to the air signals in time to act on them. The result is that signals are occasionally missed. This is especially true of machines with 15x17 mat cases or unit shift: the extra valve boxes that allow codes to do double duty cause delays that push things over the edge.

The first attempt to improve the situation involved a modest change. The sensor was repositioned to the cam lever that operates the air bar clamp. This gave a little more wiggle room, because the cam lever operates over a fairly wide arc, allowing the reed switch to operate a little sooner. Ultimately, though, the whole approach was hindered by the fact that the cam only produces an air pulse timed to the use of a paper ribbon. We needed more flexibility in order for the system to work reliably in all situations.

The solution turns out to to be quite elegant: a transparent disc is attached to one of the machine's camshafts. The camshaft, and by extension the transparent disc, rotates once for each cycle of the machine. A section of the disc is made opaque, and an infrared sensor is placed over the outer edge of the disc. The infrared sensor then detects the opaque segment as it rotates past, causing the air valves to send air to the caster.

The optical sensor in place on a caster

There are 2 aspects of the air pulse that are of interest to us: the time the pulse begins, and its length. The exact moment that the air valves are turned on can be controlled by rotating the disc in relationship to the sensor. For example, moving the disc forward in the direction of rotation causes the opaque sector to arrive at the sensor a little earlier. Similarly, the length of the air pulse can be controlled by controlling the width of the disc's opaque sector. The transparent disc is made up of a set of overlapping discs, each with an opaque section. Sliding these overlapping discs relative to each other allows the width of the opaque section to be varied, causing the air pulse to be shorter or longer.

Now, with the new optical cycle sensor, we have complete control and simple control over the timing and duration of the air pulses to the casting machine. A few hardy souls, including Nick Gill at Hand & Eye Letterpress have been testing the new approach out, and the initial reports back are good. An added bonus is that unlike the previous reed switch, the new sensor has no moving parts to wear out, which should improve reliability.

The new Optical Cycle Sensor is available for retrofit on existing computer interfaces, and will ship standard on future interface installations.

Following the conference, I stayed in town for Thompson Tech III, in an attempt to get more comfortable with the machine that's been lurking in the corner of the shop for two years. The class consisted of myself and David Smith, as well as the illustrious George Hamilton and Stan Nelson. It was great fun getting to work with everyone, including Sky and Johanna Shipley, our gracious hosts. The long evenings of fascinating stories told by "around the campfire" would have made the trip worthwhile on its own, but to top it off, we were casting good type all week. Overall, the week went very smoothly (I was the only one to have had any drama, a very mild burn on my arm), and I'm feeling pretty good about the possibility of getting my Thompson up and running in short order.

An interesting twist is that Martin (who's been helping with this project for a while now) and I are planning on setting aside proceeds from the sale of the book to fund Pike development and marketing projects. That means that, in addition to getting up to speed on your favorite programming language, you'll also be helping to advance and promote Pike.

I expect the book to be available at online outlets such as Amazon or Barnes and Noble in about a month. Until then, you can get your copy from Lulu, our printing vendor for USD 29.95. In addition to getting your book sooner, Lulu's commissions are lower, meaning that a larger percentage of your purchase price will be made available for supporting the Pike community.

Learn more about the book, and purchase your copy today by visiting:

http://book.gotpike.org/

Enter Stomp…

Stomp is a text based protocol designed to be easy to implement, yet full featured. The protocol supports text and binary messages of arbitrary length and the Pike client supports asynchronous message receipt. I wrote a client for Stomp a year or so ago, and used it a bit, but recently spent some more time working on it. Newly added features to the Stomp client include reconnection and off line message sending for more reliable behavior.

Through the use of the Pike Stomp client and StompConnect, you can connect your existing and new applications to enterprise messaging buses such as ActiveMQ or MQSeries. This opens up a whole world of possibilities, ranging from integration to transaction processing.

Additionally, I added support for Stomp (and possibly other asynchronous messaging systems as well) to the Fins framework, making it incredibly easy to write applications in Pike that utilize Messaging. I'll be posting some examples of how to use Stomp with Fins over the next few days, be sure to keep an eye out for them.

For those of you that may have missed the original announcement, this year's Pike Conference will be held in beautiful Riga, Latvia, from October 18 through the 22nd. Riga's old town was named a UNESCO World Heritage Site, and getting to and from Riga has never been easier. For more information, send an email to the conference coordinators at conference at gotpike dot org, or visit the conference website at:

http://conference.gotpike.org

If you know you'll attending, but haven't registered yet, please take a moment to do so now, as it allows the conference team to better plan activities to suit your interests and schedule. Also, we still have spaces for participants; so if you'd like to make a presentation, suggest a topic for group discussion or just want to say a few words in person, do let us know, as we'd love to include you in the program.

I'm personally very excited about getting to meet everyone (again, even). We always have a good time and a lot of good information is passed around. If you're thinking that maybe you'd like to get more involved with your language of choice, you probably won't find a better chance to chat with like minded folks. Additionally, I've got some very cool things to talk about, so I hope to see you in Riga!

Even more interesting are the possible modding opportunities. By appearance, the whole affair seems like a webcam strapped to some high power optics, but that may be over-simplifying the situation. This tool would be useful for all kinds of work, including comparison and measurement. The resolution is a little low, but someone suggested that it might be possible to rig up a digital microfilm reader (or scanner, even.

First, in the eye-candy department, I started working with Dojo 0.3.1, which has some better widgets than previous releases. It adds some quirks, especially with the DHTML effects, but hopefully we'll be able to work through them. I also added a new widget called RTEditor, which extends the Rich text editor widget to be tabbed: one tab is allows you to edit text in Rich Text format, and the other tab lets you edit the raw text. As you change from tab to tab, the version from the other tab is brought along with you, so you don't lose content. It's pretty neat, and lets users who are more comfortable with HTML tweak their content.

Second, on the Fins side of things, I've added some developer admin tools. We're hooking into the pike -x command, and so far, a new application creation tool is available, as well as a replacement for fin_serve, which should make it easier to run your Fins apps.

Most significant, though, is automatic configuration of Model objects by examination of the database schema. This means that if you write your database to follow the rules that Fins expects, you don't have to write Model code. It's all done for you… just create a (more or less empty) class for each datatype, and Fins will handle the rest… it's pretty cool. It's also completely optional. If you've got legacy databases to work with, Fins can also use those, but you'll have to resort to increasingly manual tactics.

FinScribe is built on the MVC framework I've been writing, called Fins, and is written in Pike with support for mysql, sqlite and (hopefully) postgresql. Originally intended as a demonstration application for that framework, FinScribe has taken on a life of its own.

It's been a busy few months; we finally finished the floor in the foundry area after winter set in early. A new entrance door was cut in the concrete wall in order to allow equipment to be moved in. We moved the two English casters in May and they're awaiting a plan for getting them off their pallets.

About the time we were moving things in, I got a call about a Thompson typecaster down in North Carolina (at Heritage Letterpress, who was in the process of shutting down their hot metal operation). I went down with Ian Schaefer who was picking up a composition caster. We pooled our resources for the big move and spent all night driving the truck back to Pennsylvania. We also got lots of spares and some nice composition and display mats. I've also started a Matrix Inventory to keep track of what faces and sizes I've got. There are still a few faces that I have mats but no wedges, so I'm still on the lookout for those. If you've got spares, drop me a line!

Finally, I have a first pass at a keyboard emulator up and running. This piece of software is designed to fix a lot of the shortcomings of working with the standard pneumatic keyboard, yet still retain the flavor of working in a traditional way. It will output files that can be sent to the caster driving software (not quite written yet) for final casting. Eventually, I'll adapt the keyboard sofware into something that can take a standard text input file and turn it into an "e-ribbon" for casting.

I guess that about sums up the latest happenings; lots of stuff going on, and I'm excited about finally getting some of these projects wrapped up!