macOS Technical

Upgrade to 2016 Tech Bumped Mac Pro

  If you read the Op-Ed piece I wrote back in November of 2016, after deciding not to repair my late 2008 model Mac Pro and switch to a Windows 7 desktop “Is The Mac The Amiga Of Today – Part II”  You might have thought I had left the Apple ecosystem for good.  

The reasons that I had decided to try a PC.

• Apples poor decision to abandon Aperture, my photo management application of choice and it’s poor replacement ‘Photos’.
• Slow updates to the Macintosh hardware line.
• UI Changes within OS X that I found needless and cumbersome.
• Needlessly removing support for Late 2008 Mac Pro in OS X Sierra.
• Replacing ports on Macbook Pro with all USB-C, and removing MAG SAFE power connector.

I “upgraded” to a Dell Optiplex 9020 running Windows 7 Ultimate, and even tried a couple of tablets, the Dell Venue running Windows 8.1, and the Microsoft Surface Pro 3 running Windows 10.  I had issues with both products.  I will not get into why Windows 8 sucked, as this still born Microsoft product has been beaten to death over the years. 

The Dell Venue was just a terrible cheaply made product!  The hardware never worked properly, and the power adapter would only actually charge the tablets when the planets were properly aligned.  The Surface Pro 3 did fare better, though I also thad problems with the adaptor and had to replace it. Updating Windows 10 also caused the built in web cam to stop working twice!  Requiring complete reinstalls of the OS.  It does not say great things about your products, if your drivers do not work with your own hardware.

Now I had planned on eventually upgrading  to Windows 10, but kept putting it off due to security concerns, I really did not relish the thought of Microsoft collecting usage data, including keystroke logging being collected. Apple collects telemetry and error log reporting as well, but at least I can opt out!  So I decided to give OS X Sierra a “fair” shot for a couple of months, and then possibly choose to go back to the Mac. 

Actually I lie!,  the comparison would not really be fair, as the Mac I was going to base my decision on, was the Mac Mini!  While the processor and RAM specs were similar, the Optiplex had the benefit of a discrete video card, which allowed Lightroom to take advantage of hardware acceleration.  Even with these performance caveats stacked against the Mini I was really impressed with how the Mini performed for my blog work, and other daily tasks.

Except for a slight lag loading photo’s in Lightroom, the system was very usable and for the majority of people out there the system would be more than adequate for day to day use.  Certainly within the realm of intended purpose of the Mac Mini. 

The other issues I had with OS X Sierra I discovered work arounds after abit of research.  Issues such as being able to minimize of maximize windows (without toggling full screen) by double clicking on the windows title, disabling gatekeeper, and other little odds and ends.  I also discovered the wonders of the Homebrew repository, and was able to install BASH v4, an updated version of Nano, and my favorite top utility ‘htop’.  I was having too much fun using a Mac again!

The only problem I had with the Mac mini when working with  multiple virtual machines, the 16GB RAM limite and the slower disk performance of FW800.  Due to the fact I was running dual displays and the only Thuderbolt port was taken up by the second display, there was no room to update.  I realized what I was going to need a new Mac.  The only problem was that Apple definitely limited my choices. 

After owning a Tangerine iMac back in 98 (Which at the time was a great computer), until the analog board went out after a couple of years, and the replacement boards never worked right.  I swore I would never again own an all in one computer again!  Not from any manufacture!  That left only one choice, a new Mac Pro.  I waited to see what Apple was going to do with the Mac line after the 2017 WWDC. 

I am excited that it looks like they will be continuing the Mac Pro line.  It is a GREAT workstation.  I also knew I could not wait a year for the new modular Mac Pro to be delivered.  So I decided to plunk the cash down on a new Tech Bumped 2016 Trashcan Mac Pro instead.  Thinking when the new Mac Pro is released I can always sell it.

Here are the specs of my Mac Pro

Mac Pro (Late 2013)
3.5 GHz 6-Core Intel Xeon E5
32GB 1866 MHz DDR3 Ram
512GB SSD
Dual AMD FirePro D700 6GB Video RAM
After using the Mac Pro for a month, what do I think about it?

It is blazing fast, where the Mac Mini took a minute and 4 second to boot, the Pro spring to life in 19 seconds!  Lightroom smokes along with virtualy no lag in loading photos and rendering slide shows is noticeably faster.  As I have mentioned in the past I do not do allot of work with video, so I will have to come up with a reason to try out Final Cut Pro!

Where the Pro really shines for me right now is when running virtual machines.  As I can now run 3 fully featured VMs with 8 GBs of RAM allocated to them and still have 8 GBs free on the host OS, so there is very little performance degradation.  So be expecting more Windows and OS X tutorials in the future!

What additions or upgrades do I have planned?

Once the dust settles, and the hole in my wallet gets alittle smaller, I do have a couple of upgrades already planned for the Pro.

• Thunderbolt RAID2 chassis
• External Blu-Ray Burner
• Upgrade the internal SSD from 512GB to 1TB

Mac Pro (From The Front)

