[Csped] Power2People Goals

Joel Fessler joel.fessler at Trinity.edu
Fri Feb 2 22:29:34 CST 2007


The previous suggestions of the highly configurable Linux distro and the 
small form factor without built in display both seem like good ideas. We 
also need to work figuring out what all we want the user to be able to 
do with this system. I see the major things as being word processing, 
web browser, email, spreadsheet, and possibly basic drawing and 
calculator. I can work on hardware, applications or OS. I would prefer 
to work on Os or applications.

Zain Shamsi wrote:
> Yeah, any Linux distribution which provides a highly configurable 
> installation would work well - like Gentoo. There are also other small 
> Linux distros which we might want to take a look at...like some of 
> these mentioned here
> http://en.wikipedia.org/wiki/MiniLinux
> They usually come with a bunch of simple applications like a word 
> processor / spreadsheet program / browser etc. and are meant to run on 
> systems with very low resources
>
> As for the portability issue - we might want to consider that if we 
> end up building a prototype, it would be a significantly different 
> experience - in terms of price and complexity to build a portable 
> system as compared with one that isnt. I like Tim's idea on this - as 
> it doesnt have to have built in display capability. Possibly a 
> MicroATX form factor which can still allow standardized 
> components..but of course the prices would have to be looked into.
>
> I am pretty comfortable with the hardware as I've built a few systems 
> before, so I would rather work on the software portion - OS / 
> Applications
>
> - Zain
>
>
>
> Glenn Kavanagh wrote:
>> 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
>>      
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> 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




More information about the CSPED mailing list