Every time I log into "my babies", I'm greeted by some ASCII art text. It serves two purposes:

• Let's me know which server I am on, very visibly
• Creates a sense of pride and ownership, having a flamboyent login

This is what it looks like:

To accomplish this masterpiece of engineering, I simply went to the Text Ascii Art Generator from patorjk.com, generated my desired text, pasted that into a file called .name. Next, it was just a simple edit of the .bashrc file in the home directory and have it spew out the contents of a file named where the ASCII art lives.

   cat .name

Ta da!

Responses[2]

Posted by Stu Thompson on 04 February 2010 21:47:37 CET #

While micro-benchmarking the performance of BufferedInputStream with various buffer sizes (both on my new fast SSD and a slow slow USB-attached HDD), the question came to mind "Has this default buffer size value changed over time in Java? And if so, who decides this? And where exactly is the line between a version of Java and a JVM."

My first instinct was to ask the boffins & peasants over at Stack Overflow: Where is exactly is the demarkation between a version of Java and the JVM? While some folks answered my main question, and one SOpedian (Joachim Sauer) went on to loosely answer my real questions, there was still not an absolute answer.

Time to take a trip down history lane via teh Google, and Sun's Java archive site.

So, how does that look in a graph?

Interesting. In following posts next month, I'll compare the default buffer size of BufferedInputStream with other seemingly relevant metrics, such as Moore's Law, storage bus speeds, and hard disk size over the years.

There are other Java implementations out there, and they have their own default buffer size. I'll keep this list up to date as I learn of new JVMs.

BufferedInputStream Default Buffer Size Series: Next

Add a comment

Posted by Stu Thompson on 31 January 2010 18:55:00 CET #

At xtendx we are big on simple, effective, and most things Apple. With an office of only a few people, we don't have the need or desire for a dedicated "IT Guy" and so those responsibilities generally fall on me.

Most of us are on MacBook Pros and have been handeling our backups individually at home when convenient. Recently, my colleague Mattia also started using a MBP, and a critical mass of support developed for bringing our backups "in house". To that end, we ordered three 1TB LaCie Grand USB-attached external hard drives (designed by Neil Poulton.) At SFr120 each (approximately US$122) from Digitec they were a fair price.

The original plan was to connect all three drives to the Apple AirPort Extreme base station and have each Mac's Time Machine backup over the network. No go. Constant errors like "Error 17 creating backup disk image" and "Error: (-8062) SrcErr:NO CopyingTime", Machine/System Preferences becoming unresponsive, and other drama. Big Apple #fail.

After three hours of tinkering and following many suggestions found on the Intertubes (downgrading the AirPort firm ware to 7.5.1, reformatting to a non-journel file system, and renaming the drives to conform to 8.3 naming convention), I gave up. The three disks now site near our desks and are attached directly via USB. Not as nifty, but it works and my time is valuable.

I like the blinking lights.

Here are some of the logs. Maybe if someone out there on the Interwebs has a suggestion then I'll try agin.

Starting standard backup
Attempting to mount network destination using URL: 
afp://xtendx@xtendx%20AirPort%20Extreme._afpovertcp._tcp.local/Stu's%20Time%20Machine
Mounted network destination using URL: 
afp://xtendx@xtendx%20AirPort%20Extreme._afpovertcp._tcp.local/Stu's%20Time%20Machine
Creating disk image /Volumes/Stu's Time Machine-1/Stu Thompson’s MacBook Pro.sparsebundle
Disk image /Volumes/Stu's Time Machine-1/Stu Thompson’s MacBook Pro.sparsebundle mounted 
at: /Volumes/Time Machine Backups
Backing up to: /Volumes/Time Machine Backups/Backups.backupdb
Ownership is disabled on the backup destination volume.  Enabling.
Backup content size: 129.6 GB excluded items size: 12.0 GB for volume Manoa SSD
No pre-backup thinning needed: 141.11 GB requested (including padding), 926.89 GB available
Waiting for index to be ready (101)
Error writing to backup log.  NSFileHandleOperationException:*** -[NSConcreteFileHandle 
writeData:]: Input/output error
Error: (-36) SrcErr:NO Copying /Applications/Stargate.Universe.S01E10.720p.HDTV.x264-SiTV.mkv 
to /Volumes/Time Machine Backups/Backups.backupdb/Stu Thompson’s MacBook 
Pro/2010-01-18-132728.inProgress/8289BDA1-B63B-4F3C-9277-936B11355DA5/Manoa SSD/Applications
Stopping backup.
Error writing to backup log.  NSFileHandleOperationException:*** -[NSConcreteFileHandle 
writeData:]: Input/output error
Error: (-8062) SrcErr:NO Copying /Applications/Stargate.Universe.S01E10.720p.HDTV.x264-SiTV.mkv 
to /Volumes/Time Machine Backups/Backups.backupdb/Stu Thompson’s MacBook 
Pro/2010-01-18-132728.inProgress/8289BDA1-B63B-4F3C-9277-936B11355DA5/Manoa SSD/Applications
Stopping backupd to allow ejection of backup destination disk!
Error writing to backup log.  NSFileHandleOperationException:*** -[NSConcreteFileHandle 
writeData:]: Input/output error
Error writing to backup log.  NSFileHandleOperationException:*** -[NSConcreteFileHandle 
writeData:]: Input/output error
Copied 16560 files (6.1 GB) from volume Manoa SSD.
Error writing to backup log.  NSFileHandleOperationException:*** -[NSConcreteFileHandle 
writeData:]: Input/output error
Copy stage failed with error:11

Responses[1]

Posted by Stu Thompson on 21 January 2010 12:40:08 CET #

Is your Windows 7/ Internet Explorer 8 browser magically renaming .air files (Adobe AIR applications) as zip files when downloading them from an Apache Tomcat server? Well, have not fear! Stu is here!

You just need to edit conf/web.xml file and add the following MIME type code snippet:

 <mime-mapping>
  <extension>air</extension>
  <mime-type>application/vnd.adobe.air-application-installer-package+zip</mime-type>
 </mime-mapping>

Now, just restart your Tomcat instance and the .air files will download as expected.

Add a comment

Posted by Stu Thompson on 13 January 2010 15:25:00 CET #

Earlier in the week I ran some micro-benchmarks against my new very performant Intel X25M solid state drive. Today, for 'kicks', I ran the same benchmarks with the same data against a 5,400 RPM external USB-attached 3.5" hard disk drive. Wow, what a difference that makes!

Destination Byte Array Size vs. KBps (for 16 different Buffer Sizes + the default)

(Larger Image)

Detailed description of the graph (same as previous post):

• x-axis: The destination byte array size used in individual read method calls as defined by payloadSize in this snippet:
  

      byte[] payload = new byte[payloadSize];
      int readIn = is.read(payload);

• y-axis: The speed in Kilobytes per second for a complete build up, file opening and reading, and the algorithm's computation.
  
• series (individual lines): Individual BufferedInputStream buffer size's as set with buffSize during class initialization.
  

      FileInputStream fis = FileInputStream(file);
      InputStream is = new BufferedInputStream(fis, buffSize)

For a slower disk, the conclusions are different only in the specific sizes:

One aspect of this entire performance question that I have not measured is the CPU load for these different operations. Hmmm...maybe for a new post...

Add a comment

Posted by Stu Thompson on 31 December 2009 17:21:00 CET #