Mac Pro (From The Back)

Inside joke started on Facebook with my 2008 Mac Pro.

Is the current MacPro for everyone?  NO!  Especially since Apple has announced the new iMac Pro.  There are serious form factor issues as I have already openly stated on my blog.. However currently The Mac Pro is the most powerful offering from Apple, and it is doing what I need it to do until the new Pro desktop is released.

Hard at work on the blog using my new Mac Pro.

Thank you for visiting Brent’s World, and American Expat Living and Working In Korea!  I hope you enjoyed this weeks technical blog, and will continue to return for more exciting articles!  If you with to be notified by email when new content is posted, please register by clicking HERE!

MAC OS X

Compiling CG Term To Connect To Commodore BBSs via Telnet using Commodore Color Graphics.

  UPDATE!! – I am keeping this blog for instructional purposes on compiling source code in Mac OSX.  There is a pre-compiled version 1.9 in an app package available at the following link https://roxburysoftware.com/Blog/cgterm-for-os-x-10-9/ that supersedes the need for these instructions.

Time sure does fly!  Getting the inspiration to write this month’s technical blog I reflected on the exclusive article I wrong back in November of 2014.  It seems like only yesterday that I put that article together.  If you have not had a chance to read NO CARRIER!  The Lost World Of The BBS, you may do so by clicking here. The terminal program that I recommended, CG Term 1.7 unfortunately no longer works on Mac OS X versions later then 10.10 (Yosemite).  You may download and try SyncTerm, but I have found that it does not properly decode the PETSCII (C/G) graphics correctly.

  So what are us Mac users to do?  We could either use a Windows virtual machine, or boot into boot camp.  However that kind of rubs the wrong way, especially since CGTerm worked in previous versions of Mac OS.   There is a third option, and that is to take the freely available source code and compile it in a later version of the OS.  I have compiled it on my OS X Sierra desktop and 2010 MacBook Pro running Yosemite.

This is a 4 step process.

1. If you are not already using the Homebrew repositiory and installed brew, follow the instructions by  Clicking Here.
2. Download and extract the source code for CGTerm 1.7b2 beta (Version 1.6 also has C/G translation errors.) Click here to download.
   1. 1. If you do no not already have one, I would create a dev directory in your home directory.
         1. $ cd ~
         2. $ mkdir dev
      2. Move the downloaded files to the directory you just created.
         1. $ mv ~/Downloads/cgterm-1.7b2.tar ~/dev
      3. Extract the files 
         1. $ cd ~/dev
         2. $ tar -xvf cgterm-1.7b2.tar 

 3. Install sdl headers (SDL.h) from the brew repository if not already installed.
            a. $ brew install sdl4. Compile the software.

 
Normally we need to run 3 commands to compile source code, however I only had to do two for CGTerm.  These commands are

1) ./configure (Not needed for this install.)
2) make
3) make install

There is no configure script for this source code, so if you try and execute it you will receive an error, so let’s move on to step 2.

Make sure you are in your ~/dev/cgterm-1.7b2 directory by typing at the shell prompt
$ pwd   

If you are not, type.
$ cd ~/dev/cgterm-1.7b2

Now we will create the make file. Type
$ make

If all goes well, you will see a screen that looks like this.  Ignore any warnings.

now lets compile the .app files.
$ make install

You will see the following output if successful.

Lets now perform a directory listing specifically to check if we now have the 3 CGTerm executable files. (NOTE: Without configuring your shell to colorize the output, it can be difficult to find the executables in the listing.  I recommend following the link at the bottom of this blog, which will walk you through how to get colorized directory listings like Linux.)

ls -l cgchat cgedit cgterm testkbd

Finally let’s perform some housekeeping tasks, since we do not need to keep the source files around.

First lets create a new directory in the /Applications folder, then we will copy the newly compiled executables to that directory

$ sudo mkdir Applications/CGTerm-1.7
$ sudo mv cgchat cgedit cgterm testkbd /Applications/CGTerm-1.7

It is up to you if you want to keep the source files around, in this example I do not, however I will keep the compressed .tar file

$ rm –r ~/dev/cgterm-1.7b2

Perform a final test by either changing working directories in the terminal to /Applications and launching CGTerm, or launch from the finder.

$ cd /Applications
$ cgterm

Once your newly compiled CGTerm opens and you see this screen let’s connect to a BBS.

Type ESC
Type D

When you get the Connect to host [port]: box, type

cib.dyns.org 6400 <ENTER>

You should now be connected to the Commodore Image BBS

When launching from the finder, Mac OS will launch a terminal session, this is normal.

I hope you have enjoyed another Mac OS tutorial, and compiling your first application from source code!  Please try connecting to the following BBS’s running on a Commodore 64 using your newly compiled app.

Commodore Image – cib.dyndns.org:6400
Lowdown BBS – lowdown.servebbs dot net:6401

** I highly recommend coloring your directory output, it makes differentiating between Directories, Text files, and applications allot simpler.  To enable colorized directory output in Mac OS X, please CLICK HERE.

*** PLEASE NOTE!  All traffic sent via TELNET is sent in plain text, when connecting to BBSs using CGTerm or other telnet applications, DO NOT use passwords that you use for any other services.  Such as financial institutions or online shopping!

OS X Technical

Installing GNU-sed using Home Brew repository

   Last month’s technical article focused on adding BASH 4 to OS X using Home Brew, because OS X ships with BASH v3.257 due to GPLv3.0 licensing requirements.   You can read the article here.  https://www.catracing.org/hendrb/tech-tutorial-adding-bash-4-osx-using-home-brewos-x/.  This month I will share some more tips  that will make your shell experience more compatible with Linux scripts by adding GNUsed,  First some background then we will fire up the terminal.app and get started!

  Back in 2015, I published article containing a type in yourself BASH script that will display random quotes from a file called ‘quotations’ that I converted from a CNET Amiga BBS plus file (Door, or external for the PC BBS SysOps).  (Click here for article.) While it ran great on Linux boxes, due to differences in the BSD-sed (stream editor) utility, which is  used to parse the blocks in the text file containing the individual quotes then centering them depending on the width of your terminal window.  Would work on a Linux box, but fail with an error on OS X.

(As you can see the script runs fine in CentOS Linux)

(The script failing in OS X with the ‘expected context address’)

  After upgrading to BASH 4 using the Home Brew repository I discovered you could also install the GNU version of the sed utility which would allow me to run my script error free without writing 2 versions of my script.  Which brings us to the purpose of this blog, installing GNU-sed from the Home Brew repository.

  There are 2 way we can install this from the repository, one method will install the files renaming GNUsed to gsed. Which will allow you to either call ‘sed’ (BSDsed), or ‘gsed’ (GNUsed) as needed from your scripts.

Method 1 :

Enter the OS X Terminal (SHIFT – COMMAND – U) Then launch the terminal.app.

You must be in an account with elevated privledges (NOTE: You can NOT sudo)

            If logged in a normal user account (Which you should be!), Type the following at the terminal prompt.

$ su – <username>

            The – option tell the terminal to switch users and load the environment of that user.

             At the Shell Prompt type

$ brew install gnu-sed –with-default-names

The Brew repository installer will install sed into /usr/local/Cellar/gnu-sed/4.2.2/, and create a symbolic link for  /usr/bin/local/sed to that directory

Now when you use sed, it will use GNU-sed instead of BSD sed.

You can revert back to BSDsed by removing the symbolic link in /usr/local/bin.

$ rm sed

You also need to remove the symlink to the man pages /usr/local/share/man/man1

$ rm /usr/local/share/man/man1/sed.1

NOTE: This does not remove the files only the symbolic links!
To permanently remove GNU-sed from your computer, simply type the following with your elevated account.

$brew remove gnu-sed

Method 2: Installing GNU-sed so it can be installed concurrently with BSDsed (dogs and cats living together.)

Let’s say that we wanted to install GNU-sed but for whatever reason (Such as compatibility), you wanted to install GNU-sed and have it reside on the system concurrently with BSDsed!  Or give your users the option to choose which version of SED they want to use by default.  This is quite simple to accomplish. 

Enter the OS X Terminal (SHIFT – COMMAND – U) Then launch the terminal.app.

You must be in an account with elevated privileges (NOTE: You can NOT sudo)

            If logged in a normal user account (Which you should be!)

            Type at the terminal prompt.

                        $ su – <username>

            The – option tell the terminal to switch users and load the environment of that user.

At your elevated prompt type.

            $ brew install gnu-sed

The brew repository will install gnu-sed in the same dictory as method 1, but it will not create symbolic links for sed, or the sed man pages.  You now have BSD-sed ‘sed’, and GNU-sed ‘gsed’ on your system!  Type it our, type $ man sed, and $ man gsed at a terminal prompt!  Scroll down to the last line of the page and note the difference!

If you are writing scripts that require the use of GNU-sed for your own environment just remember to use gsed,  if you need to run scripts written for Linux machines, you may want to consider writing a launching scrip that aliases sed to gsed and then removes the alias upon exit.  This can be done like this.

#!/bin/bash
# OS X Launcher for randquote.sh
# You MUST have gnu-sed installed from homebrew to use
# aliases sed to gnu-sed for linux bash script compatibility
alias sed=’gsed ‘
source ./randquote.sh
unalias sed

(Executiing randquote.sh with the launching script above, note that I needed to execute the script using the source command, instead of launching it using ./filename.sh)

In order for aliases to work inside a shell script, you must execute the script using the source command, not with the simple .\ from the command prompt.  Your other option is to use a text editor and replace all incidents of sed with gsed manually. 

Unless there is a specific reason option one will not work for you, I highly recommend installing GNU-sed with the –with-default-names option.  It will save extra steps and headaches down the road, and can always be easily removed if you suspect compatibility issues.

I hope you enjoyed todays OS X Terminal tutorial, please let me know if you found this interesting! Until next month, don’t stop exploring and be safe on the digital playground.