Originally Posted By: mlord

/dev/hda5: 16MB root (or maybe 32MB to give room for more apps)

How well does that work with stock upgrade files? Currently, owners of (already built) big drives can apply any stock upgrade, and then immediately a new Hijack (only), and be fine. IIRC the stock car-player upgrade files contain complete root filesystem images, not tarballs (we only invented embedded tarballs for Jupiter). So they'll come out as 16M, not 32M, filesystems.

Mind you, I suppose anyone installing a stock upgrade is going to eliminate any "more apps" from their root filesystem anyway. I think the recommendation has to remain that "more apps" live on hda2, hda4, or hdb5.

Quote:
/dev/hda6: 64MB swap

That's definitely a good idea, though.

Quote:
In particular, would the player binary actually use a larger dynamic data area?? I know we could put longer bookmarks (and a longer current running order) in their if we left enough space, and we already know how to patch the player binary for those..

The table of offset/length pairs which set-empeg-max-fid already patches, is the only thing which tells the player how big a dynamic data area it has. So no, it won't use a bigger area automatically, but you already know how to tell it to use a bigger area. Nor (if building a new drive from empty) is it important to keep the offsets/lengths compatible with the stock player -- as long as users know they can then never use a stock player on that drive.

Peter