Re: Journal Suggestions
On Wed, Apr 30, 2008 at 10:15 AM, James Simmons <[EMAIL PROTECTED]> wrote: > To be truthful I would be perfectly happy if the SD card just had metadata, > including screenshots, like regular journal entries have. The other Journal Quoting Jameson: "Technically, I think this would mean that the metadata are stored on the NAND, with some UID of the associated file. The file, if not present on the NAND, would be looked for on SD, USB, and then server, in that order." And quoting myself from the other thread on the Journal designs: "Well, this has been a point of debate. Some feel that absolutely nothing should change on removable media unless the user specifically copies to it or modifies files on it. It's very questionable if "reading a pdf on my USB drive" should amount to "modifying the pdf on my USB drive". I'm actually leaning towards no on this point, to retain the idea that the Journal itself is the thing which retains history. Files which aren't in it are thus not versioned. That seems like a clear distinction to me, and one that can be learned. "The addendum to this idea, which stems from the new Journal designs, is that the Journal can record actions on objects that don't actually reside in the Journal, which in some sense gets around the issue. For instance, it could say "You read all_about_sharks.pdf on your_USB_drive today". The Journal entry records the action, and the metadata (such as the page you stoppped on), but keeps only a reference to the file on the USB drive, instead of manually copying it. You could resume this entry only when the USB drive was present, of course. This opens the dangerous door of aliases, which is why we've been operating under a copy-almost-everything model, so that it's always possible to resume old entries." We may find a good way to handle this type of approach. It's still not inherently correct. For instance, even if we store the metadata on NAND and reference another object on an external device, there's a question of whether or not we redundantly store that metadata on the device itself. Without it, we keep the USB drive (for instance) clean, as many have claimed we must do. On the other hand, without it we can't ever truly restore from that device, which is a firm requirement of the backup server. So there may still need to be differences...perhaps instead we always keep the local metadata, but we have the option to treat external devices of any kind as Normal or Backup devices. Assume the above for a moment. As I mentioned before, saves will always save into the Journal (by default, at least). If we open a pdf from the Backup SD, we'll get an entry in the Journal for that. Do we also get an entry on the SD? Are there mirror entries? Conversely, do actions I take on objects in local NAND get mirrored in the Backup SD? If we want to treat them as local backup, then yes. But perhaps this is again not the use case you had in mind, in which you wanted metadata actually *on* the device. For that matter, what reasons might you have for needing the metadata on the device itself other for backup, assuming you can actually manage all of the history within the Journal, and reference the files which live on the external drive? The other problem is how and when to handle aliases, and how to expose that to kids. For instance, we've been operating to the extent possible under the assumption that we'll copy any files used or viewed into NAND so we can retain the history locally, and so kids don't have to always think about when to copy or not, and can always go back into the Journal and resume an entry. Maybe this is the wrong approach. If we don't automatically copy for them, how do we expose that, make them aware of it, and offer a simple way for them to do it? Perhaps an entry with an alias has a special button which pulls the aliased content in upon request, automatically. - Eben PS. Please submit tickets for the feedback issues you see. We need to close up holes like that and make sure the laptop keeps the kids properly informed about such things. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Journal Suggestions
To be truthful I would be perfectly happy if the SD card just had metadata, including screenshots, like regular journal entries have. The other Journal features aren't necessary. If there was a way of doing a Move from the Journal to the SD card that would be helpful. Finally, since both are constrained in space, it would be desireable to prevent copies and moves if the target did not have enough free disk space. This is my biggest frustration with the XO. If I'm reasonably careful it has more than enough disk space for my needs. The problem is that it makes it difficult to be careful. I have had an experience where it copied a Journal entry to the SD card and ran out of disk space before the copy completed, and there was no indication of this at all, other than the fact that my Activity didn't work. I had to open the Terminal to find out what went wrong. James Simmons Eben Eliason wrote: > | In other words, the Journal and the interactions with it are so tied > | to the system already, that one would still have to manually copy > | pretty much anything one wants onto the SD card or external device > | anyway. The only difference would be in whether or not the copied > | files get indexed, with metadata, similar to the way the Journal > | entries do; it can never serve as a "replacement" for the Journal, or > | as an "extension" of it, which seems to remove most of the benefits > | that it could otherwise offer. Perhaps you could instead "register" > | an SD card *as* the Journal, so that in the future the Journal > | activity ignores NAND and instead operates only on the registered > | device instead. This doesn't really extend the memory...it simply > | swaps it out (for something with, presumably, much more), which is > | still not that great. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Journal Suggestions
> > storage. The mechanisms required for handling removable media, USB hard > drives, and networked storage, are all essentially the same. > ++ Technically, I think this would mean that the metadata are stored on the NAND, with some UID of the associated file. The file, if not present on the NAND, would be looked for on SD, USB, and then server, in that order. ps to Mikus: I think the "slowness" of NAND is due to the automatic compression (and of course decompression) of JFFS. This is based on no data, just intuition. I would be interested to know if there are any comparative speed tests with/without this feature. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Journal Suggestions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eben Eliason wrote: | In other words, the Journal and the interactions with it are so tied | to the system already, that one would still have to manually copy | pretty much anything one wants onto the SD card or external device | anyway. The only difference would be in whether or not the copied | files get indexed, with metadata, similar to the way the Journal | entries do; it can never serve as a "replacement" for the Journal, or | as an "extension" of it, which seems to remove most of the benefits | that it could otherwise offer. Perhaps you could instead "register" | an SD card *as* the Journal, so that in the future the Journal | activity ignores NAND and instead operates only on the registered | device instead. This doesn't really extend the memory...it simply | swaps it out (for something with, presumably, much more), which is | still not that great. To me, this issue seems almost indistinguishable from the school-server Journal integration problem. In both cases, we have a storage device other than the NAND, providing a great deal of space (potentially larger than the NAND) but whose presence is not entirely dependable. The comparison is particularly apt if we imagine a scenario in which there are multiple backup servers, some trusted and some not, as suggested in Bitfrost. The role of a specific SD card could then be as (1) Trusted Journal storage, (2) Untrusted Journal storage, or (3) Non-Journal storage. The mechanisms required for handling removable media, USB hard drives, and networked storage, are all essentially the same. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIF+ndUJT6e6HFtqQRAu85AKCbTJ87WMPKAHi72cbaJsFac+uoNACdGGVy W9/X7JwZYiyQW4U0h3DLK8I= =S8Im -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Journal Suggestions
> The SD card > is deliberately made difficult to remove. If someone buys and installs > an SD card perhaps it should be considered a part of the Journal > itself. More like buying a second hard drive for your system than > plugging in something removeable. So now I have just one Journal with > 2.5 gigs free instead of 500 megs free. That's the way I was hoping to > use the SD card when I got it. I have a significant problem with the speed of the OLPC. Even on NAND, if I (manually, in Terminal) copy a 5 MB file from one place to another, it takes seconds and seconds (as opposed to a desktop, where such a transfer happens in the blink of an eye). I have not tried any measurements, but my concern is that with an external device (*particularly* an SD card), access is even slower than with NAND. [And SD cards come in several speed ranges - the cheapest are usually the slowest). Empirically, I haven't noticed 'olpc-update' being significantly faster from an USB stick than over the internet. What raises my concern about treating an SD card as an extension of the Journal is - how fast will the XO be once there are a great many items for it to keep track of? I don't use 'suspend'; but the few times I've tried it - typically when attempting 'resume', my "Power" light stays on for more than three seconds, then goes back to blinking (in other words, the "un-suspend" times out). I suspect some of those seconds are being spent accessing the 100 or so files on my SD card. [Would be nice if the OLPC had a 'Storage Device Busy' light for me to look at.] What will be the performance of the OLPC (including: how long will it take to boot?) when I have several thousand files on my SD card? mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Journal Suggestions
On Tue, Apr 29, 2008 at 6:46 PM, James Simmons <[EMAIL PROTECTED]> wrote: > Eben, > > Considering the complexity of having one Journal which could be spread > across two devices, one of which could be removed, I think I would favor > having two separate but equal Journals. The second Journal would, I think, > be functionally equivalent to the first, but would have more available > storeage. This would mean that you could install Activities on it. (By > default the Browse activity would still download them to the main Journal, > but you could move them to the second Journal. You might add a "Move" menu > option in addition to the present Copy). > > The use case I'm thinking of is maybe the teacher has an XO with the extra > journal and the students don't. Or maybe the older students get an SD card, > after they are already familiar with the use of Sugar with one Journal. The > teachers and older students would benefit the most from the extra space. The main problem I see with the "easy" approach is that most of the interactions with the Journal are implicit. Everything saves to the Journal automatically. Activities save there. Clippings on the clipboard can be put there. Downloads and transfers will wind up there. Screenshots go there. In the future, the Journal will log additional actions, other than just activities, which might be relevant in the future. All of these things go to The Journal. In other words, the Journal and the interactions with it are so tied to the system already, that one would still have to manually copy pretty much anything one wants onto the SD card or external device anyway. The only difference would be in whether or not the copied files get indexed, with metadata, similar to the way the Journal entries do; it can never serve as a "replacement" for the Journal, or as an "extension" of it, which seems to remove most of the benefits that it could otherwise offer. Perhaps you could instead "register" an SD card *as* the Journal, so that in the future the Journal activity ignores NAND and instead operates only on the registered device instead. This doesn't really extend the memory...it simply swaps it out (for something with, presumably, much more), which is still not that great. - Eben ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Journal Suggestions
Eben, Considering the complexity of having one Journal which could be spread across two devices, one of which could be removed, I think I would favor having two separate but equal Journals. The second Journal would, I think, be functionally equivalent to the first, but would have more available storeage. This would mean that you could install Activities on it. (By default the Browse activity would still download them to the main Journal, but you could move them to the second Journal. You might add a "Move" menu option in addition to the present Copy). The use case I'm thinking of is maybe the teacher has an XO with the extra journal and the students don't. Or maybe the older students get an SD card, after they are already familiar with the use of Sugar with one Journal. The teachers and older students would benefit the most from the extra space. For the thumb drives we might treat them as visitors from another realm, and recognize that they might well contain subdirectories. Same thing for CDs and DVDs. James Simmons >Well, there seems to be two ways to treat a device of type 1. One is >to treat it as an independent entity, which happens to be "Journaled" >(has metadata, index, etc). The device could still be treated as an >independent storage space, and it would be necessary for the user to >manually determine which files went onto it vs. into the Journal. It >would give them, effectively, two separate Journals. > >Another way to treat a type 1 device is as an extension of the NAND. >In this scenario, such as was suggested with the SD card initially, >all of the available space would be effectively made part of the >Journal. Looking at the capacity meter for the Journal in the Frame >would indicate 2.5 GB instead of 500MB, and the device icon itself >would have some special treatment indicating that this is No Ordinary >Device. In this model, the user wouldn't need to consider that there >are actually two physical places for storage; copying anything to the >Journal could silently place it in the other type 1 device which is >"extending" the Journal's space. Of course, this also poses some >complex problems for what to do when such a device is removed, since >it effectively separates ones Journal into two pieces, and perhaps for >that reason alone, ignoring technical concerns, it should be >immediately forgotten that I brought this other approach up. > >If this is in any way feasible, perhaps it does only make sense for SD >cards which can be physically installed in the machine at all times, >unlike the USB drives which are very much a peripheral instead. In >the context of the XOs, this is almost the defining differentiator for >the two media. The SD is inherently more "permanent". It still seems >prudent to give the user the option to choose whether or not to make >an SD card a type 1 device anyway, of course. > >- Eben > > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Journal Suggestions
On Tue, Apr 29, 2008 at 3:59 PM, Benjamin M. Schwartz <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > > Eben Eliason wrote: > | On Tue, Apr 29, 2008 at 3:25 PM, James Simmons > | <[EMAIL PROTECTED]> wrote: > |> Eben, > |> > |> You bring up some points I hadn't considered. I agree that thumb > drives > |> and the like probably shouldn't have their files modified if all you are > |> doing is reading them. By their nature these drives will be used to > copy > |> files to and from non-Sugar systems, so leaving them alone makes sense. > On > |> the SD card, however, this is a different issue. The SD card is > |> deliberately made difficult to remove. If someone buys and installs an > SD > |> card perhaps it should be considered a part of the Journal itself. More > |> like buying a second hard drive for your system than plugging in > something > |> removeable. So now I have just one Journal with 2.5 gigs free instead > of > |> 500 megs free. That's the way I was hoping to use the SD card when I > got > |> it. > | > | That's a very interesting idea, and one I'm quite happy to entertain. > | It seems on the surface like a very logical way to handle SD cards. > | > |> As for thumb drives, not keeping metadata for stuff on these is OK as > long > |> as the user interface does not suggest that you WILL keep metadata for > them. > |> Currently the Journal entry looks exactly the same for an item on a > thumb > |> drive or SD card as it does for the Journal proper. There is a place > for a > |> screenshot, for notes, etc. None of this works, but it suggests to the > user > |> that it *should* work. That causes confusion. At least I was > confused. If > |> these non functional areas were hidden that would help. > | > | Agreed. If you look through the mockups for the new designs, you'll > | see that external devices will actually be completely independent from > | the Journal UI. They appear in the device tray, and when viewing one, > | you'll be in a list view that looks and functions similarly to the > | Journal, but should certainly take into account as you mention that > | tagging etc. isn't available on them, if that's the way we choose to > | go. > > The logical conclusion, it seems to me, is that the datastore should > support > 1. Datastore-controlled devices with metadata > 2. Non-datastore-controlled devices without metadata > 3. Detection of whether a given device is type 1 or type 2. > 4. Conversion of external devices from 2 -> 1 and 1 -> 2, only when > initiated by the user. > 5. Using Type 1 devices to extend the capacity of the Datastore. Well, there seems to be two ways to treat a device of type 1. One is to treat it as an independent entity, which happens to be "Journaled" (has metadata, index, etc). The device could still be treated as an independent storage space, and it would be necessary for the user to manually determine which files went onto it vs. into the Journal. It would give them, effectively, two separate Journals. Another way to treat a type 1 device is as an extension of the NAND. In this scenario, such as was suggested with the SD card initially, all of the available space would be effectively made part of the Journal. Looking at the capacity meter for the Journal in the Frame would indicate 2.5 GB instead of 500MB, and the device icon itself would have some special treatment indicating that this is No Ordinary Device. In this model, the user wouldn't need to consider that there are actually two physical places for storage; copying anything to the Journal could silently place it in the other type 1 device which is "extending" the Journal's space. Of course, this also poses some complex problems for what to do when such a device is removed, since it effectively separates ones Journal into two pieces, and perhaps for that reason alone, ignoring technical concerns, it should be immediately forgotten that I brought this other approach up. If this is in any way feasible, perhaps it does only make sense for SD cards which can be physically installed in the machine at all times, unlike the USB drives which are very much a peripheral instead. In the context of the XOs, this is almost the defining differentiator for the two media. The SD is inherently more "permanent". It still seems prudent to give the user the option to choose whether or not to make an SD card a type 1 device anyway, of course. - Eben ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Journal Suggestions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Benjamin M. Schwartz wrote: | If you hover over either device in the Journal, you can be | presented with an option like "Format this device as Advanced Storage". Except the devices are now in the frame. I mean in the frame. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIF38SUJT6e6HFtqQRAhA2AKCB0RUH2SBV2Ot6Q9scU3iyVyqfYACfZnU9 gOH0AW2/jbjEFK4Fp6I/RGk= =wMs3 -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Journal Suggestions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eben Eliason wrote: | On Tue, Apr 29, 2008 at 3:25 PM, James Simmons | <[EMAIL PROTECTED]> wrote: |> Eben, |> |> You bring up some points I hadn't considered. I agree that thumb drives |> and the like probably shouldn't have their files modified if all you are |> doing is reading them. By their nature these drives will be used to copy |> files to and from non-Sugar systems, so leaving them alone makes sense. On |> the SD card, however, this is a different issue. The SD card is |> deliberately made difficult to remove. If someone buys and installs an SD |> card perhaps it should be considered a part of the Journal itself. More |> like buying a second hard drive for your system than plugging in something |> removeable. So now I have just one Journal with 2.5 gigs free instead of |> 500 megs free. That's the way I was hoping to use the SD card when I got |> it. | | That's a very interesting idea, and one I'm quite happy to entertain. | It seems on the surface like a very logical way to handle SD cards. | |> As for thumb drives, not keeping metadata for stuff on these is OK as long |> as the user interface does not suggest that you WILL keep metadata for them. |> Currently the Journal entry looks exactly the same for an item on a thumb |> drive or SD card as it does for the Journal proper. There is a place for a |> screenshot, for notes, etc. None of this works, but it suggests to the user |> that it *should* work. That causes confusion. At least I was confused. If |> these non functional areas were hidden that would help. | | Agreed. If you look through the mockups for the new designs, you'll | see that external devices will actually be completely independent from | the Journal UI. They appear in the device tray, and when viewing one, | you'll be in a list view that looks and functions similarly to the | Journal, but should certainly take into account as you mention that | tagging etc. isn't available on them, if that's the way we choose to | go. The logical conclusion, it seems to me, is that the datastore should support 1. Datastore-controlled devices with metadata 2. Non-datastore-controlled devices without metadata 3. Detection of whether a given device is type 1 or type 2. 4. Conversion of external devices from 2 -> 1 and 1 -> 2, only when initiated by the user. 5. Using Type 1 devices to extend the capacity of the Datastore. This means that: If you put in a blank USB stick, it'll be recognized as a non-metadata device and shown as such in the Journal. The same is true of a blank SD card. If you hover over either device in the Journal, you can be presented with an option like "Format this device as Advanced Storage". This option would not destroy any data, or perform any actual low-level formatting, but might well remove the directory structure and otherwise shuffle things around. If the user selects this option, then after the conversion completes (it could be very fast), the device will instead show an option "Extend my Journal onto this device". The Type 1 vs. Type 2. detection would presumably depend on the presence of something like .olpc.store/ This approach also works well for accessing network shares, and doing seamless backup to the school server, by representing SMB or NFS mounts as Type 1 or Type 2 devices, depending on the presence (and correctness) of .olpc.store/. The school server would simply provide every student with an NFS mount, or perhaps a more exotic networked filesystem, appropriately configured as a Type 2 device. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIF34tUJT6e6HFtqQRApmbAJ4iWMg+g3oH2UrLuVXjOgYl17hltACfWAKZ mT+amSKBAhvFtJy60cW5ojM= =q57K -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Journal Suggestions
On Tue, Apr 29, 2008 at 3:25 PM, James Simmons <[EMAIL PROTECTED]> wrote: > > Eben, > > You bring up some points I hadn't considered. I agree that thumb drives > and the like probably shouldn't have their files modified if all you are > doing is reading them. By their nature these drives will be used to copy > files to and from non-Sugar systems, so leaving them alone makes sense. On > the SD card, however, this is a different issue. The SD card is > deliberately made difficult to remove. If someone buys and installs an SD > card perhaps it should be considered a part of the Journal itself. More > like buying a second hard drive for your system than plugging in something > removeable. So now I have just one Journal with 2.5 gigs free instead of > 500 megs free. That's the way I was hoping to use the SD card when I got > it. That's a very interesting idea, and one I'm quite happy to entertain. It seems on the surface like a very logical way to handle SD cards. > As for thumb drives, not keeping metadata for stuff on these is OK as long > as the user interface does not suggest that you WILL keep metadata for them. > Currently the Journal entry looks exactly the same for an item on a thumb > drive or SD card as it does for the Journal proper. There is a place for a > screenshot, for notes, etc. None of this works, but it suggests to the user > that it *should* work. That causes confusion. At least I was confused. If > these non functional areas were hidden that would help. Agreed. If you look through the mockups for the new designs, you'll see that external devices will actually be completely independent from the Journal UI. They appear in the device tray, and when viewing one, you'll be in a list view that looks and functions similarly to the Journal, but should certainly take into account as you mention that tagging etc. isn't available on them, if that's the way we choose to go. Thanks for your useful feedback! - Eben ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Journal Suggestions
Eben, You bring up some points I hadn't considered. I agree that thumb drives and the like probably shouldn't have their files modified if all you are doing is reading them. By their nature these drives will be used to copy files to and from non-Sugar systems, so leaving them alone makes sense. On the SD card, however, this is a different issue. The SD card is deliberately made difficult to remove. If someone buys and installs an SD card perhaps it should be considered a part of the Journal itself. More like buying a second hard drive for your system than plugging in something removeable. So now I have just one Journal with 2.5 gigs free instead of 500 megs free. That's the way I was hoping to use the SD card when I got it. As for thumb drives, not keeping metadata for stuff on these is OK as long as the user interface does not suggest that you WILL keep metadata for them. Currently the Journal entry looks exactly the same for an item on a thumb drive or SD card as it does for the Journal proper. There is a place for a screenshot, for notes, etc. None of this works, but it suggests to the user that it *should* work. That causes confusion. At least I was confused. If these non functional areas were hidden that would help. James Simmons Eben Eliason wrote: On Tue, Apr 29, 2008 at 7:42 AM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote: > 3). Metadata should be saved when the user is loading data from > removeable media. For instance, if I keep books on my SD card or thumb > drive, I should be able to return to the saved page number, and also see > a screenshot of the page I left off on. Yes, I'm not sure if we have agreed in a way for storing metadata in removable devices. Well, this has been a point of debate. Some feel that absolutely nothing should change on removable media unless the user specifically copies to it or modifies files on it. It's very questionable if "reading a pdf on my USB drive" should amount to "modifying the pdf on my USB drive". I'm actually leaning towards no on this point, to retain the idea that the Journal itself is the thing which retains history. Files which aren't in it are thus not versioned. That seems like a clear distinction to me, and one that can be learned. The addendum to this idea, which stems from the new Journal designs, is that the Journal can record actions on objects that don't actually reside in the Journal, which in some sense gets around the issue. For instance, it could say "You read all_about_sharks.pdf on your_USB_drive today". The Journal entry records the action, and the metadata (such as the page you stoppped on), but keeps only a reference to the file on the USB drive, instead of manually copying it. You could resume this entry only when the USB drive was present, of course. This opens the dangerous door of aliases, which is why we've been operating under a copy-almost-everything model, so that it's always possible to resume old entries. We'll have to see how this plays out, and to what extent it's needed to use the USB drive as a working directory of sorts. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel