Category: Technology

the 2014 mac pro – another gas outlet

whbeebe2 Comments

I started a small conversation with atmtx over on one of his blog posts. Andy’s post was about the 30 year anniversary of the original Mac. I remember the Mac, as well as its progenitor, the Lisa. I was working for Digital Communications Associates of Atlanta in the early 1980s (1982 to 1985). DCA was a company that sold digital communications gear, specifically statistical multiplexors that could tie terminals (and later, IBM PCs running terminal software) to minicomputers, especially the Digital Equipment Corporation (DEC) VAXen that were ruling the roost at the time.

In 1982 DCA purchased a small local Atlanta company called Technical Analysis Corporation (TAC), whose claim to fame at the time was the IRMA Board, a full-length IBM PC card that turned the PC into an IBM 3270-alike terminal. DCA was looking to diversify, TAC needed capital to expand, and TAC with its Irma card seemed a good fit into a growing telecom gear company. There would eventually be software that allowed software running on the PC to basically screen scrape, not just turn the IBM PC into a dumb terminal. This would then hook into other applications (or so the thinking went) allowing for a crude way to integrate IBM mainframe applications into PC applications.

When TAC arrived at the DCA offices they brought an original Apple Lisa with them. The original with twin floppy drives. That big honking system that cost a cool $10,000 dollars. I don’t remember what the Lisa was being used for, all I remember was seeing a machine with the Apple multi-colored logo stuck to the front, and it weren’t no Apple II. Since I was just a field engineer (a mere peon, not a vaunted software engineer at the time) I was only allowed to look, but never touch. TAC would eventually buy the new Mac, and integrate the Irma to the Mac by building it into a flat pizza-box size housing that the Mac sat on. Tow cables came out of that Irma, one to the Apple and the regular coax cable to connect to the IBM 3270 terminal port.

Anyway, all this was triggered by reading about Apple’s 30th Mac anniversary, which led to the video at the top of the post, and the latest Mac Pro, which costs – get ready – about $10,000 when fixed up into something decent. Think of it as the Lisa reborn. Except this time, instead of a paltry 5MHz Motorola 68000, we have multi-core Intel Xeon processors and nVidia GPUs with hundreds of cores, capable of driving 32-bit color panels with 4K and higher resolution. And the networking that little machine is capable of allows the attachment of devices undreamed of in 1982, when the original Lisa was released. So, it might cost the same amount, but this Mac Pro ain’t your daddy’s Lisa. Not by a long shot.

One more bit of history: the Irma used the SMS/Signetics N8x305 microprocessor chip, a very peculiar 8-bit micro that was blazing fast at the time (10MHz) and optimized for signal processing. It handled the video and communications between the computer and the IBM mainframe terminal system. It was a big chip, power hungry, and recognized as a dead end even back then. It was originally selected at the time as the only reasonable solution for that type of product. I left DCA in 1985 after moving to Florida, and DCA was purchased by Attachmate in 1994, long after I’d left.

That turned out to be a bad idea, as two years later a clash developed between Attachmate’s management and former DCA management (still in place), which led to a corporate implosion of sorts. I don’t know what happened after that as it was the mid 1990s and I was heavy into wireless telephony. Attachmate survived, and eventually went on to buy up what was left of Novell and SUSE Linux in late 2010. In an odd way, my history intertwines with Attachmate via my first engineering company (DCA) and one of my former favorite Linux distributions (SUSE). These days I live in a world of modeling, simulation, and robotics and the Linux I use is either Ubuntu or an occasional foray into Fedora/RHEL. It’s a funny old world…

GAS stands for Gear Acquisition Syndrome, an affliction well known to enthusiast photographers. Buying computer gear is every bit as expensive as buying digital camera gear, and they insidiously conspire with one another to double dip into your wallet. After all, you need that beefy computer to post process those beefy raw files coming out of that beefy camera system you just purchased. Right?

One more memory: It was DCA/TAC that introduced me to C, specifically Lifeboat C, on an IBM PC XT. You needed the 5MB (yes, MB) 5 1/4″ full-height drive not just to hold all the tools, but to have a computer fast enough to be productive. The definition of slow as molasses in winter was developing on a floppy-only IBM PC.

mixing technologies – weekend edition

whbeebe

So. It’s late Saturday night, and here I sit in front of my little hackerish Ubuntu notebook. The clock just rang out midnight, meaning I’m rolling with this into Sunday, and I’m typing away while listening to Depech Mode’s “The Best Of” on Youtube that somebody in Russia ripped and uploaded. Yeah.

It’s been a long three or four days since I first wrote about starting out with Open Street Map, and it’s like I’ve been in a long, drawn-out fist fight, where the punches keep coming in from out of nowhere and I can’t land any of my own. That map above, with the southern states in place from Georgia west to Arizona, took me the majority of the time figuring out how to load.

