Re: [IAEP] [Sugar-devel] A Virtual Box solution that works with Sticks
On Mon, Sep 28, 2009 at 10:45 AM, Caroline Meeks carol...@solutiongrove.com wrote: Hi, I'm trying to understand this. Is it possible to use the booting method Bill found, where we boot one kernal in Virtual Box, then that Linux mounts the USB and then it boots the Sugar kernal on the stick? I'm not even proposing that. :-) I would have to think about it a while to see if there were even any advantages. I think the fundamental problem here is that the people who are commenting (including myself) have never seen the actual problem occur. The hardware/software resources available as well as the minimum functionality (use cases) are still hazy to me as well. Could you clarify what you want to accomplish and leave anything out that isn't essential? For example, does it have to be VirtualBox (or even virtualization)? If something isn't required don't mention it except in the list of resource you know you have available to solve your problem. Thanks, Bill Bogstad P.S. I'm cc'ing this note to s...@lists.sugarlabs.org as it clearly is about SoaS Strawberry and has literally nothing to do with Sugar development. It's a more generic 'my machine won't boot Linux' problem. Where the Linux in question is SoaS Strawberry. I'm leaving sugar-devel on the cc line for now, but will probably drop it if this thread continues and certainly will for any future threads on similar topics. ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Announcing the creation of a SoaS Decision Panel [organization process started]
On Mon, Sep 28, 2009 at 12:48 PM, Chris Ball c...@laptop.org wrote: Hi all, In Friday's SLOBs meeting, we approved the creation of a decision panel, with the following people eligible to join the panel: Can I take it that SLOB is not formally requesting a two week deadline to report back as was suggested on the wiki minutes? Thanks, Bill Bogstad P.S. We have already started organizing ourselves based on the minutes. We will conduct any public discussions in the s...@lists.sugarlabs.org mailing list with a subject line tagged with [DP]. Individuals not on the panel who want to follow those discussions should subscribe to that list. We may make announcements/request for input to other lists, but will not conduct discussions in them or in all likelihood consider comments that are only sent to those lists. ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] [SLOBS] SoaS: Searching for Decision Panel volunteers.
On Mon, Sep 21, 2009 at 10:41 AM, Bernie Innocenti ber...@codewiz.org wrote: El Mon, 21-09-2009 a las 10:14 +0200, Tomeu Vizoso escribió: Yes, the most obvious path is to be based on the next CentOS major release, which in turn will be based on Fedora 11 (AFAIK). Switching to other distros with LTS is of course possible but then it will be most probably carried out by a different team than SoaS Fedora. The only reason you want a distribution to be long-term supported is security updates, but those tend to affect mostly server applications (which we don't have) or multiuser environments (and we have only one user). The only remaining pieces that may contain vulnerabilities are the Activities. Especially the web browser. I agree with your statement about security updates being what is desired here However, you can have bugs elsewhere in the stack which can cause problems even if all anyone ever runs directly are Sugar activities: 1. Single packet DOS attacks against the kernel. 2. Overflow bugs in the DNS resolver libraries of the system which are triggered by simply doing a DNS query from the browser. (Implies no bug in the browser itself.) 3. Overflow bugs in ANY non-Sugar library/program which is used by an Activity and whose parameters come from data which might be obtained from the Internet. Perhaps gnome libraries? Python interpreter/core libraries? I believe Read is a wrapper for evince and/or poppler, Speak is a wrapper for espeak or gst-espeak. Any activity which wraps a standard Linux program is a potential problem. Sure an activity can attempt to filter out bad data. I see this as getting into the anti-virus signature game though. Every time an activity is modified to filter out some new variant the attacker will just change their data slightly by adding padding, etc. Maybe it wouldn't be as bad as I suggest, but it could get ugly fast and activity performance would suffer as data was parsed in two places (wrapper and core program). We are not yet a target because most Sugar installations (XO-1s) are slow and at the end of really slow network pipes. Always-on Sugar workstations in developed world schools sound like a much better target. Not as nice as ubiquitous Windows boxes, but still of interest. This creates a sustainable market for Sugar. Linux distributors who have successfully built a reputation for offering good customer support, such as Red Hat, *do* make good profits and *do* reinvest a large part of them to contribute back to Linux development. Everyone wins. Even RedHat's $30 pricing for desktop support for educational users is higher then I believe SoaS (or its equivalent) needs to support. Tomeu's CentOS suggestion is more plausible to me. Bill Bogstad ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] [SLOBS] Long-term support for Sugar
On Wed, Sep 23, 2009 at 1:07 PM, Bernie Innocenti ber...@codewiz.org wrote: ... Right. One way around it is using Alien, which I already proposed. Another solution is to admit that kids running incompatible distros will be unable to exchange activities -- period. It would be quite a rare scenario in the field. Depends on what you define as 'field'. If you mean national/province/whole school XO (or maybe SoaS) deployments. It will be practically never. If you mean: meetups, gruops of home schoolers, Sugar days at the local museum/zoo/etc. i.e. grassroots events, then it's going to be a lot more common. In fact, given how many releases there have been for the XO and other Sugar delivery methods; I suspect that any meeting of this type will not be all the same base system. Bill bogstad ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] A Virtual Box solution that works with Sticks
On Wed, Sep 23, 2009 at 3:20 PM, Caroline Meeks solutiongr...@gmail.com wrote: Since we can't seem to boot the MacBooks directly, but we could use Virtual Box, can anyone think of way to use Virtual Box that would allow students to use the info on their sticks so they can at another point in time use a classroom computer and not always need to use the same MacBook? I may have mentioned this to you before, but I have managed to use my SoaS stick directly with VirtualBox running on a Linux host. VirtualBox has a method of making an entire physical disk available inside it's emulated environment and this is what I used. I have no idea whether this is doable under Mac OS X, nor do I have access to the hardware/software to test it. (Not to mention the time at the moment.) If you look in the VirtualBox manual for Using a raw host hard disk from a guest in section 9, you will find info about what I used. If someone else with hardware access wants to try it, I'm happy to exchange email. You are liable to run into permissions issues and any number of other problems getting this to work. If you pick the wrong host hard disk you could cause damage to your Mac OS X installation as well. Bill Bogstad ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] A Virtual Box solution that works with Sticks
On Wed, Sep 23, 2009 at 4:26 PM, Gary C Martin g...@garycmartin.com wrote: Sure, you could just link the ~/default/datastore directory on the VM to the matching location on the stick. I'm not sure how the pretty way to do this would be (likely at this moment in time would be just tweaking the VMs to assume the stick was there). Pop stick in, then run the VM would be the workflow once set-up. From a future stand point, you'd likely want to push upstream for a feature where Sugar checked for valid (and correct version) data-stores on start-up (perhaps with a UI if more than one valid data-store was found), so any external media device, or perhaps even mounted network volume could become the default data-store for that session. Could you clarify what you are suggesting? Most VMs (including VirtualBox) typically use large files within the host environment to provide the contents of virtual disks to the OS running under virtualization. By default VirtualBox uses a format that dynamically allocates in the real filesystem as the guest OS actually writes to the virtual disk. I don't think this file is going to be directly compatible with any file (or filesystem image) that SoaS is storing on a USB stick. If you were thinking of something else, please let me know. Thanks, Bill Bogstad ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] A Virtual Box solution that works with Sticks
On Wed, Sep 23, 2009 at 8:12 PM, Gary C Martin g...@garycmartin.com wrote: Yes, I routinely use the Shared Folders feature for VirtualBox on the Mac :-) Every thing Sugar flavour I work on resides there for easy access between different VMs. VirtualBox treats this as a device (after installing guest additions) so after a reboot I run: I wondered if you might be thinking of Shared Folders. I don't think of this as accessing a device. I believe the access is at a filesystem level rather then a block level. Kind of like a network-based client-server (NFS, CIFS) filesystem which just happens to be running all on one physical machine. I don't see how this would allow the guest OS running inside VB to actually boot off of the USB stick. If you use the raw disk method that I suggested, then you really do boot off of the USB stick. Theoretically the raw disk method could be used with any USB bootable stick because you get everything from the stick (not just the users home directory). Still one could install SoaS to a virtual disk under VB, install the VB guest software there, modify the installed SoaS to mount the a directory via the shared folder mechanism. Then the question is what is in the shared folder. You can't just have it be the mounted USB stick. That's isn't the SoaS user's home directory. You have to to dig inside the USB stick to find the linux filesystem image there which is used for the user's home directory. I'm guessing Mac OS X doesn't mount Linux filesystem images located on VFAT formatted USB sticks. One possibility might be to make the shared folder just be the VFAT formatted USB stick and mount the Linux filesystem image from within the Linux guest OS (kind of like SoaS does it now anyway). Personally, I think the raw disk method is much simpler for the SoaS use case of wanting access to all of the users journal entries/activities. I just don't know if this works under Mac OS X. Also, if you want any user modified OS stuff as well; I don't see any way to get it to work. Also be aware that you need to tell VirtualBox it's allowed to use USB, I I don't see why. You aren't actually giving the the VB Guest OS direct access to the USB stick at any level. You are giving it access to some directory in some filesystem which is mounted somewhere by the host OS. The guest OS (SoaS/Fedora) doesn't ever see it as a USB device at all. This is true with the raw disk method as well, but block level access via USB is close enough to block level access via an emulated IDE controller that it seems to work. Only the kernel itself cares which device driver is being used. think it defaults to allow, but you can also filter for named devices if that makes more sense in a deployment. I would also want to sanity check the shut down process to make sure we didn't bork users sticks at the end of a session. Ping if you'd like to work this through, should be easy enough for me to set up a test cycle here if you think this is valuable. If I get some time to actually do something about it, I'll let you know. Thanks, Bill Bogstad ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Long-term support for Sugar (was: slobs... blah blah)
On Mon, Sep 21, 2009 at 3:25 PM, Bernie Innocenti ber...@codewiz.org wrote: [cc += mstone] [cc -= everyone else] El Mon, 21-09-2009 a las 12:54 -0400, Bill Bogstad escribió: I agree with your statement about security updates being what is desired here However, you can have bugs elsewhere in the stack which can cause problems even if all anyone ever runs directly are Sugar activities: 1. Single packet DOS attacks against the kernel. Yes, but the vast majority of these actually affect weird network protocols that nobody's using (such as IPX or AFP) or weird IP options that are not normally exploitable with a regular Internet client. If the attacker social engineers you into visiting their web site/network resource, I believe that they can request any IP option they like during the initial handshake. Stateless packets (ICMP or UDP) can also be directed your way at any time. 3.[general problems with software boundary issues/program/library wrappers] Indeed. This is one more reason why I dislike the notion of drawing a straight line in across a modern distribution and call everything on one side system and everything on the other side applications. We have very advanced package systems in Linux, we don't need to regress to Windows-era tools that can't upgrade the system and its applications consistently. The lack of good dependency reporting and version tracking for Activities makes this difficult. Something like XO bundles could work better for for some scenarios though. For example, has anyone ever done anything with the 'host_version' field in the Activities *.info file? Maybe it could be hijacked for Sugar library dependencies. Not as remotely capable as full dependency checking, but core Sugar (glucose) could at least use this for direct Activity dependency issues. Preferentially with a pop-up telling people there may be incompatibilities. Activities that stick with direct Sugar supplied functionality would be safe. Glucose would know what range of values it supports and would alert if an Activity is outside of that range. Activities would request the minimum value that works for them in their info file. Perhaps Activities could also query for the maximum value supported and change their behavior based on it. (This assumes that Glucose functionality is monotonically increasing and the cost of retaining compatibility with older versions of the Glucose API is reasonable for at least a few releases.) I wasn't suggesting paying Red Hat to support us. I was suggesting that some companies -- like, for example, Solution Grove -- could offer such long-term support service to schools for a fee. Such companies could decide to create a CentOS based spin of SoaS, or backport the security fixes themselves, or maybe even ensure that major OS upgrades are synchronized with the beginning of the school year and work seamlessly for the all the hardware they support. It's really up to them to figure out what makes their own customers happy. Sugar Labs does not need to spend a single buck on this, exactly the same way the Kernel Hackers don't need to care about linux-2.6.18 today... unless they're employed at Red Hat, of course! ;-) So clearly teachers/schools aren't Sugar Labs' target for its' deliverables because their desire for stability is incompatible with the fast changing, (almost) never look back release model of Sugar and Fedora. I'm glad that we cleared that up :-( Bill Bogstad ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] [SLOBS] Long-term support for Sugar (was: slobs... blah blah)
On Mon, Sep 21, 2009 at 4:04 PM, Peter Robinson pbrobin...@gmail.com wrote: I'm not sure something like sugar which is (and should be) fast moving mixes well with something like CentOS or its parent. At the beginning of the v6 release cycle begins it will be fine but within 12 months I'm sure everyone will want the features that are provided by the I read everyone here as programmers and early adopters. It has been suggested that other people (regular teachers for example) might care more about the stability of the total user experience rather then new features. latest release of gtk/glib/gstreamer/python/telepathy etc that just won't be available in v6 so we en up in a situation we've been in before where we either need to fork massive amounts of packages to get the features everyone wants or moving back to Fedora. Both which will require lots of work. I know what its like as I've spent lots and lots of hours getting the changes merged upstream. I don't doubt that it was a royal pain. But I believe the situation we are discussing now is a little different. This isn't a situation where the functionality that is required to provide core use cases isn't available anywhere. From the outside, it seems like most of this has been pushed upstream and will be maintained by others. Now we are talking about what new functionality that comes in from the outside should be made part of the core requirements to run current releases of Sugar. Should Sugar releases really require the latest version of everything (as defined by the latest Fedora) in order to function correctly? Bill Bogstad ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] [SLOBS] Long-term support for Sugar (was: slobs... blah blah)
[trimmed some cc's - they are probably on these lists anyway] On Mon, Sep 21, 2009 at 5:07 PM, Peter Robinson pbrobin...@gmail.com wrote: Well it wasn't a royal pain if you didn't have to co-ordinate between about 8 different parties. And most of the the latest releases were in fact defined by the Sugar Development and had nothing to do with Fedora at all so I suggest you do some research to find out the facts before you actually define royal pain. Things like Telepathy Tubes were pushed forward to allow things like abiword (Write activity) collaboration. There are still things that are being merged into mainline that have been used by Sugar for a while and in the case of abiword its only the soon to be released abiword 2.8 that will finally merge those changes Is that light at the end of the tunnel or just an oncoming train? i.e. Do you think that it will ever be the case that most Sugar activities won't need special features from the base system to function adequately (note I don't say optimally)? If you think this is possible, what time frame do you see this happening? By Fedora 13? Fedora 14? In your lifetime? If it's more then a year then this conversation is probably premature. If it's less then that, then it's just about the right time to decide if long term support is something that matters to SugarLabs and how to address it if it does. Bill Bogstad ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] The Future of Sugar on a Stick
On Tue, Sep 15, 2009 at 6:36 AM, Martin Langhoff martin.langh...@gmail.com wrote: On Tue, Sep 15, 2009 at 10:24 AM, Tomeu Vizoso to...@sugarlabs.org wrote: We already have de...@lists.laptop.org for OLPC, fedora-olpc-l...@redhat.com and others for Fedora, debian-olpc-de...@lists.alioth.debian.org for Debian, ubuntu-sugart...@lists.ubuntu.com for Ubuntu. Why SoaS would be different and share the mailing list with the upstream developers? And I think it is wrong and counterproductive to have so many mailing lists. - All have very modest subscription numbers, and very low traffic. - Anyone has to follow a lot of them to keep track of things! - But most importantly: *where the hell am I supposed to post anything*? We'll have even more cross-posting in lists where you have 90% overlap, and to make matters worse, some of the lists involved here have broken Reply-to settings that _break_ cross-list discussions. So replies to a crosspost that involves fedora-olpc for example _break_ the discussion. Human brains s are _excellent_ at filtering, and we are a small group. Yes, all of these are sub-projects of a grander Sugar (and Fedora, and Debian, and Ubuntu, and OLPC) vision. These subprojects deserve a separate identity -- but a separate identiy does not equal a separate forum of discussion. We all talk in one shared space, but retain our name and affiliation. We need to hear all the voices and we naturally filter the messages that are relevant. You seem to respond with this same argument every single time someone suggests a new mailing list whether about SugarLabs or previously about OLPC lists. I would like to suggest you consider the following: Your definition of low traffic might not be the same as someone else's definition. Full time contributors are likely to have different needs/desires then part time contributors or just interested parties. Your interests are not always the same as everyone else's interests. Personally, a project doesn't have it's own identity unless it has a separate mailing list. Until then it's just some random mailing list threads. My impression is that some people feel similarly. Your brain may be able to keep up with and separate relevant from irrelevant messages easily. Personally, I would like some more from technology to solve my human problem For me, different lists is one way to do this. It also doesn't require me (and everyone else) to remember to put funny things in their Subject line. BTW, reply breakage is a REAL problem. (I hate it myself.) It's also a technical problem. It has a technical solution. On the individual level, you could sign up for every single SugarLabs, etc. list. I've now done this for the most common cross post lists at SugarLabs. You could also set up an email alias in your address book which would send every message you send to every single one of those lists. You would then have the single community that you seem to desire. Though, I suspect that a lot of people would start objecting if you took that last step and used it regularly. Personally, I did the above and marked a number of lists 'no delivery' since I'm not normally interested in that topic unless it is crossposted. On a more general level, I did some investigation and forwarded an idea to Bernie that I got from the mailman support people which could alleviate the problem for SugarLabs lists. Basically the idea is that if you are subscribed to any of a set of lists you can post to any of them, but you won't get mail from them. The advantage of this is that as new lists are created, it would require no work on the part of mailing list subscribers. It's is a bit hack so we'll see if Bernie and company decides it's feasible. Finally, please consider all of the above for the sake of my overloaded brain. Thanks, Bill Bogstad ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] SLOBs Position on SoaS
On Fri, Sep 18, 2009 at 2:20 PM, Martin Dengler mar...@martindengler.com wrote: On Wed, Sep 16, 2009 at 12:39:08PM -0400, Bill Bogstad wrote: This note is only tangentially a response to Peter Robinson's... Here's my thought process... [meta: it's hard to know to what email are you replying or to what topic you're speaking] [Yes! :-)] Sorry. It was a general response to giving SoaS a more separate identity. (Which I think is a good thing.) At the same time, there seems to be a lack of consensus of what SoaS actually is or what it's goals (use cases) should be. And therefore what such an identity would be. It's possible that those questions will only be answered after SoaS (and the core people involved in its creation) have a place to discuss this without flooding the people who don't care. I ... don't think we can leave Sugar LiveUSB to any distribution. What is Sugar LiveUSB? Is it SoaS? That's my question. So far Strawberry (and it's variants, successors) is the only LiveUSB environment that I know of that makes Sugar the default UI If someone takes any of a number of other LiveUSB environments and makes Sugar the default, will that be SoaS (but not Strawberry). Maybe Sugoppix? :-) I hope that I have clarified somewhat. Bill Bogstad ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] SoaS: Searching for Decision Panel volunteers.
On Fri, Sep 18, 2009 at 4:27 PM, Chris Ball c...@laptop.org wrote: Hi all, Sebastian Dziallas has asked for clarity on how the SoaS distribution he maintains is going to be treated and considered by SL. It doesn't seem that there's consensus, so we suggest forming a Decision Panel: ... This mail is to ask for volunteers for the Decision Panel. Volunteers can be anyone with an interest in the outcome, and the Oversight Board will then vote on (a) whether to convene the panel, (b) who should be on the panel, and probably (c) what the decision being paneled is. :) Please volunteer by replying to this mail if you're interested, and please do so by Thursday September 24th so that we can run the vote at the Friday September 25th SLOBs meeting. I'm willing to be on the panel, but strongly believe it should be balanced. It's probably obvious which way I lean so some people with differing opinions might be a better choice. (Community members who haven't expressed an opinion are important as well.) Bill Bogstad ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] SLOBs Position on SoaS
This note is only tangentially a response to Peter Robinson's... Here's my thought process... Computer technology can improve education for children. Collaboration (i.e. Sugar) and free software (i.e. Linux) is the best way to make this happen. The question is how do we get educators/schools to start using (or switch to) Sugar/Linux for children's educational computing. We can go down a route similar to OLPC. Tell them to buy new hardware (XOs), buy new server hardware (to run XS), reconfigure their networks (Xs controls all network access). (i.e. Convince people at the top of the organizations) Or we can put together software systems which disturb pre-existing technology as little as possible. Require as few new hardware purchases as possible. Not require schools to make either/or decisions. Instead let them use old AND new. This is probably a 'developed world' point of view. The original goal of OLPC was to bring technology to places/children who have no access at all. They did this through better/cheaper hardware. Sugar, however, is inherently software. There is nothing SugarLabs can do other then to try to support the widest range of hardware possible. However, widespread use in the developed world on old/cheap hardware isn't a bad thing. More real world usage will (hopefully) result in more contributors and make it a better system for all users. As a result, I think the second approach is fundamental to getting Sugar used and therefore improving education. I also believe that SoaS is fundamental to supporting old AND new environments and therefore is fundamental to changing children's education. Personally, I don't care what Linux distribution it is based on. (My personal desktop is Ubuntu, but I'm fine with SoaS being based on Fedora.) I also don't think we can leave Sugar LiveUSB to any distribution. My impression is that both LiveCD and LiveUSB Linux distributions are essentially gimmicks for all of them. Does anybody other then SoaS use (or hope to use) Live environments for regular operations for thousands if not millions of users? Given the above, I conclude that SoaS really needs to be something that SugarLabs supports. That doesn't mean that Sugar should be tied to SoaS, just that it really is a fundamental part of changing education. Bill Bogstad ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] SLOBs Position on SoaS
On Wed, Sep 16, 2009 at 8:22 PM, Douglas McClendon dmc.su...@filteredperception.org wrote: Bill Bogstad wrote: ... I also don't think we can leave Sugar LiveUSB to any distribution. My impression is that both LiveCD and LiveUSB Linux distributions are essentially gimmicks for all of them. I generally agree with the rest of your sentiments in this mail, but as the now quasi-official 'Godfather of Fedora LiveCD' I have to respond to this 'gimmick' claim. I'm sorry if you were offended by the word gimmick. A better word might have been niche. From the first time, I saw Knoppix Live media system were clearly interesting and useful. However... In summary - LiveUSB == primarily trial and installation medium. I.e. perhaps the thing that _generates_ 'installed-normal-nonlive-fedora-on-a-stick' on sticks whose flash is performancewise on par or better than a usb rotating disk. Even you don't see this as a normal everyday usage model. Assuming that to be widely used, Sugar needs to support this model where do we go from here? Should Sugar wait for distributions to make it more usable? Am I wrong about this being vital to Sugar success? Linux itself got its start coming in the backdoor. Given the lack of marketing dollars available to Sugar, I think a similar strategy is worth considering. You second message about changing flash/filesystem technologies brings to mind a discussion on a different mailing list about whether SSDs are appropriate for use as journals for enterprise databases. Many people are finding that they see great performance improvements. There are quite a few netbooks out there at this point and I haven't heard anything about massive flash failures at those price points either. I'm wondering if people are just scared of the fact that flash is different then hard drives. The differences aren't all bad either. Flash doesn't suffer from head crashes where you lose read access to ALL your data. Instead, you probably slowly lose the ability to change it. Somehow that sounds better to me. When Sugar was being run an XO which had its flash soldered to the motherboard, it made sense to care alot about reducing flash writes. If SoaS is deployed with integrated XS backups of user files, so what if the USB flash drive only lasts a year or two. It's still way cheaper then the cost of an XO. [This presupposes some actual testing to determine what the typical lifespan would be.] Bill Bogstad ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Sugar on a Stick v2 Release Naming
On Mon, Sep 14, 2009 at 10:27 AM, Sean DALY sdaly...@gmail.com wrote: As long as no one (including developers) is confused that SoaS release 1( Strawberry) alias SoaS-2 is running Sugar v0.84 and Fedora 11. I'm just wondering why SoaS-2 is in use... non-initiates will assume that means SoaS release 2 (Blueberry), don't you think? I'm a long-time watcher of the mailing lists and (now) a developer and I was/am confused. What do you think is going to happen when some random IT guy/power user tries to report problems? At a minimum, there needs to be a prominent wiki page somewhere documenting which number corresponds to what. And it IS a mess. If someone says that it will be fixed in Sugar 0.88 (which is likely to be the response from a developer), as an end user (or supporter of same); I shouldn't have to dig through mailing list archive archives to figure out what that means. As for these numbers not being visible, that's just wrong. The pilgrim 'version' number is displayed every time I boot an SoaS ISO on my machine. The CD label is in the isolinux.cfg file, which is practically the only file on a burned ISO whose contents can be viewed without growing through wizard level Linux incantations. As for ISO filenames: http://download.sugarlabs.org/soas/releases/soas-2-beta.iso is the same as: http://download.sugarlabs.org/soas/snapshots/3/SoaS3-200908302159.iso and http://download.sugarlabs.org/soas/releases/soas-strawberry.iso equals http://download.sugarlabs.org/soas/snapshots/2/Soas2-200906221314.iso Anybody who is curious (isn't that what we are encouraging) is likely to find at least one of those numbers. The problem will come when they don't find ALL of them and realize they have to be careful when reporting problems. We are punishing them for their curiosity by having a gratuitous inconsistency. Unfortunately, I don't see any other fix then to document what corresponds to what. This is a software (release) engineering issue. The problems will come from non-developers and will only start to happen once there is more then one public release. To: Martin: I'm not objecting to v2 (we have no choice). I'm saying we have to publicly document what goes with what. Bill Bogstad ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] The Future of Sugar on a Stick
On Mon, Sep 14, 2009 at 11:32 AM, Sebastian Dziallas sebast...@when.com wrote: +1 to pretty much your whole message. I would like a little clarification though on the boundaries of SoaS. My interpretation is as follows: SoaS takes the XO 1-1 model and replaces the one machine per student with one stick per student. CD, hard drive, and floppy boot helpers are part of SoaS to the extent that they make SoaS sticks usable on a wider class of machines. Installing a user's files to a hard drive is not (probably should not be) a SoaS goal (the user's environment is no longer portable to other machines). Storing the SoaS OS files on a hard drive for performance/stability reasons might be a SoaS goal. The fact that the SoaS ISO allows one to demo Sugar is an accident of implementation. The real goal is bootable SoaS sticks. I think a demo ISO is a great thing, but that doesn't have to be something that SoaS produces. From my perspective, a bootable CD that gave you a simple menu to generate a SoaS stick would be much preferred to the current download the ISO image and then do these complicated things with it. Support for multiple users on a single stick is not a goal of SoaS (breaks 1-1 assumption). I realize that many of the above assertions are not what some (most?) deployments want to hear. I'm not sure I like them either. I just want some clarity. Looking forward to a SoaS mailing list, Bill Bogstad ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] [SoaS] The Future of Sugar on a Stick (was [Sugar-Devel] The Future of Sugar on a Stick)
b On Mon, Sep 14, 2009 at 2:04 PM, Luke Faraone l...@faraone.cc wrote: On Mon, Sep 14, 2009 at 13:56, Walter Bender walter.ben...@gmail.com wrote: To Martin's point, how about the routine use of a filterable tag, [SoaS] , in the Subject to messages appropriately routed to either IAEP or Devel or both? I just created a Sugar on a Stick topic on Sugar-Devel's mailman, which matches the pattern [SoaS] in the subject of a message. If we are going to go down this route (which I still believe is inferior to having separate mailing lists) then you need to: Modify this page to list all of the current sugar-devel topics (we are now up to four): http://lists.sugarlabs.org/listinfo/sugar-devel as well as letting people know there and in the welcome to the list email how they can modify their subscription options at: http://lists.sugarlabs.org/options/sugar-devel so they only get messages on the topics that are relevant to them. Upon rereading Walter's note, I guess you need this for IAEP as well. While we are at it, can we get [GPA] topics as well, since we can't have a GPA mailing list. Bill Bogstad ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] [SoaS] The Future of Sugar on a Stick
2009/9/14 Philippe Clérié phili...@gcal.net: +1 I made a similar suggestion a couple of weeks back. Thinking as someone who will probably be in it up to his neck, on the teaching side, what I would like to see is a polished distribution, installable on a hard disk, released once a year around April-May. That will ... So you probably disagreed with my statement that SoaS is not about installing user files to a hard drive. Or do you mean having the Base OS on the drive, but the user files/activities directory on a stick? Given the wide range of school schedules world wide, I'm not sure if it is reasonable to try to synchronize release schedules with any particular schedule. I'm willing to be educated if there is in fact some consistency. I'm just not willing to support something like that without more data. It also seems like there is a desire among core Sugar developers to do releases more often then this as well as a desire to synchronize with Fedora's six month schedule. On the other hand, It seems like what you want is some hope that you will get some support (security patches?) for longer then until the next six month release. Given that Fedora itself is only supported for 12-13 months after release and SoaS resource constraints, I don't see any way to get more then that. It seems plausible though that Fedora security and other patches could be made for available for SoaS releases as long as they are available. Until Sugar reaches 1.0, I don't think it makes much sense to expect much in the way of support for older Sugar versions unless the problems are particularly bad. It would be better if a 'real' Sugar developer could respond to this. I just do SoaS... Bill Bogstad ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Bill Bogstad's floppy disk boot (Soas)
On Sun, Sep 13, 2009 at 10:48 AM, Caroline Meeks solutiongr...@gmail.com wrote: I tested this on the GPA computer lab computers. It takes about 1 more minute (4.5 vs 3.5) to boot. I think that it will take more then a minute on average to give all the students CDs, have them open the CD drawer, turn off the computer, turn it on again and collect all the CD at the end of class so that the next class boots into Windows. My plan is the floppies can just live in the machines, not pushed in all the way. The current version requires the user to press enter 1 minute into the process. Can we get a version that we just start the boot, then goto the rug for our lesson and 4.5 minutes later the machines are booted? As I already mentioned in my note to Art, it's easy to edit the kexec-loader.conf file to set the delay to anything you want by modifying the timeout off line in that file. You can do this yourself easily. I was under the impression that the students 'owned' their sticks and took them home from the GPA. In that scenario, it makes no sense for the machine to finish to attempt booting until the student arrives at the classroom and can insert their personal stick. If you are using generic SoaS sticks, then you can modify the config file to boot immediately as Art did. WARNING WARNING WARNING You may find that this doesn't work on some machines. On my test machine, if you have a USB stick inserted when you power it up; it won't boot at all (from anything). The BIOS apparently gets confused and just gives up. WIthout changing the BIOS, there is no way to get around this problem. If you have a machine like this, you will have to come back to the machine after the BIOS gets done anyway. Having a prompt made sense in that scenario and I made configured the image that way since I didn't think it would hurt in the use cases I was considering. Change it, it's easy... Good Luck, Bill Bogstad ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Sugar on a Stick v2 Release Naming
I've been watching this thread since it began and understand that from a marketing perspective numbers are 'ugly'. On the other hand, everyone seems to acknowledge that numbers make it easier to track things from a development and deployment support perspective. Obviously, that works best if the numbers are consistent. Unfortunately the number usage has NOT been consistent. Martin's original web page with proposed logos seems to indicate that the SoaS Strawberrry release was release 1. SoaS 1 is also what shows up on the the 'ugly?' text oriented plymouth start up screen for Strawberry as well. On the other hand, the CD labels as well as the ISO filenames for Strawberry and its test releases all referred to themselves as SoaS2. The current Blueberry? beta ISO calls itself SoaS3 internally in the same places that Strawberry calls itself SoaS2. From a deployment support perspective, this is not a good thing. Unfortunately, I can't think of anyway to sink the numbers up again that won't result in additional possibilities for confusion. Are we stuck documenting the fact that the official release number and plymouth displayed versions are always one less then the CD label and ISO filename? Bill Bogstad ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Bill Bogstad's floppy disk boot (Soas)
On Fri, Sep 11, 2009 at 12:00 PM, Art Hunkins abhun...@uncg.edu wrote: With regard to Bill Bogstad's floppy boot disk project for SoaS: it works flawlessly for me. (I've tried it successfully on both an older Windows laptop and desktop - vintages: Pentium II/III.) Thanks for the feedback! I wasn't aware that Walter was going to announce it this week so I quickly went and put a README.html file at the location he published so people would have some idea what to do with it. I've one suggestion for Bill: for use by children, I'd make everything as automatic as possible. Either delete the display where the user needs to make a choice (it's *way* technical and *I* didn't know what to do), or put a (10?) auto-timer on it so that it goes on through (the usual way) without user intervention. It's easy to put a timeout in or even eliminate the delay entirely. Because a floppy is easily writable (unlike a CD) you can even do it yourself. There is a text file called kexec-loader.conf on the floppy. You should be able to edit it with any text editor and change the line timeout off to have a number instead. It can be either 0 (boot immediately) or wait the specified number of seconds. If you look at the rest of the file you can get some idea of what is going on. It's probably a good time for me to point out that I didn't write the software. I just found it and worked with the author to fix some bugs/suggest features that made it work better for GPA. You can find more info about it at: www.solemnwarning.net/kexec-loader. The image I supplied is based on the authors most recent release 2.1.1. Speaking of GPA (who originally requested it), the 'wait for user input' is a good thing for their usage case.. They use a shared computer lab and wanted to be able to have an instructor go around the room inserting floppies and turning machines one before the students get there. (Booting from floppy is slow.) My understanding is that they plan to have students come in, insert their stick into an already powered up machine, hit enter, and then go over what they plan to do during that computer lab with the instructor. Other environments may want something different. Since floppies are writable changing timeouts and the menu text is straightforward. For Windows people: I suggest creating the boot disk with RAWriteWin. It's simple, user-friendly and efficient. Thanks for the info. I was hoping there was something other then rawrite.exe, but I hadn't researched it. Take care, Bill Bogstad ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
