Talk:Sugar on a Stick
Installation
While it is easy to find the download instructions, the non-GUI installation instructions are hard to find [1][2]and I don't know where the GUI instructions are.[3] --Walter 21:28, 4 June 2010 (EDT)
Sugar on a Stick/FAQ
See Sugar on a Stick/FAQ and Talk:Sugar on a Stick/FAQ. For older versions of this page, see /Archive.
There's a lot going on in this thread; here is my attempt to summarize discussions so far. If I've missed or misstated anything, please correct me. Last updated by Mchua 04:14, 24 September 2009 (UTC)
What are we talking about?
Part of the ongoing discussion is meant to clarify and answer the question "What is SoaS?" The other part of the discussion is exploring "where SoaS could go in the future," for various definitions of "SoaS." (Proposed Next Steps)
What is SoaS?
SoaS is a Linux-based, Sugar-running, delivered-on-a-thumbdrive distribution focused on customizability, deployability, and local support, and meant for 1-to-1 use in schools.
The term is currently used colloquially to refer to several things:
- the code, based on Fedora, that Sebastian has been working on (...for lack of a better descriptor)
- any bootable thumbdrive running Sugar on top, whether based on Ubuntu or Fedora or Debian or $DISTRO.
- "the physical product SL is marketing to end-users right now"
Proposed next steps
Formalize what SL project status means for SoaS spins
SoaS development and Sugar platform development are two separate projects done by different groups; one for Sugar platform development and one for each SoaS spin. There is currently only one active SoaS spin, and it is the Fedora-based project being driven by Sebastian Dziallas, for a current grand total of 2 project groups; however, there may be other SoaS spins in the future.
Exactly what it means to be a SL project is still an open question.
- What are the criteria a SL project must meet (including requirements for ongoing engagement/contribution)?
- How does something become a SL project?
- Who determines whether a project meets these criteria?
- How do they make that determination?
- Is there a schedule and/or timeline for this determination?
- How does someone initiate the process for requesting SL project status, and who can do so?
- What happens if it is determined that a project does not meet these criteria?
- How does a SL project become not a SL project, and for what reasons might this happen?
- What benefits (mailing list, etc.) does a SL project get?
- How can all of the above answers be amended if needed in the future?
- What is the list of current projects that we are considering including in the initial "this is a SL project" approval round, and what do these projects have to do in order to be approved for the criteria?
Who decides: These decisions need to ultimately be ratified by SLOBs. It's been suggested that Sebastian's Fedora-based SoaS spin be the test case for the first "SL project," so it makes sense to start out on the SoaS mailing list to come up with a set of proposed answers to these questions that will work for the projects themselves, then ask SLOBs to formalize them (with more discussion/modification if need be).
Determine what "Sugar on a Stick" refers to
Options:
1. SoaS is a generic name usable by anyone who produces a thumbdrive-bootable Sugar, regardless of what distro, etc. that image may be based on. Since SL owns the SoaS trademark, there may be an application and approval process for projects that want to use the trademark/name, but there would be multiple "$DISTRO Sugar Spin", "$DISTRO Sugar Remix", "Sugar on $DISTRO", etc. projects.
2. SoaS is a "marketing name" used by SL as a pointer to the thumbdrive-bootable version of Sugar that SL wishes to promote at any given time. So for one press release, SL may go point to SUSE-SoaS and say "Everyone, this is SoaS!" and the next time point to Mandriva-SoaS and say "Everyone, this is SoaS!" (Note that options #1 and #2 are compatible.)
3. SoaS is a product name that refers specifically to the Fedora-based code Sebastian is working on.
Who decides: A decision panel convened by the SLOBs (the latter is happening now), with strong input from both the current "SoaS" team and the Marketing team. See this mailing list thread calling for discussion panel volunteers.
Completed next steps
Make a SoaS mailing list
The list was created at http://lists.sugarlabs.org/listinfo/soas after reaching consensus on the ticket requesting that the list be created, http://dev.sugarlabs.org/ticket/1419.
From the list description: "This list is intended for discussions related to the development of Sugar on a Stick, which is located in the Sugar Labs wiki. User feedback can also be directed to feedback@sugarlabs.org and the IAEP (It's An Education Project) mailing list. Upstream development and discussions of Sugar take place in the sugar-devel mailing list. Other LiveUSB Sugar projects are invited and very welcome to share their concepts, ideas and thoughts on-list, too." Also see the log from the informal IRC discussion about mailing list creation for more context.
Side questions
Determine whether SoaS is a SL-endorsed way of distributing Sugar
The consensus here seems to be that yes, SL should endorse some form or forms of distribution of Sugar on a thumbdrive using the name "Sugar on a Stick." The mission of SL is to "produce, distribute, and support" Sugar, and SoaS gives SL an easy, concrete way to demo, deploy, and therefore distribute Sugar.
Determine whether SoaS is the SL-endorsed way of distributing Sugar
Whether SoaS should be *the* SL-endorsed way of distributing Sugar is another question. Is SoaS the way that SL distributes Sugar directly to learners?
Support:
- Marketing-wise, this would be a key tool in creating widespread awareness of Sugar and having that awareness all point to a single cohesive effort.
- Since Sugar is free software, this does not preclude other distribution methods from being created and promoted independent of formal endorsement from SL.
Concerns:
- Thumbdrives are not the answer for everyone; for instance, LTSP-like compatibility may make more sense in some situations. We should not lock ourselves into a single distribution method.
Who decides: This seems to be dependent on two other decisions:
- The decision on what "SoaS" refers to (which is within the scope of this discussion)
- The decision on "whether SL wants to produce an end-user product" (which had several pros and cons mentioned during the thread, but is probably outside the scope of this discussion)
Both decisions would be made by SLOBs or a decision panel convened by the SLOBs. This issue is a peripheral one that isn't particularly within the scope of the current SoaS discussions in this thread, though.
Side notes
SJ Klein: "I would find it a refreshing counterpoint to have a group in this ecosystem focused on maintaining a toolchain that first prioritizes the overall teacher and classroom experience, and second prioritizes hardware, OS, and software details. Some of its core releases / components / packages (for instance, a new social & procedural system for getting help or processing feedback) might not involve a single transistor or line of code."
Feedback from a first grade teacher: What teachers care about: (1) Is it friendly? (2) Is it consistent? (3) Can the effort needed to maintain it be sustained? What they don't care about: (1) What group "runs" it? (2) Who owns the trademark? (3) What bleeding-edge features are being developed now for a future release? (3) What is the underlying technology? What would reassure them: (1) Peer support. (2) Seeing it in action, so they can create a "mental paradigm" category for something like Sugar/SoaS.
Added Notes:
- 1.) F12(rawhide) and opensuse-edu now distribute a dual mode live.iso of Sugar-Desktop which boots into sugar as a CD or can be used to dd write to a USB/SD "stick". (persistence is a work in progress on these)[[4]] [[5]][[6]][[7]]
- 2.) Sugar from multiple distros is available[[8]] as a VMPlayer or Virtualbox "Appliance" which can be stored on a USB/SD "Stick" and thus is transportable with (persistence) from PC to PC.
- 3.) There are "full installs"(real file structure-not a live system) of: Sugar, Sugar+Gnome, Sugar+KDE on larger(4GB+) USB Sticks which are available for download [[9]]in compressed form that can be written to a bootable USB/SD with a dd command in several minutes.
Added Notes:
from Soas lists:
Rubén Rodríguez Pérez
- Trisquel-Edu (Live USB)
- Trisquel-Sugar (Announced 09/28/2009)
I will further explain the differences:
We are including the Sugar packages in both our 2.2 LTS version (where you can find the Trisquel Edu edition), and in our new 3.0 STS version. All our live Sugar images will be based on the STS one, as it will provide better hardware support.
Trisquel Edu, which is a GNOME based educational system, can run Sugar as an alternate environment, or serve it via LTSP. The Edu edition (like the Pro one) is only available in the 2.2 LTS version of the distro. It will be the recommended version for large Sugar-on-Trisquel deployments.
Development notes
Processes we should document.
- How to make a remix:http://wiki.sugarlabs.org/go/Sugar_Creation_Kit#Instructions
- minimal kickstart file
- Package selection: timeline and criteria. How does stuff make it onto SoaS?
Some checksum hash(s) please
The following links are missing the SoaS SHA256 checksum/hashs
http://fedora-spins.c3sl.ufpr.br/alt/spins/linux/releases/15/Spins/i686/Fedora-15-i686-Spins-CHECKSUM http://fedora-spins.c3sl.ufpr.br/alt/spins/linux/releases/15/Spins/x86_64/Fedora-15-x86_64-Spins-CHECKSUM
Could someone post a png or gif of the hash for these files here since fedora won't update this until F16(Verne) is out.
--Chief Mike 11:29, 18 October 2011 (EDT)
- sha256sum 95650ec1257670e44466e75059ff8b05f636cd78658a025ae52c8992145f778c Fedora-15-i686-Live-SoaS.iso
- md5sum 67dc6fe4625f61d9d51f89c082f3c9c3 Fedora-15-i686-Live-SoaS.iso
- sha256sum aa18f9dae1fe8d9bde47a45fefd19f2127dfc1001de3c1f76fbc1f85ec576e0d Fedora-15-x86_64-Live-SoaS.iso
- md5sum db209baffdef41b7ca029b6e224ed7d1 Fedora-15-x86_64-Live-SoaS.iso
- from my copies --FGrose 12:30, 18 October 2011 (EDT)