There's OBS (build packages for multiple distros) and suse studio, the
latter builds isos, and if I understand it correctly not just suse isos,
its kind of a drag and drop tool where you choose what your iso should
contain
And I would hardly say openSUSE is a minor distro... next to Ubuntu and
Fedora, probably the most known and used... though I guess much more so
outside the US, seeing as its German in origin...
kind regards,
David Van Assche
On Thu, Jun 2, 2011 at 11:20 AM, Aleksey Lim alsr...@activitycentral.orgwrote:
On Thu, Jun 02, 2011 at 06:29:51PM +1000, Sridhar Dhanapalan wrote:
On 28 May 2011 08:31, Aleksey Lim alsr...@activitycentral.org wrote:
On Fri, May 27, 2011 at 11:39:54AM -0400, Bernie Innocenti wrote:
On Fri, 2011-05-27 at 21:14 +0545, Abhishek Singh wrote:
Dear All,
I've put down my OLPC XS wishlist at
http://asingh.com.np/blog/olpc-xs-my-wishlist/ . Please comment
upon it.
Thank You.
Thank you! Forwarding this to the Dextrose list as well.
I've also CCed guys who do XS work in .au
Abhishek: thanks for sharing your wishlist.
From my side, I see the whole picture in case of school server like
having:
* sugar-server[1], the base of any school server. it doesn't provide
stuff like moodle (too complicated to be basic) or puppet (useless on
this level, since configuring sugar-server should be just install
packages/iso and do some automatic work, the higher levels might user
puppet or so)
* any additional services that might be useful in some deployments but
are not basic, eg, moodle or wiki.
sugar-server should provide needed info via reliable API for these
services.
in my mind, such services might be formed as separate projects (like
sugar-server-moodle) to make it possible to attach it on purpose
(there might be useful configuration tool that is being used in
sugar-server, mace[2]).
* final products that include components on purpose (but sugar-server
is
a required one). It is entirely depends on local needs.
We are looking to make our XS-AU[0] more modular to suit different use
cases. Our initial goal
(completed over a year ago)
If I got it right, it is still the same OLPC XS code base but w/ tweaks?
sugar-server in that case is a new project w/ more tough and localized
design.
work on a single interface to integrate well into existing networks.
Installation is via USB and fully scriptable via kickstart files.
The current XS is very monolithic and bureaucratic. It requires
moderate sysadmin skills to install and maintain. Maintaining the
presence service is cumbersome and impractical in our schools. The
turnover of teachers and students is far too high to ensure that
anything gets managed properly.
We're looking to slim down the XS-AU such that we can have a simple
collaboration server (which we currently call XS Lite) that is
installable in a classroom as a drop-in appliance.
ie, just having jabber server and somehow let students know where it is?
is an ejabberd.
btw, I'm planing to use Prosody instead of ejabberd. I have really bad
experiance w/ ejabberd - on jabber.sugarlabs.org it eats too many
resources for regular 10-30 online users. Prosody is slim and light app
and it alsready works fine w/ sugar-0.88.
Registration, Moodle, Squid, backups and so on are
unnecessary. Each teacher can run their own server for their own
class. Conveniently, this could easily run on an XO (XS-on-XO).
in other workds there is no need in sugar specific stuff at all - just
install jabber server from packages (maybe w/ sugar specific patches) and
write its url on studensts' boxes.
My own running though your wishlist keeping in mind sugar-server plans:
1) Porting XS to new version of Fedora
sugar-server will be build on OBS[3] for distros that are being used
in the field (deb or/and rpm based).
So, downstream can just use these packages, add new one and create
the final product (there is an idea to teach OBS to create isos for
not only SUSE, obs is designed originally)
You're using SuSE as a base? That sounds like an awful lot of work
porting to a distribution that isn't widely used. Why not stick with
the current platform, which benefits from Red Hat engineering and has
a much larger developer, installation and user base? Not to mention
that the XOs use the same platform, meaning that skills can be shared
across client and server.
OBS is not only suse (in fact, they renamed it from openSuse Build
Service to Open Build System recently). In other words, it can create
package for any rpm/deb based distro, but, afaik, it can create iso only
for opensuse for now (and plan is looking how it might be done for other
distros, but anyway using obs as a packages farm is good w/o having
isos).
The XS-AU has been working pretty well on Fedora 11 for quite some
time. We've
