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
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
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
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 lack of 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
-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
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