Now, I haven’t been spending all this time on this task; I do have A Real Job. I’d take time off during a lunch and spend about 30 minutes on it, then spend another hour after getting home and after everything was done for the evening before hitting the sack. Even so, I never expected this kind of slow going.

Biggest problem is in the directions. Remember that page that was so helpful with its simple directions? Turns out it was too simple, and here’s why. At one point you need to load a file using the following command (this is for Florida, which is where I started to build my map of CONUS):

osm2pgsql –slim -C 1500 –number-processes 4 florida-latest.osm.pbf

That command loads the latest Florida map into the database. So far, so good. The problem is that if I use the same command to load any other file, it wipes out any other data. That’s when I found out about the “–append” command line switch. Sweet. Just add that to the rest of the commands to load the rest of the states and I’m done. No, not sweet. When run, I’d get the following error message:

failed: ERROR: duplicate key value violates unique constraint “planet_osm_rels_pkey”

I tried all sorts of ways to get around this, including the implied method of importing all my map files at the same time by placing all the file names on the command line, separated by spaces. That didn’t work either. Finally, while cruising through this forum on github I found out you needed to drop the “–slim” command line switch. WTF? When I did that with the Georgia file, all the other files loaded, and when it was all done I had the basic map you see above. I noticed something interesting about the slim switch. If you read the documentation, it seems to imply that using slim is actually faster than not using it. Not on my system. Leaving slim off actually sped things up a bit.

Note that I got so desperate to load anything in CONUS that I downloaded the 5GB map file of the entire continental North America and attempted to load it. I downloaded that late Friday, and started it up around 6pm. It ran through the night, and continued until I killed the whole thing around 3pm Saturday. That’s when I gave Google another stab at trying to find a solution. I did try DuckDuckGo, but it failed spectacularly in trying to find a solution; it gave exactly two (yes, I said two) hits. Google gave me page after page, and it was literally the first entry that gave up the vital clue about the use of slim. Google 1, DuckDuckGo 0.

Other issues I’ve had with my Open Street Map stack is getting it to generate all the necessary tiles at the default resolutions. I’ve been doing it the hard way with “/dirty” on the end of the map graphic. For example, in Chrome, selecting “Open Image in New Tab” gives you a new tab with “http://localhost/osm/5/7/12.png” in the address bar. Modify the URL to “http://localhost/osm/5/7/12.png/dirty” and hit return, and OSM responds with “Tile submitted for rendering“, and after a bit of time it will be rendered. I did this on a lot of blank tiles, then setting Permalink on that section and hitting refresh until it showed up. This is a royal pain, and no amount of searching calls out clearly what tool needs to be installed and/or run to generate a series of default tiles. I will find out how to do this, as my very labor intensive method sucks dead hamsters through a garden hose.

Here’s a few more screen shots showing the detailed maps I have so far.

The browsers used are, from top to bottom, Opera showing Austin Texas (West Sixth Street and the Colorado River), Firefox showing Orlando Florida (I-4/408 interchange and Lake Eola), and the JavaFX in Java browser showing the states of Tennessee, North and South Caroline, Georgia and Alabama. I’ve started to hack the original JavaFX demo application, having reversed the tab order and setting the default URL to point to the OSM slippymap page. The next step is to build a PostgreSQL viewer into the second tab so I can browse the GIS tables that hold the OSM map data. Before I do anything else I’m dumping the database to back it up. I want to add the rest of the continental US states, and maybe a few of the Canadian cities like Toronto.

While I was at it I also pointed my Nexus 7 2012 tablet, running KitKat, at the OSM stack, just to see how it rendered on an Android tablet. I have my reasons. My systems are wirelessly connected so it wasn’t any big deal to punch in the IP of the Ubuntu system along with the default slippymap URL and give it a go.

Both of these screenshots were using Opera. I have to say that I really enjoy using Opera on my Samsung Galaxy S4 (Android 4.3), Nexus 7 2012 (Android 4.4.2) and even my Barnes & Noble Nook HD+ (Android 4.0). It seems to be fast and use a minimal amount of memory. I like the Speed Dial page, especially on the phone. The only problem I had rendering my local OSM map was with Firefox, as you can see below.

I don’t know what’s happening here, but dragging the map around caused it to tear apart. I don’t know why that happens, but I won’t lose any sleep over it. Firefox does just fine with Google Maps and the commercial implementation of OSM, so it’s definitely something in the current installation. Since I need to make all Javascript references on slippymap local, I hope dropping the latest versions of OpenLayers and OpenStreetmap will fix that issue. Speaking of commercial implementation, I came across this courtesy of DuckDuckGo:

Yes, it’s MapQuest Open, but this site is using Open Street Map data as explained here. Looks kinda pretty, don’t it? Anyway, that’s it for the evening. It’s now past 1 AM, and I’ve had enough excitement for one weekend.