[Csped] Power2People Goals (and a question)
Glenn Kavanagh
gkavanag at Trinity.edu
Fri Feb 2 20:35:47 CST 2007
Tim hits on a very good point about the operating system. However, I
would say that using distro like Gentoo would be even better than
Ubunutu. There is a large support for Gentoo, and you can compile
everything (applications included) to run faster for your specific
platform (processor). Usually this would prove to be a difficult task
for someone inexperienced with Linux, but we are trying to make a system
that receives updates on it's own. Because we are building identical
machines to distribute, we can compile all of the new applications where
ever the central server is located and then allow the users to download
the newly compiled updates from our Master Server.
Along with this, GNOME and KDE are likely out of the question because
they do have a fairly big memory footprint. Xfce would be a good choice
because it is much lighter weight, it can run anything written to run
for the GTK+ toolkit (GNOME), and is also user friendly. If we get
desperate for resources, we could always go with just a window manager
(e.g. FVWM), instead of an entire desktop environment. If we chose this
route, we wouldn't be able to run Open Office and would have to rely on
AbiWord and an equivalent Spreadsheet application.
As far as portability goes, it seems that the more portable, the more
expensive the system is going to be (see current desktop price vs. and
equivalent laptop price). This would be one of the first problems that
the hardware team would need to look into.
From the power and network access point, I think that we could take two
different approaches here. One, assume that we have both of these. Dr.
Howland mentioned that we could assume the environment that we are
working in has certain amenities. Power and a network connection
(wired/less) could be those things. The other would be to take one or
both and come up with a plan to provide them for the users. I think
that designing a way to efficiently provide a networking solution could
even be one of our team's goals.
As for restoring the machine to its original state, that could pretty
easily be done over the network... I think. Essentially we just save
the users' home directories and overwrite any files that are out of sink
with the state they should be in by default.
So for the teams, I was thinking something along these lines:
1. Hardware
2. OS
3. Applications
4. Network Infrastructure (this could include the main server and
distributing updates)
Preference: working on the OS portion.
Glenn
Tim Nunamaker wrote:
> I think it's fairly obvious that some Linux distro is going to be our
> best bet for the OS/software. As Dr. Howland mentioned, I think Ubuntu
> would be a pretty good choice. I've only been using Linux for a few
> months, and I've only used Fedora and Ubuntu for extended periods of
> time, but I do know that Ubuntu has a lot of community support and I
> haven't really had any major hardware configuration problems. Other
> distro's like Slackware would simply be too difficult for inexperienced
> users to operate.
>
> In particular, I think Xubuntu looks pretty appealing:
> http://www.xubuntu.org/
>
> >From the main page: "Xubuntu is a complete GNU/Linux based operating
> system with an Ubuntu base. It is lighter on system requirements and
> tends to be more efficient than Ubuntu with GNOME or KDE, since it uses
> the Xfce Desktop environment, which makes it ideal for old or low-end
> machines, thin-client networks, or for those who would like to get more
> performance out of their hardware."
>
> Sounds like just what we need. The only disadvantage to using it vs
> GNOME or KDE that I can think of is that it's less mainstream and so
> there is less support and it also wouldn't support all of the KDE/Gnome
> applications so well. On the other hand, I think that's a fair trade off
> considering our design limitations.
>
> The huge benefit that I see to using Linux is the availability of so
> much free software. I can't think of anything we would want to put on
> the machines that we couldn't get in a matter of minutes, especially
> using a package manager such as Yum or Synaptic. This will be an
> especially useful feature for the end user, who will probably have
> limited access to software otherwise. In addition, major Linux distros
> usually have pretty good support for languages.
>
> Now that I've got that out of the way... I think Joey question about
> portability is an important one. This is going to affect not only the
> hardware that we can use (as well as its cost), but also how we deploy
> the units as a whole. If we go the route of building desktops with big
> towers, then for any kind of update capability the user will most likely
> have to have some kind of local network/internet connection, or some
> means of transporting a big computer to a location where he/she can
> access one.
>
> I think a laptop would be a bit on the extreme side as far as
> portability goes. If we can possibly squeeze the size down to something
> like the Dell machines in the library, then they will be transportable
> but can still use some standard components. In addition, the machines
> don't have to have built in displays to be portable. In the case of Dr.
> Howland's example, the school, maybe students can bring their computers
> home and plug an old 15" CRT into them, which might not be too expensive
> (depending on the cost to deliver a bulky item to a distant location).
>
> I think the best way to approach this project is to, at the least,
> assume the following:
>
> Users will periodically have access to power (maybe they can charge a
> battery).
> Users will periodically have access to either a: the internet, or b: a
> network with software updates available.
>
> Joey mentioned the possibility of connecting the machine to a more
> powerful machine for updates. I think this is an important point to
> consider. Maybe we can design a system where a central, powerful machine
> makes up for some of the weaknesses of the smaller ones, which can
> connect to it. If anyone can think of specific applications of this,
> please chime in.
>
> I also think we need a way of restoring the machine to its original
> state. I think this can be easily done by distributing a few CDs or DVDs
> with hard disk images on them to locations where these machines will be
> deployed, and if the system needs to be wiped, it can be easily done by
> loading the image onto the drive. Since every computer will have
> identical components, this should work pretty well.
>
> Sorry for the long read, I'll get to the point and give the criteria
> which I think are important:
>
> 1) Software usability/maintainability/availability
> 2) Non-bulky hardware which will allow the machine to be transported
> 3) Some form of AC power
> 4) A network adapter for a network/internet connection
> 5) Ability to restore the machine to its original state
>
> As far as my personal preferences go, I'd prefer working with the OS and
> selecting software packages, but hardware would be good too.
>
> Everyone should feel free to make comments about anything and everything.
>
> Tim
>
> On Thu, 2007-02-01 at 17:17 -0600, John Howland wrote:
>
>> On Thu, 1 Feb 2007, Joey wrote:
>>
>>
>>> Ill start with the question. Are we looking for a portable system?
>>> Clearly there are pros and cons to a portable machine.
>>>
>> All of the choices/criteria are yours to determine. Portability adds
>> (probably) to overall cost and complexity. However, portability could
>> be defined to be easily movable, but not operable when not connected to
>> some sort of power grid. For example, suppose the target user was a
>> school setting where, for security reasons, the machines had to be
>> moved to a secure locker, but when they were in use they could be connected
>> to a power source.
>>
>>
>>> Things our system should be capable of:
>>>
>>> 1. Connecting to a network for weather information, email, web browsing
>>> and so on.
>>> 2. Word processing
>>>
>> Spreadsheet?
>>
>>
>>> 3. Multi-user capability, with extremely limited access to normal user
>>> accounts (the less access the average user has, the less maintenance the
>>> system is likely to need).
>>> 4. Very basic and easy interface... much of what is available in open
>>> source operating systems will be completely useless to the average user
>>> of these systems.
>>>
>> Gnome seems to be most linux distro's choice, but there are lots of lighter
>> weight gui's. See Ubuntu for example.
>>
>>
>>> 5. Update capability, likely over a local connection, possibly to a
>>> central, more powerful machine.
>>> 6. Some sort of method to completely reset the system to its original
>>> configuration, in case of extreme malfunction. Obviously the easier the
>>> better
>>> 7. Install that can be easily changed for locality. Language, special
>>> applications and so on.
>>>
>>> I don't have much to say about hardware, it might be best to figure out
>>> what we want to be able to do and then build our system around that. It
>>>
>> User requirements! Radical! UML might even be useful here to get a handle
>> users.
>>
>>
>>> would be a shame to build a system, only to realize later it is
>>> completely useless for our goals.
>>>
>>> Doesn't matter to me what I end up doing, Im more than willing to take
>>> any job nobody else wants to do, although there are enough interesting
>>> topics that I don't see that being a huge problem...
>>>
>>> I hope to see more of these by tomorrow! See you all in Software
>>> Engineering HAHAHA (Im sure we will have loads of fun :))
>>>
>>> Joey
>>>
>>>
>>>
>>> _______________________________________________
>>> CSPED mailing list
>>> CSPED at mail.cs.trinity.edu
>>> http://www.cs.trinity.edu/mailman/listinfo/csped
>>>
>>>
>> _______________________________________________________________
>> John E. Howland url: http://www.cs.trinity.edu/~jhowland/
>> Computer Science email: jhowland at ariel.cs.trinity.edu
>> Trinity University voice: (210) 999-7364
>> One Trinity Place fax: (210) 999-7477
>> San Antonio, Texas 78212-7200
>> _______________________________________________
>> CSPED mailing list
>> CSPED at mail.cs.trinity.edu
>> http://www.cs.trinity.edu/mailman/listinfo/csped
>>
>
>
> _______________________________________________
> CSPED mailing list
> CSPED at mail.cs.trinity.edu
> http://www.cs.trinity.edu/mailman/listinfo/csped
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://Sol.CS.Trinity.Edu/pipermail/csped/attachments/20070202/396edc13/attachment-0001.html
More information about the CSPED
mailing list