Archive for August, 2012

Basics of Mac OS X Package management

The package management in Mac is quite non-existent compared to what Linux has to offer, e.g. Debian packaging which has full dependency resolving capabilities and ability to install package along with dependencies and uninstall along with dependencies.

Mac has a pkgutil command that knows something about installed packages on the operating system. It is also possible to dig information on what applications are installed on the OSX by using the System Profiler. In the System Profiler full report, all installed software is counted.

Here is man page for pkgutil:

https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/pkgutil.1.html

How to determine what each package contains:

pkgutil –packages list installed packages.

then loop through all the packages and run

pkgutil –pkg-info packageid

for example:
pkgutil –pkg-info com.blackmagic-design.DaVinciResolveApplications

command prints out: “

package-id: com.blackmagic-design.DaVinciResolveApplications
version: 1
volume: /
location: Applications
install-time: 1328796965″

From this we know that the base directory for this package is Applications folder on system root volume /.

Then we can find out what files this package has installed under the base folder.

pkgutil –files packageid

example:
“pkgutil –files com.blackmagic-design.DaVinciResolveApplications
DaVinci Resolve.app
DaVinci Resolve.app/Contents
DaVinci Resolve.app/Contents/Frameworks
DaVinci Resolve.app/Contents/Frameworks/Cg.Framework
DaVinci Resolve.app/Contents/Frameworks/Cg.Framework/Cg
DaVinci Resolve.app/Contents/Frameworks/QtCore.framework
DaVinci Resolve.app/Contents/Frameworks/QtCore.framework/Resources
DaVinci Resolve.app/Contents/Frameworks/QtCore.framework/Versions
DaVinci Resolve.app/Contents/Frameworks/QtCore.framework/Versions/4
DaVinci Resolve.app/Contents/Frameworks/QtCore.framework/Versions/4/QtCore
DaVinci Resolve.app/Contents/Frameworks/QtGui.framework ….
– rest of the printout is clipped because it is large -….”

This information is actually found from a folder, pkgutil just finds the same information that is stored in bom and plist files under:
/private/var/db/receipts

The bom-files can be inspected with command lsbom.
lsbom com.apple.pkg.FinalCut_AppStore.bom

The plist files are typically binary format, but they can be converted to readable xml format using plutil:
plutil -convert xml1 -o –
This is hardly needed because the plist files can be also read with defaults read -command as follows:
Example:
defaults read /private/var/db/receipts/com.apple.pkg.Aperture_AppStore.plist
Please note that you must specify full url to defaults read, if you are in directory /private/var/db/receipts and try to execute defaults read ./com.apple.pkg.Aperture_AppStore.plist – it will not work.

Useful parameters for lsbom:
-s list only files (the numeric information disappears with this):
Example:
cd /private/var/db/receipts
lsbom -dfls com.apple.pkg.FinalCut_AppStore.bom

Someone has made a simple script to uninstall bom:
http://invariance.org/clemens/uninstall_bom
And here are instructions how to use that script:
How to use uninstall_bom

High Altitude UAV Launch for Microsatellite Launcher Rocket

Rockets lifting off from the ground are inefficient and require enormous amount of fuel and especially oxidizer despite there is plenty of oxygen in the low atmosphere. Rocket engine is very inefficient too, and to save fuel, the best way is to limit the time the rocket engine is needed => more reasonable amount of fuel needs to be carried and subsequently smaller rocket is needed.

To launch microsatellites, a similar approach than Burt Rutan’s WhiteKnightTwo (or Stratolauncher) is the best way to go. The difference for a microsatellite rocket is that the payload is much more modest and a much smaller and much less expensive airplane can be used. The airplane can be either UAV or optionally piloted aircraft. If it is just pure UAV, it can be made smaller and less expensive.

The principle of this airplane would be series hybrid propulsion. There would be a small but powerful modified series turbo liquid cooled motorcycle engine turning a generator (which is also a brushless DC electric motor, but bigger than the propulsion units). The actual propulsion would be provided with several smaller electric motors which would turn relatively modest size propellers (vs. the need for prop size in the high altitude). The large number of the propulsion units would compensate for the diameter. Very large diameter in the prop would cause severe geometric problems for the aircraft (landing gear, wing placement etc. as evidenced by Grob’s high altitude aircraft), but instead lowering the disc loading of the prop by increasing the number of the props, is much less expensive and much less complicated way to do it, especially since the construction with electric motors approaches trivial.

The aerodynamics of the aircraft would be based on a high aspect ratio long wing and conventional tail placed aft of a ideal laminar pod-shaped fuselage (for UAV pod-shape would be even easier because there is no need for seating people inside and no bumps / deviations of the ideal shape are needed). The airfoil designed for the purpose would be obviously a low Re airfoil with maximized L/D at moderately high Cl (unlike the cruise-oriented airfoils presented earlier on this site).

The airplane would lift the rocket with the hybrid electric propulsion to 50000-80000 ft like e.g. the Stratolauncher does, but with the difference that the aircraft would be very inexpensive. Even 80000 feet should be possible with hybrid propulsion since when the dual turbo can not provide enough power anymore (it would cut out pretty much after 60000 according to some studies done for HALE-UAVs), it can continue climb purely by using batteries. There is a limit though how much batteries can be carried along with the plane to not lose too much of the payload (the rocket). This is a compromise that needs to be optimized carefully to maximize benefits.

The airplane would be obviously fully reusable and good for a long long time. Different kind of payloads could be accommodated, depending on the need. E.g. rocket carrying multiple microsatellites or a rocket carrying one payload or a equipment that would study higher atmosphere (without rocket) or possibly a pressurized pod housing a human (as alternative to the rocket). It would be highly interesting concept to design & implement. It requires some budget, but can be done with quite modest budget not commonly considered in the aircraft/spacecraft circles.

Marching order would be this:
First study items for this would be:
1. Determine how large rocket would be needed for reaching orbit from case 1) 50000 ft and case 2) 80000 ft. Someone familiar with rocket equations could contribute if you would be interested. Please note comments are unfortunately moderated due to spam-comment problem, and may not appear immediately (only when I have time to go to press approve).
2. Then the size of the aircraft that will lift the rocket can be determined by requirements set by 1).
3. Determine the propulsion system needed for lifting the 2) to case 1) 50000 ft and case 2) 80000 ft.

Conservative assumption would be that the aircraft would reach 50000 ft and horizontal speed would be negligible at launch altitude, and the size of the rocket would need to be determined based on that altitude (and initial speed). Then if the aircraft could be made to reach 80000 ft, it would be all plus, bigger payload could be accommodated to the rocket.

The configuration for the aircraft could be quite simple:
– 2 small pods with two tails (or interconnected tail) like Burt Rutan’s high altitude lifters leaving the center section for the payload
– one pod could house the piston engine + fuel
– another pod could house the batteries
– four wheel landing gear would be located to both pods, similarly than White Knight