Online Image builder

Online Image Builder

Objective: To provide the ability for the Gentoo users to have installable images built by a web server that would contact them when it was ready to be downloaded.

Abstract:  Using example front ends create a way to deliver a generic Gentoo system without having to have a user there to do the installation.  The delivery would then be provided in several formats (zip, tar.bz, bootable iso).  The user would be expected to install their own kernel, a genkernel will be shipped with the installation image but will not be suitable for every user so they *should* go and recompile it with their own options.

Deliverable's:

• A website (in PHP or Python) with the ability to take orders from users, que them, and notify users when their build is ready to be downloaded. 
• User documentation in an easy to understand format.
• A modular design so new things can be put into place with ease.
• A generic base system for x86 and amd64 (server and desktop of each).
  

Timeline:
May 10th - 24th:

• Get a standard set of use flags that will be applied to every package (will be different for each system).
• Get a standard set of packages that will be installed on each system.
• Decide on standard CFLAGS to be used, most likly CFLAGS="-O2 -march=i686 -pipe"
  
• Begin work on Python script to do the install.
• Decide what platform will do the building.
  

May 24th - June 8th:

• Have Python script done and work on debugging it.
• Have the finalized set of packages that will be available to be installed though the online tool.
• Begin work on the que system.
• Begin front end mock up/decide what mock up to use.

June 8th - June 22nd:

• Do a build via the online (protected) front end and debug w/ que utility.
• Decide what to include with each delivery.
• Prepare a bootable iso template.
• Have everything that is build saved in a binary form (to save time for each build).

June 22nd - 29th:

• Flex time for unanticipated problems.

June 29th - July 20th:

• Have multiple people build systems concurrently(while website still protected).  Test system tax's.
• Work out any bugs on the delivery system's.
• Find and fix system bottlenecks.

July 20th - August 10th:

• Have the site open to the gentoo population with a request for error's that happen on build.
• Fix error's.
• Generate a time from request to delivery time sample.
• Be able to predict (withing an hour or two) when a user's build will be ready.
• Find and fix system bottlenecks.

August 10th - Onward:

• Improve delivery system.
• Find and fix system bottlenecks.
• Fix error's.
• Make build system portable (so it can be taken to different location ie. university, and have builds done by there servers with even more customizability).
  

About me:
My name is
Ethan Hall, I am currently a sophomore in the college of Computer and
Electrical Engineering at Purdue University. I am 20 years old My parents are currently located in VA, my mom has
just started an alpaca farm, we will see how well that goes. In my
free time I like to swing dance, mostly. I am currently the designer
for Night Train swing dance club. I love it, it gives me
a way to relax, and mingle with people after a hard day of engineering
homework. One of my goals every semester is to try to bring my friends
into the swing club so they can experience it too. Lets face it, there
is a reason that the stereotypical engineer is a nerd who plays video
games all the time. I also like to ride motorcycles but as of yet to
own one, this is one of my summer goals. I am in a call at Purdue
called EPICS and it has been a great way for me to get my feet wet with
actual applications of of products. My team works for a museum called
Imagination Station, and I personal am a co-team leader. The project I
work on is called the LASER maze, it teaches kids about LASER's
reflection and reflection. It has shown me some really cool things and
make me realize why there are "warranty void if opened" stickers on
everything. When one thing starts to work anther stops working. AHH
agrivating.

Googles Summer of Code Idea

Objective:
The objective of the project would be to make faster searches with paludis/protage by implementing a database of information and no longer requiring a tree sync to download everything from the tree at that time.

Abstract:
When Gentoo uses portage it uses 600M of disk space. This is extremly large and is slow to search. At 600M a machiene that is embedded each meg that is used will increase the cost of the device and right now solid state hard drives are expensive, so every meg that Gentoo makes the system cost more to devlop. The cache sync project would be my choice of projects to be on. I would want to first create a program that would call paludis (my current package manager, and portage should be an easy change). The program would keep a database of all packages, only the packages and versions currently in the portage tree and the overlay's. The program would do the dependency searching internally (this would me changed once the proof of concept was complete to be done by the package manager). The code that would do the dependency search would be then transfered into the respecitve program. The next step would be to download all the files needed by the build. This would include Manifest's, ebuilds, source, and all other files.

An idea I had would be to model the RPM system and have everything (including source) be included in a file, most likly a .tar.bz or another compressed file type. The source code would be uncomressed and put into a folder called "source".

The program would then take the data and place the ebuild's and other needed data in the /usr/portage directory. Here is where a discision must be made. I believe the source should be kept in /usr/portage/distfile to keep the the package management software consistant but it would be able to be changed if need be. After the PM's have run and installed the applications, the source would stay on the machine and so would the ebuilds. But once a new version is installed the old version would be purged from the file system to keep it as light as possible. I would do this because it keeps the size on a file system smaller and allows people to rebuild packages without having to re-downlaod source files.

