ASCII Art Text for Remote Server Login Greeting
A silly customization that warms my geek soul
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 .nameTa da!
3TB of Time Machine Backup Storage for the xtendx Office
And a video with blinking lights to prove it
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
Adobe AIR MIME type for Apache Tomcat 6
Win7/IE8 will mischievously rename the file .zip if the MIME type is not set server side
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.
Optimal Buffer and Destination Byte Array Size for java.io.BufferedInputStream Reads (for a slow disk)
A continuation of micro benchmarking
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...
Optimal Buffer and Destination Byte Array Size for java.io.BufferedInputStream Reads (for a fast disk)
Micro-Bechmark Results on a MacBook Pro with an Intel X25M SSD
When implementing file reading Java code with Java IO's BufferedInputStream, what buffer size should one choose? Should we just not specific it and go with the default? And what destination byte array size is best?
These questions pop up from time to time when I have the opportunity to write such code. And I've seen folks ask similar questions on Stack Overflow and The Java Ranch. So, with my trusty new SSD drive, and a bit of spare time this holiday season, I set out to answer those questions.
The methodology for the below micro-benchmark results was simple: Graph the maximum speed of a simple algorithm with various BufferedInputStream buffer and destination byte array payload sizes. They algorithm was just as simple: add up all the bytes in a file. This is both computationally light weight and serves as a simple checksum (to ensure the consistency of my algorithm in with various parameters.) The code: OptimalBufferSizeSquentialReader.java
The target file read in these metrics was a 31MB video clip. To prevent the OS file cache from mucking up the results, there is a unique file for each buffer size + destination byte array size, for a total of 7GB in test data.
Destination Byte Array Size vs. KBps (for 16 different Buffer Sizes + the default)
(Larger Image)
Detailed description of the graph:
- 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)
An interesting graph. My conclusions:
- One generally cannot go wrong with a destination byte array size of 512 or 1024 bytes, regardless of what the BufferedInputStream's buffer size has been initialized to.
- BufferedInputStream's default buffer size is pretty well tuned, as long as one does not use a destination byte array size smaller than 8 or 16 bytes
- There is no point in having BufferedInputStream's default buffer size initialized to anything larger than 2KB. In fact, if an application is going to have many concurrent threads running this code (like in a web application) then large values will only wastefully consume memory, limiting overall scalability.
- The lower destination byte array sizes seem to have some sort of Sigmoid Function.
- My new SSD is freaky fast. ~130,000KBps is ~125MBps! Yeah, baby!
One thing I don't get is that the default buffer size is 8KB, but the 8KB series does not match the default series. Humph.
Update! I was curious aoubt two other aspects of the buffer size and destination byte array size, CPU load and the impact of speed of the disk. To that end, I've followed up with a second, similar set of metrics in Optimal Buffer and Destination Byte Array Size for java.io.BufferedInputStream Reads (for a slow disk)