Using Minecraft Texture Packs on OS X

Do texture packs work with Minecraft on the OS X platform? Yes, yes they do. Is it as simple as dropping the file(s) into ~/Library/Application Support/minecraft/texturepacks? No, no it isn’t.

After searching for several weeks on this (it took so long because I was avoiding all the youtube videos) I finally found the solution. Here is how to use texture packs on OS X:

  1. Download your chosen texturepack
  2. Open your Downloads folder using Finder
  3. Go into, or open, the folder created when the texturepack was unzipped during the download
  4. Select all files (cmd+a)
  5. Right click the selected files
  6. Click the menu entry labeled ‘Compress # Items’ where # matches the number of files selected
  7. A file named Archive.zip now exists in the folder
  8. Rename Archive.zip to a more appropriate name

At this point your texturepack is now ready for use. Copy it into ~/Library/Application Support/minecraft/texturepacks and start minecraft. The listing in ‘Mods and Texture Packs’ should be in color, indicating the texture pack is ready for use.

 

Crib Notes: Pimp Your Mac with Perl

Title: Pimp Your Mac with Perl
Speaker: Mark Fowler
Photobox
All slides are on site. Highly recommend reviewing them.
Apple standard perl is seriously broken.
pbcopy/pbpaste for clipboard interaction from cli

growl integration

Numberous Perl modules to do this
          Cocoa::Growl
          Growl::Any
          Mac:Growl
          Net::Growl
Once used your script appears in the growl preferences for configuration.

OS X Automation

Mac::Safari::JavaScript
Use ThisService to create a Mac Service(free)
Keyboard shortcuts tend to collide with other apps.

Doing things Automatically

Example of tidying Downloads folder
launchd
        uses plist format, a variant of XML
        ~/Libary/LaunchAgents to run at login
fsevents
        similar to dnotify
        Mac::FSEvents
        is a pain to install

Todo: investigate App::GitGot

App::GitGot simplifies management of multiple git repositories. It provides simply status reports and update management. It’s goal is to support multiple repo types but only supports git at the moment.

Why You Should Disable the Popup Login Box

Long, long ago, there was only one way to authenticate users on a website: HTTP Basic Authentication (oh sure, there was later Digest Authentication, but few people used it). And then Cookies were invented, and the web was yummy. Only it wasn’t, because cookies had privacy concerns along for the ride; and still do. But, cookie-based login methods began to be used, and quickly out paced the older (and by many, considered uglier) Basic Authentication method.

Now it’s trivial to use cookie-based authentication and authorization when creating a web application. To the point web application developers don’t even have to think about adding it to their application. Most frameworks and libraries provide it out of the box.

However Basic Authentication continues to be used. And, oddly, still preferred by some (hopefully the slim, tiniest of minorities). Let me provide one reason you should disable, and desist using, HTTP Basic Authentication:

HTTP Basic Authentication does not provide, nor support, a means of logging out of the session.

Once you login to a site using HTTP Basic Authentication, your session token is retained by the browser until you close the browser. FireFox and IE provide a means of clearing this token, but the means is a hack and fragile. Webkit-based browsers such as Google Chrome, and Apple Safari, do not provide such a means.

Using the cPanel software as an example, consider this scenario:

  • You login to your cPanel site at https://example.com:2083
  • HTTP Basic Authentication is used to authenticate with cPanel
  • After your management session, you click the Logout Button
  • You visit various other websites throughout the day
  • You return to https://example.com:2083 and are immediately take to the main cPanel interface

The above is possible because of the lack of logout functionality.

Now, why should you or I care?

One phrase: Cross-site Request Forgery (XSRF). Because the session token is retained by the browser until the browser is closed, it is possible for malicious users to access that token and accomplish things you don’t intend. Consider this article as an example.

Don’t get me wrong, cookie based authentication is no guarantee a web application is proofed against XSRF. With cookie based logins it is possible to clear out the authenticated tokens and cleanup the session. Not so with HTTP Basic Authentication. It is for this reason cPanel recommends disabling HTTP Basic Authentication with cPanel & WHM.

HTTP Basic Authenticatio? Please, don’t use it.

openSUSE equivalent of rc.local

On Red Hat systems (and possibly others) custom services and commands a user may want executed after other services in the runlevel have started may be added to /etc/rc.d/rc.local (more information in the RHEL Reference Guide; order of calling is given here).

What is the equivalent on an openSUSE system?

This is what I needed to know tonight. Unfortunately the answers I found told me to create a full-fledged init script. That seemed a lot of work simply to run one or two commands. Searching the openSUSE Wiki also resulted in no answers. Thank fully, after reading a few scripts ( /etc/inittab followed by /etc/rc.d/rc) I found the answer:

/etc/init.d/after.local

They provide a counterpart for commands that need to run before entering the runlevel:

/etc/init.d/before.local