On Mon, 2007-08-20 at 14:10 -0500, Douglas McClendon wrote:
Jeremy Katz wrote:
> On Mon, 2007-08-20 at 05:23 -0500, Douglas McClendon wrote:
>> (I'm getting a sense of deja vu, that I'm learning the same lesson
>> someone else recently learned here. Lets see if the 3rd time is the
>> charm...)
>
> It looks like you're getting hit by what Colin was where the list is
> eating some attachments :-/ FWIW, the "best" way of sending patches
> directly from git is git-format-patch followed by git-send-email; I need
> to sit down and write up some simple docs for using git + livecd-creator
> and best practices. Where's that 36 hour day? ;-)
>
> I'll try to get access to the list admin page later and try to tweak
> stuff to avoid the problem later as I suspect it's that one of the
> default mailman settings blocks attachments that look like mail to avoid
> some of the WINMAIL.DAT crap.
Hmm... The 3rd time did appear to be the charm for me. Perhaps your
email client is eating a broader class of attachments than the list
itself. To see the patch, see the archive link of the post you replied to-
https://www.redhat.com/archives/fedora-livecd-list/2007-August/msg00168.html
Weird. In any case, I'm also now an admin for the list, and like I
said, I've _hopefully_ adjusted things so they should work anyway.
We'll see I guess. And review coming up from looking at the patch
next...
>> It may well be that a simpler persistence implementation
that involves
>> just extracting tarballs from usbsticks into the normal ram overlay, may
>> be useful instead of (or even in addition to) this kind of
>> implementation. (or perhaps some implementation of unionfs will make it
>> into fedora eventually?)
>
> There's work on doing unionfs via fuse which could be interesting for
> that in the medium term. But I'm not sure how useful tarballs/unionfs
> are when we think about the user experience. If it's going to persist,
> we want changes to "persist" as soon as they're done, not after some
set
> of stuff is done to apply them.
Well, the way ubuntu is trying to do it of course, is with unionfs
(since of course they use unionfs rather than dm-snapshot to get cow in
the first place).
And as such, unionfs can provide just as persistful an implementation as
the direction I've been going. In both cases you can think of the
persistence as another embedded layer in the total root filesystem.
It's been quite a while since I looked at unionfs, but I vaguely
remember that it was more subtree overlays. I guess you could perhaps
do a subtree of /. But even so, I don't know that supporting multiple
ways of achieving the same goal is really where we want to go. But it's
somewhat academic at the moment, so probably not much discussion needed.
> Let's make things simpler for the moment and just ignore
ntfs. If we
> get things happy with ext3 and vfat, then we can start to think about
> ntfs.
I was ignoring ntfs, though not enough to remove the stuff that could
support it.
I say let's just pull it. If it doesn't work right now, we might as
well save the effort of testing it and/or someone trying it, finding it
doesn't work, and filing a bug. Plus, it then makes the changes clearer
for looking at.
Jeremy