Deliverables:
Complete source code, documentation, examples of use, patches made to other applications, files that would be used to transfer data, example database structure with explinations.

Timeline:
In the first two weeks I would have the structure of the way the database would be set up. I would then have to download the tree and write a batch file to purge the needless data from the files and add it to the database. I would then have to modify a dependency checker used by paludis to use my database structure. That should take about a month.
The next step would be to create the way the files that would hold ebuilds, patchs, source, etc. This should take about a week.
The next 2 weeks I would have to pick applications that I would want to test the system with, most likley building the files as I need them via another batch file.
The week would be to put the actual build section into the program, at first it would use another program to do the actual installation, but after bugs are worked out it would be merged into an existing program.
About a month of time to fix bugs and prepair the code to be implemented into a PM.


Bio:
My name is Ethan Hall, I am currenly a sophmore in the college of Computer and Electical Engineering at Purdue University. I am 20 years old, and was born in Akron, OH. My parents are currently located in VA, my mom has just started an alpacka farm, we will see how well that goes. In my free time I like to swing dance, mostly. I am currently the designer for Night Train swing dance club and have asperations for running for president. I love it, it gives me a way to relax, and mingle with people after a hard day of engineering homework. One of my goals every semester is to try to bring my friends into the swing club so they can experience it too. Lets face it, there is a reason that the sterotipical enigneer is a nerd who plays video games all the time. I also like to ride motorcycles but as of yet to own one, this is one of my summer goals. I am in a call at Purdue called EPICS and it has been a great way for me to get my feet wet with actual applications of of products. My team works for a meusiem called Imagination Station, and I personal am a co-team leader. The project I work on is called teh LASER maze, it teaches kids about LASER's reflaction and reflection. It has shown me some really cool things and make me relize why there are "warrently void if opened" stickers on everything. When one thing starts to work anther stops working. AHH agrivating.

Ethan Hall
ekhall@purdue.edu
ethankhall@purdue.edu

Annoy-a-tron! DIY

Okay people here is the first project that I am going to put up, its called Annoy-a-tron. Here is where I got the idea from ThinkGeek.com. So some specs for it:

• Buzz are a very loud and anoying sound for ~1 second.
• The time between "buzzes" change.
• Run on <>
• Easy to hide
• Be michevous!

Parts List:

• Buzzer @ 3.2Khz
• Counter Shift Registers - Mouser no longer stockes these.
• 556 Timer
• 8 input Nand Gate
  
• PLD - you should find this yourself.
  

So first thing that I did was hit up google looking for a '555' timer. Basicly its something that you can use to make clocking pulses that rely on an RC network. This RC network will let us change the timing... Here is a tutorial that will calculate the values. If the web program says Infinity and NaN. Just put '10' in the capasitor values. So putting in .001KHz (1 hertz) and a 50% duty cycle. The duty cycle means that the output from the 555 timer will be a logic '1' for .5 seconds and a logic '0' for .5 seconds.

The values that the wesite will give you are:

• 0.00K Ohm - R1
• 72.0K Ohm - R2
• 10uF - C1

If you do not have this values just re arange the C1 by facotor of 10 to increase/decrease the resistors. Here is how the timer will eventually be set up.

The next thing that happens is we need to look at a 14 bit ripple counter. I used the "MC14040BCP". The basics of this chip are power on 16, ground on 8. From pin 3 on the 555 timer, run the input to 10. For right now thats all we need to go.

Okay so since I have already done it and ran into a problem. The pizo electric speeker requires a clock. Well we are screwed at the moment, because out clock is being used for the ripple counter. So we need another one. Well, this is an easy fix thanks to the great people that make IC's. They have something called a 556 timer. This is a 555 timer with 2 timers that work independently of each other.

After doing some research (and some help with a few friends) I found that a pizo electic speeker is increadibly loud at 3Khz. And the pizo buzzer that I found is very good (and speched at 3.2Khz). Here is the scematic for the 556 timer. So we will have to use this from now on.

Okay the next thing we need to do is get an 8input NAND gate. The output from the NAND gate will be connected to the 3KHz reset pin. Okay so I am going to just put out the scmatic here and you should be able to put it all together. If you have any guestions feel free to email me, ethankhall (at) gmail (dot) com. Sorry just want to keep the spam down.



From here I will go and talk about how I am going to make it better with GAL device, this requires a Dataman. This is an expensive piece of equipment ( I dont know why though).



Special Thanks:
Patrick Wright, Matt Barton

Who am I?

Well my name is Ethan. I go to Purdue, and I am a sophmore in Computer Engineering. I have project idea's all the time, and here is where I am going to put stuff up. I will also put up some things that I do with Gentoo when I have problems and fixes for it.