Well. I’ve hunted long and hard for a soft turn-off to the mDNSResponder in OS X broadcasting all sorts of junk all over the place . . . I use ARD for a bunch of stuff (camera raw updates, remotely helping students and faculty who have a problem in the digital lab, debugging printserver errors, updating the systems, etc.)  However, I hate that screen-sharing is broadcasted throughout the building’s network showing up as a list of computers on any Leopard/SnowLeopard computer that is on the same network. Well, with Snow Leopard, the option to turn off broadcasting without actually killing the mDNSResponder daemon is here. For anyone who has SSH or ARD (please note, ARD needs to have legacy VNC turned off and only local admin user for authent to keep it secure + required encryption.) this is a nice little security upgrade. Instructions below:

Using compressed asr images, a server with dual gigabit ethernet and fast raid setup along with gigabit router and mutlistream casting, it’s possible to install an entire 52 gigabyte system image (think CS5, CS3, all other graphic applications and preferences, Final Cut, etc) in under 14 minutes.  Whoa!!!

I figured out how to do it.

1. Jailbrake iPhone and install AFP (netatalk).
2. Connect to shared Wifi access point and log in to iPhone as root.
3. Go to /var/mobile/media/DMC10/APPLE (I’m forgetting the exact folder name)
4. Add applescript action to folder to copy all new files from this folder to a folder on your desktop. Let’s call that folder “live”
5. Open Adobe Bridge and navigate to the iPhone photo folder. (Bridge forces the Finder to auto-refresh AFP mounted folders. It doesn’t do this by itself.)
6. Open lightroom and set auto-import settings to point to the “live” folder on your desktop.
7. Take a photo and watch it show up in Lightroom. This lets you take photos from as far away as your wifi can go. If you hook your AFP connection up through a VPN server, you could be taking photos over 3G in California and have them show up live in Lightroom in Vermont.

UC base fluid found and ordered today. Looked up regulations on phlebotomy. Disturbingly little. More on transportation of blood through the USPS. Looking for an artist doctor who is willing to pull 500ml of my blood for printer testing. Will build a septone monochrome print environment with megenta ink first.

Two nights ago I finished doing test photos. Conclusions for Fomapan 100. ISO 50 with 13 minute develop gives full 13+ stop range. Great scanning film because it is to thin! Took photos of Will Blackwell (my cousin) for first blood print. Need to learn how to take blood. Developing tonight.

I am going to go out on a limb here and talk about the future of Digital Asset Management. I believe the reason why DAM software is not working well for most people is for a few really big reasons.

1. There are too many non-compatible non-cross-platform solutions out there.
2. Many of the best solutions are not open-source. That makes many institutions unable to buy contracts for the use of the software. The institutions are also dependent on outside programers and this is always a risk.
3. Many solutions don’t implement robust infrastructure. That is to say, the time it take to query and load an asset takes way too long for the DAM software to be useful. This is often a fault of infrastructure problems at each particular institution. Many institutions haven’t funded gigabit switches enough. They are slowly adding these switches to critical network nodes, but the increased bandwidth hasn’t trickled down to the end users yet. Added to this is the need for large enough servers to through out the data fast enough.

The solutions? Well, there are a few obvious ones.

1. Go with an open-source, standardized, digital repository system like Fedora Commons or Dspace.
2. Add an extendible and “sexy” front and back end online GUI for creating user accounts and the like.
3. This is critical. Create a FUSE-based File System “glue” layer between the repository and the end user. Why do this? Simple.
a. Increased unlimited security. The file system can be upgraded with various encryption methods very easily.
b. Platform independent.
c. Open source.
d. This is the best of all. End users can use WHATEVER desktop DAM solution they want to use. All they have to do is point their DAM software to a hard-drive on their computer and away they go. They can be importing files into Final Cut live off a Fedora server. They can be scrolling through Art History slides from the Thirties in Adobe Bridge. They can run a spotlight search on the entire archive. That search would be translated into a Fedora query and return as a Spotlight result. Boom, done.

Users would be able to use their preferred applications. The ones they use all the time. The documents they would be working on, however, would be organized, archived, sorted, and versioned, somewhere else. This increases security, decreases the risks associated with HD crashes, increased collaboration (just imaging typing in someone’s user-name in Spotlight to see their shared MS word docs right in a hard-drive on your desktop), and decreases the amount of time it takes to train everyone on some clunky, underdeveloped, solution that nobody will really use.

You want to archive 3000 songs? Drag them into a folder and the rest gets done automaticly. If iTunes can scrub through metadata on a drag-and-drop, FUSE can do it to.

You want to see multiple versions of a file? Do a search of the HD.

You want to manipulate the photo? Open it in Photoshop and do that.

You want to collaborate with a peer on a document? Set the permissions directly in the file with Get Info or any other platform independent permissions window.

The possibilities are endless and the learning curve is minimal. So that’s where the future of DAMs lies. Not monolithic solutions, microlithic solutions with solid translators in-between. Imagine two people working on a digital archive at the same time. One person is using Adobe Bridge on a Mac, another person is using a normal browser on a PC. They are doing the same thing in their preferred way!

1. Create a unified content front-end and middle-end system based on XML.

2. Create a unified live-data collaboration GUI set for faculty/staff/students and anyone else connected with UVM. This can be built on Flex and Spry frameworks.

a. Email –  Have support for full unlimited archiving and RSS feeds etc. The web gui should be Air compatible and rival OS X Email for search capability. That means live searching.

b. Calendars. Everyone at UVM should have a calendar. Not just faculty/staff. Students need that too. Use the opensource Darwin Caldav server. iphone, smartphones, and all sorts of applications and platforms can connect to it. Build in a Flex front-end to the calendar for admistration. Also a Spry front-end for UVM’s site.

c. Create a real database-driven content management system for UVM’s many websites that fully seperates design markup from data. Again, build the data from XML. This should be built upon an opensource CMS like WordPress or Drupal.

d. Create a real digital repository built on the combined force of Fedora 3 and Dspace with a flex-frontend gui and suitable Spry-like web-based front ends for students and faculty to search.

e. Give access to web developers and faculty to connect departmental websites with the DR content.

f. Give access to web developers and faculty to connect departmental websites with any DB content at uvm including calendars, news, rss feeds, etc. Half of this is done, but there is no centralized pool of data for retrieval.

g. Looking forward, we realized that more and more data will run in a live-update form. Any new modifications to sites should include live listening handlers for data updates. All of this is resource intensive, but the web will always be so.

h. Add mobile application layers to any and all portions of online-accessable content on the UVM infrastructure. This includes Calendars, Email, websites, student backends, facilities management, etc.

i. Create an encryption and security protocol for all new content and infrastructure that includes regular security updates of open-source components and regular penetration testing of all components. Closed source components should be minimized and isolated to non-line communications as they are a security risk that is hard to react to when compromized. That means getting rid of closed-source collaboration software that costs too much money, does not get updated because of financial problems, and can lead to massive data vulnerability.

+ much much more.