<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
>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.<br>
<br>
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.<br>
<br>
So for the teams, I was thinking something along these lines:<br>
<br>
1. Hardware<br>
2. OS<br>
3. Applications<br>
4. Network Infrastructure (this could include the main server and
distributing updates)<br>
<br>
Preference: working on the OS portion.<br>
<br>
Glenn<br>
<br>
Tim Nunamaker wrote:
<blockquote>
<pre wrap>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:
<a class="moz-txt-link-freetext" href="http://www.xubuntu.org/">http://www.xubuntu.org/</a>
>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:
</pre>
<blockquote>
<pre wrap>On Thu, 1 Feb 2007, Joey wrote:
</pre>
<blockquote>
<pre wrap>Ill start with the question. Are we looking for a portable system?
Clearly there are pros and cons to a portable machine.
</pre>
</blockquote>
<pre wrap>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.
</pre>
<blockquote>
<pre wrap>Things our system should be capable of:
1. Connecting to a network for weather information, email, web browsing
and so on.
2. Word processing
</pre>
</blockquote>
<pre wrap>Spreadsheet?
</pre>
<blockquote>
<pre wrap>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.
</pre>
</blockquote>
<pre wrap>Gnome seems to be most linux distro's choice, but there are lots of lighter
weight gui's. See Ubuntu for example.
</pre>
<blockquote>
<pre wrap>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
</pre>
</blockquote>
<pre wrap>User requirements! Radical! UML might even be useful here to get a handle
users.
</pre>
<blockquote>
<pre wrap>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
<a class="moz-txt-link-abbreviated" href="mailto:CSPED@mail.cs.trinity.edu">CSPED@mail.cs.trinity.edu</a>
<a class="moz-txt-link-freetext" href="http://www.cs.trinity.edu/mailman/listinfo/csped">http://www.cs.trinity.edu/mailman/listinfo/csped</a>
</pre>
</blockquote>
<pre wrap>_______________________________________________________________
John E. Howland url: <a class="moz-txt-link-freetext" href="http://www.cs.trinity.edu/~jhowland/">http://www.cs.trinity.edu/~jhowland/</a>
Computer Science email: <a class="moz-txt-link-abbreviated" href="mailto:jhowland@ariel.cs.trinity.edu">jhowland@ariel.cs.trinity.edu</a>
Trinity University voice: (210) 999-7364
One Trinity Place fax: (210) 999-7477
San Antonio, Texas 78212-7200
_______________________________________________
CSPED mailing list
<a class="moz-txt-link-abbreviated" href="mailto:CSPED@mail.cs.trinity.edu">CSPED@mail.cs.trinity.edu</a>
<a class="moz-txt-link-freetext" href="http://www.cs.trinity.edu/mailman/listinfo/csped">http://www.cs.trinity.edu/mailman/listinfo/csped</a>
</pre>
</blockquote>
<pre wrap><!---->
_______________________________________________
CSPED mailing list
<a class="moz-txt-link-abbreviated" href="mailto:CSPED@mail.cs.trinity.edu">CSPED@mail.cs.trinity.edu</a>
<a class="moz-txt-link-freetext" href="http://www.cs.trinity.edu/mailman/listinfo/csped">http://www.cs.trinity.edu/mailman/listinfo/csped</a>
</pre>
</blockquote>
</body>
</html>