Finger info for

Postal 2/mac is now available for sale online with digital download, which is
 nice for impulse buying, night dwellers, and people that live in countries
 where it's banned. Please note that the Apolocalypse Weekend version here
 can't be used with any other version of Share the Pain (so if you want both,
 get them both from

Check it, and other games here:

Other stuff:

So I've been thinking about some things that Mac OS X happens to do really
 well that Linux could benefit from stealing. Not the Expose' thing, although,
 yeah, that too...I'm thinking at a more boring, plumbing level.

- Fat/Universal binaries. It would be interesting if Linux could plug more
  than one architecture into one would making shipping binaries
  easier, perhaps, but it would also solve the whole /lib, /lib32, /lib64
  mess on amd64 systems. Solving this would probably need a fake architecture
  defined in the ELF format: instead of an x86 or PowerPC ELF file, you get
  a "container" ELF file, which has a segment for each real architecture
  contained in the file...each segment being a full ELF file in itself. We'd
  have to patch some tools and the kernel, and write a few new ones like an
  equivalent of Apple's "lipo" tool, but I don't think it would be enormous
  amounts of work. (yeah, what could possibly go wrong?)

- Launch Services. It would be really nice if there was an equivalent of
  the Mac's "Application Bundles" on Linux...If you have a directory that has
  the ".app" extension, the Desktop Environments treat it as a single file as
  far as the end-user is concerned, but lets us pack all our datafiles behind
  one icon. More importantly, it lets us store some standard metadata about
  what the app can do, regardless of the filesystem...this would be your
  equivalent of Info.plist. Then we have a daemon that sits there waiting
  for the kernel to send it notice over D-bus when files are changed. If it's
  an app bundle, it updates a database. Then other processes can talk to this
  daemon and say "Can you launch whatever handles PDF file viewing?" or "can
  you launch whatever handles FTP connections?" or "can you launch the user's
  preferred email composition program?" ... or "can you tell me where
  Unreal Tournament is installed, even if the user moved it after the initial
  installation?" 9/10ths of the cases can be handled by an equivalent of
  Apple's "open" command. This would be generally useful, and also make
  interoperability between Gnome and KDE suck less.

- Disk images. Ok, we already have these, sort of, but it would be great if
  these could be downloaded and mounted cleanly. Right now we can't ship
  anything self-executable on Linux, like, say, an installer, because it
  doesn't keep the executable bit when you download the thing. There's nothing
  worse than having to tell someone "okay, download this, then open a terminal
  and type in 'chmod u+x filename' ..." disk images solve this by the nature
  of shipping with their own list of file permissions internally, but also let
  us do things like, say, ship an executable plus some shared libraries as one
  download, and, in a really Mac-like way: we may not even need an installer
  in these cases: just open the disk image, and drag the thing where you
  need it. Now that would be sharp.

- Case-insensitive filesystems. Time to let it go, people. Ironically, I bet
  that Mac OS X, a popular Unix-like system with a case-insensitive
  filesystem, probably resulted in a lot of open source packages being fixed
  already...all those packages with an "install" script and "INSTALL" readme.
  Autotools, I'm glaring at you here.


When this .plan was written: 2006-05-14 16:37:57
.plan archives for this user are here (RSS here).
Powered by IcculusFinger v2.1.27
Stick it in the camel and go.