https://wiki.cs.earlham.edu/api.php?action=feedcontributions&user=Hunteke&feedformat=atom Earlham CS Department - User contributions [en] 2024-03-28T08:11:17Z User contributions MediaWiki 1.32.1 https://wiki.cs.earlham.edu/index.php?title=Earlham_CS_Department:Deletion_log&diff=4548 Earlham CS Department:Deletion log 2007-08-03T23:29:28Z <p>Hunteke: deleted &quot;Cluster:Simultaneous Edit&quot;: empty page</p> <hr /> <div>Below is a list of the most recent deletions.<br /> All times shown are server time (UTC).<br /> &lt;ul&gt;&lt;li&gt;23:29, 3 Aug 2007 [[User:Hunteke|Hunteke]] deleted &quot;Cluster:Simultaneous Edit&quot; &lt;em&gt;(empty page)&lt;/em&gt;&lt;/li&gt;<br /> &lt;li&gt;23:27, 3 Aug 2007 [[User:Hunteke|Hunteke]] deleted &quot;JerryKevin's new page&quot; &lt;em&gt;(just a test to explain how to use a wiki)&lt;/em&gt;&lt;/li&gt;<br /> &lt;li&gt;23:25, 3 Aug 2007 [[User:Hunteke|Hunteke]] deleted &quot;Caktus&quot; &lt;em&gt;(moved to http&amp;#58;//wiki.cakt.us/w/Admin, so no need to continue to clutter this wiki)&lt;/em&gt;&lt;/li&gt;<br /> &lt;li&gt;15:48, 29 May 2007 [[User:Admin|Admin]] deleted &quot;Image:Network-layout.png&quot;&lt;/li&gt;<br /> &lt;li&gt;15:45, 29 May 2007 [[User:Admin|Admin]] deleted &quot;Image:Network-layout.png&quot; &lt;em&gt;(bad form on page)&lt;/em&gt;&lt;/li&gt;<br /> <br /> &lt;/ul&gt;<br /> </div> Hunteke https://wiki.cs.earlham.edu/index.php?title=Main_Page&diff=3467 Main Page 2007-08-01T23:57:13Z <p>Hunteke: </p> <hr /> <div>=== Computer Science Department ===<br /> * [[Users|ACL User Information]]<br /> * [[Cluster Information|Cluster Computing Group]]<br /> ** [[ccg-chemistry-faq|Computational Chemistry FAQ]]<br /> * [[Content Group|Content Group]]<br /> * [[Green Science|Green Science]]<br /> * [[HIP|Hardware Interfacing Project (HIP)]]<br /> * [[Sysadmin|Sysadmin Information]]<br /> * [[Printers|Printer Information]]<br /> * [[Applied Groups Committee|Applied Groups Committee]]<br /> <br /> === Science Division ===<br /> * [[Science-Friday]] (HHMI proposal, Keck proposal, meeting minutes, etc.)<br /> * Link to the Natural Science Division page at www.earlham.edu<br /> * Link to the H2O Keck Project page <br /> <br /> === Classes ===<br /> * [[enpr-256|ENPR 256 - Sustainable Systems, Energy]]<br /> * Software Engineering 2006<br /> ** [[SE2006:group bar|group bar]] - group project team<br /> ** [[http://www.cs.earlham.edu/~fu/mediawiki/index.php/Main_Page group fu]] - group project team<br /> * [[Operating Systems 2005]]<br /> * [[Senior Seminar 2005|CS Senior Seminar 2005]]<br /> <br /> === Research Projects ===<br /> * [[Cope Environmental Center]]<br /> * [[Earlham Energy Awarness Project|Earlham Energy Awarness Project (EEAP)]]<br /> <br /> === Earlham Committees ===<br /> * [[ERC|Environmental Responsibility Committee]]</div> Hunteke https://wiki.cs.earlham.edu/index.php?title=Main_Page&diff=3420 Main Page 2007-08-01T23:52:27Z <p>Hunteke: </p> <hr /> <div>=== Computer Science Department ===<br /> * [[Users|ACL User Information]]<br /> * [[Cluster Information|Cluster Computing Group]]<br /> ** [[ccg-chemistry-faq|Computational Chemistry FAQ]]<br /> * [[Content Group|Content Group]]<br /> * [[Green Science|Green Science]]<br /> * [[HIP|Hardware Interfacing Project (HIP)]]<br /> * [[Sysadmin|Sysadmin Information]]<br /> * [[Printers|Printer Information]]<br /> * [[Applied Groups Committee|Applied Groups Committee]]<br /> <br /> === Science Division ===<br /> * [[Science-Friday]] (HHMI proposal, Keck proposal, meeting minutes, etc.)<br /> * Link to the Natural Science Division page at www.earlham.edu<br /> * Link to the H2O Keck Project page <br /> <br /> === Classes ===<br /> * [[enpr-256|ENPR 256 - Sustainable Systems, Energy]]<br /> * Software Engineering 2006<br /> ** [[SE2006:group bar|group bar]] - group project team<br /> ** [[http://www.cs.earlham.edu/~fu/mediawiki/index.php/Main_Page group fu]] - group project team<br /> * [[Operating Systems 2005]]<br /> * [[Senior Seminar 2005|CS Senior Seminar 2005]]<br /> <br /> === Research Projects ===<br /> * [[Cope Environmental Center]]<br /> * [[Earlham Energy Awarness Project|Earlham Energy Awarness Project (EEAP)]]<br /> <br /> === Earlham Committees ===<br /> * [[ERC|Environmental Responsibility Committee]]<br /> <br /> === Test Area for Kevin at Workshop ===<br /> * [[JerryKevin's new page|Kevin's test page wheee!]]</div> Hunteke https://wiki.cs.earlham.edu/index.php?title=Wiki_Manual&diff=5831 Wiki Manual 2007-07-27T22:12:55Z <p>Hunteke: the current collaboration (wiki) scene</p> <hr /> <div>=Current Topography=<br /> <br /> * '''Physically meet'''<br /> ** Two or more people can have a meeting. Just have everyone who needs to be in on &quot;it&quot; show up at the meeting.<br /> * '''Letters'''<br /> ** Allows (roughly) two people to communicate. Just need to pay a lot for stamps, wait a couple of days for the letters to travel.<br /> * '''Email'''<br /> ** Akin to letters, but a heck of a lot faster and cheaper. It's also easier to keep multiple people in the loop. (What's the latest thread?)<br /> * '''Telephone'''<br /> ** Allows two to communicate over long distances. Teleconference phone calls allow more than two people to communicate. Expensive. People still have to actually (virtually) ''be at the meeting''.<br /> * '''Wiki'''<br /> ** Allow anyone in a given group to edit pages on the wiki. When I'm asleep, Alexa in Taiwan can put something up, and then I can read it later. Cheap, instant. &quot;Always up to date.&quot; Separates discussion from &quot;solved&quot;.<br /> * '''What's missing?'''<br /> ** There is at least one item missing from this list. What is it?<br /> <br /> I'll motivate wikis in a minute, but first let's see [[Cluster:Wiki:HowTo|''how'']] to do them.</div> Hunteke https://wiki.cs.earlham.edu/index.php?title=Cluster_Information&diff=5299 Cluster Information 2007-07-27T21:22:16Z <p>Hunteke: /* Curriculum Modules */</p> <hr /> <div>== To Do ==<br /> BCCD Liberation<br /> * v1.1 release - upgrade procedures<br /> <br /> Curriculum Modules <br /> * POVRay<br /> * GROMACS<br /> * Energy and Weather <br /> * Dave's math modules<br /> * Standard format, templates, how-to for V and V<br /> <br /> LittleFe<br /> * Explore machines from first Intel donation ([[intel-lf-server|notes and pictures]])<br /> * Build 4 SCED units<br /> <br /> Infrastructure<br /> * Masa's GROMACS interface on Cairo<br /> * gridgate configuration, Open Science Grid peering<br /> * [[hopperprime|hopper']]<br /> <br /> SC Education <br /> * Scott's homework (see [[sc-education-homework-1|the message]])<br /> <br /> == Current Projects ==<br /> * [[BCCD]]<br /> * [[LittleFe Cluster|LittleFe]]<br /> * [[Folding@Clusters|Folding@Clusters]]<br /> * [[OpenMPI|Benchmarking OpenMPI]]<br /> <br /> == Past Projects ==<br /> * [[Cluster:Big-Fe|Big-FE]]<br /> * [[Cluster:LowLatency|Low Latency Linux Kernel]]<br /> <br /> == General Stuff == <br /> * [[Cluster:Todo|Todo]]<br /> * [[General Cluster Information|General]]<br /> * [[Cluster:Hopper|Hopper]]<br /> * [[Cluster Howto's|Howto's]]<br /> * [[Cluster:Networking|Networking]]<br /> * [[Cluster:2005-11-30 Meeting|2005-11-30 Meeting]]<br /> * [[Cluster:2006-12-12 Meeting|2006-12-12 Meeting]]<br /> * [[Cluster:2006-02-02 Meeting|2006-02-02 Meeting]]<br /> * [[Cluster:2006-03-16 Meeting|2006-03-16 Meeting]]<br /> * [[Cluster:2006-04-06 Meeting|2006-04-06 Meeting]]<br /> * [[Cluster:Node usage|Node usage]]<br /> * [[Cluster:Netgear numbers|Numbers for Netgear switches]]<br /> * [[Cluster:Latex poster creation|Latex Poster Creation]]<br /> * [[Cluster:Bugzilla|Bugzilla Etiquette]]<br /> <br /> == Items Particular to a Specific Cluster ==<br /> * [[ACL Cluster|ACL]]<br /> * [[Athena Cluster|Athena]]<br /> * [[Bazaar Cluster|Bazaar]]<br /> * [[Cairo Cluster|Cairo]]<br /> * [[Bobsced Cluster|Bobsced]]<br /> <br /> == Curriculum Modules ==<br /> * [[Cluster:Curriculum|Curriculum]]<br /> * [[Cluster:Fluid Dynamics|Fluid Dynamics]]<br /> * [[Cluster:Population Ecology|Population Ecology]]<br /> * [[Cluster:GROMACS Web Interface|GROMACS Web Interface]]<br /> * [[Cluster:Wiki|Wiki Life for Academics]]<br /> <br /> == Possible Future Projects ==<br /> * [[Cluster:Realtime Parallel Visualization|Realtime Parallel Visualization]]<br /> <br /> == Archive ==<br /> * TeraGrid '06 (Indianapolis, June 12-15, 2006)<br /> ** [http://www.teragrid.org Conference webpage]<br /> ** [http://www.teragrid.org/events/2006conference/contest_poster.html Student poster guidelines]<br /> ** [[Big-FE-teragrid-abstract|Big-FE abstract]]<br /> <br /> * SIAM Parallel Processing 2006 (San Fransisco, February 22-24, 2006)<br /> ** [http://www.siam.org/meetings/pp06 Conference webpage] <br /> ** [[Cluster:little-fe-siam-pp06-abstract|Little-Fe abstract]]<br /> ** [[Cluster:llk-siam-pp06-abstract|Low Latency Kernal abstract]]<br /> ** Folding@Clusters<br /> ** Best practices for teaching parallel programming to science faculty (Charlie only)</div> Hunteke https://wiki.cs.earlham.edu/index.php?title=Hopperprime&diff=3076 Hopperprime 2007-04-06T17:13:03Z <p>Hunteke: Nothing's installed thanks to Raid mishap</p> <hr /> <div>= hopper' TODO =<br /> <br /> located at &lt;tt&gt;hopperprime.cluster.earlham.edu&lt;/tt&gt;<br /> <br /> As of 25 Mar 2007, this has all been reset due to some raid issue. We need to reinstall all this stuff. Please mark appropriately with rubric so we know what's where.<br /> <br /> Rubric items ( not installed | partially installed | installed | completed )<br /> <br /> * (not installed) Bash (3.1.17)<br /> * (not installed) Apache2 (2.2.3)<br /> ** (not installed) PHP (5.2.0 CLI)<br /> *** (not installed) session<br /> *** (not installed) CGI -&gt; necessary?<br /> * (not installed) Nagios<br /> * (not installed) Ganglia<br /> * (not installed) MRTG<br /> * (not installed) NIS<br /> * (not installed) DHCPD<br /> ** not setup<br /> * (completed) sudo<br /> ** but with something like this, it would be awesome to have someone more knowledgeable make sure that I haven't missed anything<br /> <br /> This is all that is currently on the board. If you've anything else for the list, please add it so we know what's on hopper'</div> Hunteke https://wiki.cs.earlham.edu/index.php?title=Cluster_Information&diff=3229 Cluster Information 2007-03-13T23:07:25Z <p>Hunteke: benchmarking openmpi</p> <hr /> <div>== To Do ==<br /> BCCD Liberation<br /> * v1.1 release - upgrade procedures<br /> <br /> Curriculum Modules <br /> * POVRay<br /> * GROMACS<br /> * Energy and Weather <br /> * Dave's math modules<br /> * Standard format, templates, how-to for V and V<br /> <br /> LittleFe<br /> * Explore machines from first Intel donation ([[intel-lf-server|notes and pictures]])<br /> * Build 4 SCED units<br /> <br /> Infrastructure<br /> * Masa's GROMACS interface on Cairo<br /> * gridgate configuration, Open Science Grid peering<br /> * [[hopperprime|hopper']]<br /> <br /> SC Education <br /> * Scott's homework (see [[sc-education-homework-1|the message]])<br /> <br /> == Current Projects ==<br /> * [[BCCD]]<br /> * [[LittleFe Cluster|LittleFe]]<br /> * [[Folding@Clusters|Folding@Clusters]]<br /> * [[OpenMPI|Benchmarking OpenMPI]]<br /> <br /> == Past Projects ==<br /> * [[Cluster:Big-Fe|Big-FE]]<br /> * [[Cluster:LowLatency|Low Latency Linux Kernel]]<br /> <br /> == General Stuff == <br /> * [[Cluster:Todo|Todo]]<br /> * [[General Cluster Information|General]]<br /> * [[Cluster:Hopper|Hopper]]<br /> * [[Cluster Howto's|Howto's]]<br /> * [[Cluster:Networking|Networking]]<br /> * [[Cluster:2005-11-30 Meeting|2005-11-30 Meeting]]<br /> * [[Cluster:2006-12-12 Meeting|2006-12-12 Meeting]]<br /> * [[Cluster:2006-02-02 Meeting|2006-02-02 Meeting]]<br /> * [[Cluster:2006-03-16 Meeting|2006-03-16 Meeting]]<br /> * [[Cluster:2006-04-06 Meeting|2006-04-06 Meeting]]<br /> * [[Cluster:Node usage|Node usage]]<br /> * [[Cluster:Netgear numbers|Numbers for Netgear switches]]<br /> * [[Cluster:Latex poster creation|Latex Poster Creation]]<br /> * [[Cluster:Bugzilla|Bugzilla Etiquette]]<br /> <br /> == Items Particular to a Specific Cluster ==<br /> * [[ACL Cluster|ACL]]<br /> * [[Athena Cluster|Athena]]<br /> * [[Bazaar Cluster|Bazaar]]<br /> * [[Cairo Cluster|Cairo]]<br /> <br /> == Curriculum Modules ==<br /> * [[Cluster:Curriculum|Curriculum]]<br /> * [[Cluster:Fluid Dynamics|Fluid Dynamics]]<br /> * [[Cluster:Population Ecology|Population Ecology]]<br /> * [[Cluster:GROMACS Web Interface|GROMACS Web Interface]]<br /> <br /> == Possible Future Projects ==<br /> * [[Cluster:Realtime Parallel Visualization|Realtime Parallel Visualization]]<br /> <br /> == Archive ==<br /> * TeraGrid '06 (Indianapolis, June 12-15, 2006)<br /> ** [http://www.teragrid.org Conference webpage]<br /> ** [http://www.teragrid.org/events/2006conference/contest_poster.html Student poster guidelines]<br /> ** [[Big-FE-teragrid-abstract|Big-FE abstract]]<br /> <br /> * SIAM Parallel Processing 2006 (San Fransisco, February 22-24, 2006)<br /> ** [http://www.siam.org/meetings/pp06 Conference webpage] <br /> ** [[Cluster:little-fe-siam-pp06-abstract|Little-Fe abstract]]<br /> ** [[Cluster:llk-siam-pp06-abstract|Low Latency Kernal abstract]]<br /> ** Folding@Clusters<br /> ** Best practices for teaching parallel programming to science faculty (Charlie only)</div> Hunteke https://wiki.cs.earlham.edu/index.php?title=Hopperprime&diff=3039 Hopperprime 2007-03-05T01:45:41Z <p>Hunteke: a few more hopper' services for the list</p> <hr /> <div>= hopper' TODO =<br /> <br /> located at &lt;tt&gt;hopperprime.cluster.earlham.edu&lt;/tt&gt;<br /> <br /> Rubric items ( not installed | partially installed | installed | completed )<br /> <br /> * (installed) Bash (3.1.17)<br /> * (installed) Apache2 (2.2.3)<br /> ** Basically completed, but perhaps a periphery check by someone more knowledgeable would be good.<br /> ** (partially installed) PHP (5.2.0 CLI)<br /> *** not tested<br /> *** (installed) session<br /> *** (not installed) CGI -&gt; necessary?<br /> * (partially installed) Nagios<br /> ** Not setup, not running<br /> * (partially installed) Ganglia<br /> ** only &lt;tt&gt;make install&lt;/tt&gt;<br /> * (not installed) MRTG<br /> * (not installed) NIS<br /> * (partially installed) DHCPD<br /> ** not setup<br /> * (completed) sudo<br /> ** but with something like this, it would be awesome to have someone more knowledgeable make sure that I haven't missed anything<br /> <br /> This is all that is currently on the board. If you've anything else for the list, please add it so we know what's on hopper'</div> Hunteke https://wiki.cs.earlham.edu/index.php?title=Hopperprime&diff=2903 Hopperprime 2007-03-04T03:51:59Z <p>Hunteke: initial hopper' todo</p> <hr /> <div>= hopper' TODO =<br /> <br /> * (installed) Apache2<br /> ** Basically completed, but perhaps a periphery check by someone more knowledgeable would be good.<br /> ** (partially installed) PHP<br /> *** not tested<br /> *** (installed) CLI<br /> * (installed) Nagios<br /> ** Not setup, not running<br /> * (not installed) Ganglia<br /> * (not installed) MRTG</div> Hunteke https://wiki.cs.earlham.edu/index.php?title=Cluster_Information&diff=2954 Cluster Information 2007-03-04T03:42:36Z <p>Hunteke: /* To Do */</p> <hr /> <div>== To Do ==<br /> BCCD Liberation<br /> * v1.1 release - upgrade procedures<br /> <br /> Curriculum Modules <br /> * POVRay<br /> * GROMACS<br /> * Energy and Weather <br /> * Dave's math modules<br /> * Standard format, templates, how-to for V and V<br /> <br /> LittleFe<br /> * Explore machines from first Intel donation ([[intel-lf-server|notes and pictures]])<br /> * Build 4 SCED units<br /> <br /> Infrastructure<br /> * Masa's GROMACS interface on Cairo<br /> * gridgate configuration, Open Science Grid peering<br /> * [[hopperprime|hopper']]<br /> <br /> SC Education <br /> * Scott's homework (see [[sc-education-homework-1|the message]])<br /> <br /> == Current Projects ==<br /> * [[BCCD]]<br /> * [[LittleFe Cluster|LittleFe]]<br /> * [[Cluster:Big-Fe|Big-FE]]<br /> * [[Folding@Clusters|Folding@Clusters]]<br /> * [[Cluster:LowLatency|Low Latency Linux Kernel]]<br /> <br /> == General Stuff == <br /> * [[Cluster:Todo|Todo]]<br /> * [[General Cluster Information|General]]<br /> * [[Cluster:Hopper|Hopper]]<br /> * [[Cluster Howto's|Howto's]]<br /> * [[Cluster:Networking|Networking]]<br /> * [[Cluster:2005-11-30 Meeting|2005-11-30 Meeting]]<br /> * [[Cluster:2006-12-12 Meeting|2006-12-12 Meeting]]<br /> * [[Cluster:2006-02-02 Meeting|2006-02-02 Meeting]]<br /> * [[Cluster:2006-03-16 Meeting|2006-03-16 Meeting]]<br /> * [[Cluster:2006-04-06 Meeting|2006-04-06 Meeting]]<br /> * [[Cluster:Node usage|Node usage]]<br /> * [[Cluster:Netgear numbers|Numbers for Netgear switches]]<br /> * [[Cluster:Latex poster creation|Latex Poster Creation]]<br /> * [[Cluster:Bugzilla|Bugzilla Etiquette]]<br /> <br /> == Items Particular to a Specific Cluster ==<br /> * [[ACL Cluster|ACL]]<br /> * [[Athena Cluster|Athena]]<br /> * [[Bazaar Cluster|Bazaar]]<br /> * [[Cairo Cluster|Cairo]]<br /> <br /> == Curriculum Modules ==<br /> * [[Cluster:Curriculum|Curriculum]]<br /> * [[Cluster:Fluid Dynamics|Fluid Dynamics]]<br /> * [[Cluster:Population Ecology|Population Ecology]]<br /> * [[Cluster:GROMACS Web Interface|GROMACS Web Interface]]<br /> <br /> == Possible Future Projects ==<br /> * [[Cluster:Realtime Parallel Visualization|Realtime Parallel Visualization]]<br /> <br /> == Archive ==<br /> * TeraGrid '06 (Indianapolis, June 12-15, 2006)<br /> ** [http://www.teragrid.org Conference webpage]<br /> ** [http://www.teragrid.org/events/2006conference/contest_poster.html Student poster guidelines]<br /> ** [[Big-FE-teragrid-abstract|Big-FE abstract]]<br /> <br /> * SIAM Parallel Processing 2006 (San Fransisco, February 22-24, 2006)<br /> ** [http://www.siam.org/meetings/pp06 Conference webpage] <br /> ** [[Cluster:little-fe-siam-pp06-abstract|Little-Fe abstract]]<br /> ** [[Cluster:llk-siam-pp06-abstract|Low Latency Kernal abstract]]<br /> ** Folding@Clusters<br /> ** Best practices for teaching parallel programming to science faculty (Charlie only)</div> Hunteke https://wiki.cs.earlham.edu/index.php?title=Google_SoC_Terms_of_Service&diff=5697 Google SoC Terms of Service 2007-02-12T20:32:15Z <p>Hunteke: /* Google Summer of Code -- Terms of Service */</p> <hr /> <div>== Google Summer of Code -- Terms of Service ==<br /> <br /> [http://code.google.com/soc/tos.html Complete Terms]. The highlights are below:<br /> <br /> Mentor Organizations:<br /> Mentor organizations are individuals, groups, organizations and/or businesses engaged in the development and distribution of free and/or open source software. By submitting an application to participate as a mentor organization in the Google Summer of Code 2006 program, the mentor organization agrees to provide the following:<br /> <br /> Need (very) soon:<br /> <br /> # A pool of project ideas for students to choose from, publicly published by the mentor organization<br /> # A person or persons available to take in student ideas should they not find something that appeals to them<br /> # A person or persons available to review the incoming student applications targeted to the organization and to decide which applications should be accepted, meaning development begins on the accepted student proposals<br /> # A person or persons to monitor the progress of the students and mentor them as the project proceeds (hereafter mentor(s))<br /> # A mentor or mentors ready to take over for the aforementioned mentor(s) in the event s/he is unable to continue providing guidance to the accepted student applicant (e.g. goes on vacation)<br /> <br /> Not so pressing:<br /> <br /> # A written evaluation of each student developer, including how they worked with the group, if they should be invited back should we do another Summer of Code, etc.<br /> # All necessary tax forms or other tax related documentation required to provide payment to the organization.</div> Hunteke https://wiki.cs.earlham.edu/index.php?title=Google_SoC_Terms_of_Service&diff=2872 Google SoC Terms of Service 2007-02-12T20:27:27Z <p>Hunteke: </p> <hr /> <div>== Google Summer of Code -- Terms of Service ==<br /> <br /> [http://code.google.com/soc/tos.html Complete Terms]. The highlights are below:</div> Hunteke https://wiki.cs.earlham.edu/index.php?title=Applied_Groups_Committee&diff=5696 Applied Groups Committee 2007-02-12T20:20:05Z <p>Hunteke: </p> <hr /> <div>== Applied Groups Committee ==<br /> <br /> This is a page where we can conglomerate our ideas and what gets passed around via email.<br /> <br /> <br /> === Google Summer of Code ===<br /> <br /> * [[Google SoC Terms of Service|Terms of Service]] - What we need to provide as a mentor organization. I'm still trying to find a deadline, but it may end up that we need to email them: [[mailto:soc2006support@google.com|SoC, 2006]] (Is there a 2007 address?)</div> Hunteke https://wiki.cs.earlham.edu/index.php?title=Main_Page&diff=2878 Main Page 2007-02-12T20:15:26Z <p>Hunteke: Added link for Applied Groups Committee collaboration page</p> <hr /> <div>=== Computer Science Department ===<br /> * [[Users|ACL User Information]]<br /> * [[Cluster Information|Cluster Computing Group]]<br /> * [[Content Group|Content Group]]<br /> * [[Green Science|Green Science]]<br /> * [[HIP|Hardware Interfacing Project (HIP)]]<br /> * [[Sysadmin|Sysadmin Information]]<br /> * [[Applied Groups Committee|Applied Groups Committee]]<br /> <br /> === Science Division ===<br /> * [[Science-Friday]] (meeting minutes, Keck proposal, etc.)<br /> <br /> === Classes ===<br /> * [[enpr-256|ENPR 256 - Sustainable Systems, Energy]]<br /> * [[Senior Seminar 2005|CS Senior Seminar 2005]]<br /> * [[Operating Systems 2005]]<br /> * Software Engineering 2006<br /> ** [[SE2006:group bar|group bar]] - group project team<br /> ** [[http://www.cs.earlham.edu/~fu/mediawiki/index.php/Main_Page group fu]] - group project team<br /> <br /> === Research Projects ===<br /> * [[Cope Environmental Center]]<br /> * [[Earlham Energy Awarness Project|Earlham Energy Awarness Project (EEAP)]]<br /> <br /> === Earlham Committees ===<br /> * [[ERC|Environmental Responsibility Committee]]</div> Hunteke https://wiki.cs.earlham.edu/index.php?title=SE2006:group_bar:18_April_Deliverables&diff=5537 SE2006:group bar:18 April Deliverables 2006-04-18T16:56:16Z <p>Hunteke: </p> <hr /> <div>== Completed as of 18 April 2006 (Beta) ==<br /> <br /> 1. User Interface<br /> * A [http://acl10.cs.earlham.edu:8000/scrapi/ WUI (beta)].<br /> <br /> 2. Documentation<br /> * We have an [http://cs.earlham.edu/~bar/doc/ API] for actually scraping Data written in Java.<br /> <br /> 3. Testing<br /> * We use JUnit.<br /> * See the [http://cs.earlham.edu/~bar/doc/edu/earlham/cs/scrapi/testing/AllTests.html AllTests] documentation for instructions on running the tests in Eclipse.<br /> * For information about the test case coverage see the [http://cs.earlham.edu/~bar/doc/edu/earlham/cs/scrapi/testing/SchemaTest.html Schema Tests] and [http://cs.earlham.edu/~bar/doc/edu/earlham/cs/scrapi/testing/SourceTest.html Source Tests]<br /> <br /> 4. Time Tracking<br /> * Our [http://cs.earlham.edu/~bar/time-tracking/ time-tracking] data.<br /> <br /> 5. Data Store<br /> * Our data is automatically inserted via our scraping software into a Postgres database on millie.cs.earlham.edu. Just run the java program, and the Scheduler will take care of all the nitty/gritty details.</div> Hunteke https://wiki.cs.earlham.edu/index.php?title=SE2006:group_bar&diff=1594 SE2006:group bar 2006-04-18T16:42:38Z <p>Hunteke: /* Assignments */</p> <hr /> <div>==Group==<br /> * [[SE2006:group_bar:minutes|Meeting Minutes]]<br /> * [[SE2006:group_bar:roles|Job Titles]]<br /> <br /> ==Project stuff==<br /> * [[SE2006:group_bar:overview|Project Overview]]<br /> * [[SE2006:group_bar:todo|Todo List]]<br /> * [[SE2006:group_bar:sources|Data Sources]]<br /> * [[SE2006:group_bar:tools|Tools]]<br /> <br /> * [https://www.cs.earlham.edu/bugzilla/buglist.cgi?query_format=specific&amp;order=relevance+desc&amp;bug_status=__open__&amp;product=bar&amp;content= Bugzilla]<br /> * [http://cs.earlham.edu/~bar/viewvc ViewVC]<br /> <br /> ==Documentation==<br /> * [http://cs.earlham.edu/~bar/doc/ Javadoc]<br /> * [[SE2006:group_bar:scrapi|scrAPI Usage]]<br /> * [[SE2006:group_bar:Eclipse Info|Eclipse Info]]<br /> <br /> ==Assignments==<br /> * [[SE2006:group_bar:March Deliverables|March Deliverables]]<br /> * [[SE2006:group_bar:Final sources|Final sources]]<br /> * [[SE2006:group_bar:18 April Deliverables]]</div> Hunteke https://wiki.cs.earlham.edu/index.php?title=File:Bar-wui-model.jpg&diff=5536 File:Bar-wui-model.jpg 2006-04-12T23:03:49Z <p>Hunteke: visual plan of attack of wui interface for scrapi</p> <hr /> <div>visual plan of attack of wui interface for scrapi</div> Hunteke https://wiki.cs.earlham.edu/index.php?title=SE2006:group_bar:overview&diff=5518 SE2006:group bar:overview 2006-04-12T23:02:47Z <p>Hunteke: </p> <hr /> <div>Here is (finally) the picture of our model.<br /> <br /> [[Image:bar-model.jpg]]<br /> <br /> [[Image:bar-wui-model.jpg]]</div> Hunteke https://wiki.cs.earlham.edu/index.php?title=BCCD:Automated_liberation&diff=5508 BCCD:Automated liberation 2006-04-12T07:19:59Z <p>Hunteke: explain how to use qemu with socket connect/listen</p> <hr /> <div>[[BCCD:Automated_liberation:Generalization|Generalization]] Work towards giving the liberation process a more general approach<br /> <br /> ''Do all these commands from /p0/bccd on acl13 (or the equivalent).''<br /> <br /> * Make a fresh work environment /p0/bccd from a BCCD ISO:<br /> &lt;tt&gt;./gen_staging.sh&lt;/tt&gt;<br /> <br /> * Make a new boot ISO (bccdserver.iso):<br /> &lt;tt&gt;./mksingularity.sh singularity staging&lt;/tt&gt;<br /> <br /> * Boot that ISO for liberation:<br /> &lt;tt&gt;qemu -hda lib.img -cdrom bccdserver.iso -boot d&lt;/tt&gt;<br /> <br /> * Look inside the qemu ISO (mount to /mnt/bccd):<br /> &lt;tt&gt;./lomount lib.img 2 /mnt/bccd&lt;/tt&gt;<br /> <br /> * Liberate to the hard drive after booting BCCD:<br /> &lt;tt&gt;/bin/liberate&lt;/tt&gt;<br /> <br /> * Make a server after liberation:<br /> &lt;tt&gt;/bin/prepareserver&lt;/tt&gt;<br /> <br /> * Boot a QEMU image with networking support between VMs (make sure MACs are unique!):<br /> **&lt;tt&gt;qemu -hda lib.img -cdrom bccdserver.iso -net nic,macaddr=52:54:00:12:34:56 -net socket,mcast=230.0.0.1:1234 -boot d&lt;/tt&gt;<br /> <br /> Another way to accomplish the same thing, though perhaps not as efficient: <br /> ** 1. Start the server:<br /> &lt;tt&gt;qemu -hda hdas.img -net nic,macaddr=52:54:00:12:34:50 -net socket,listen=:1234&lt;/tt&gt;<br /> ** 2. Start some clients:<br /> &lt;tt&gt;qemu -cdrom eb-5.4.1-ns8390.iso -net nic,macaddr=52:54:00:12:34:51 -net socket,connect=acl13:1234&lt;/tt&gt;<br /> &lt;tt&gt;qemu -cdrom eb-5.4.1-ns8390.iso -net nic,macaddr=52:54:00:12:34:52 -net socket,connect=acl13.cs.earlham.edu:1234&lt;/tt&gt;<br /> &lt;tt&gt;qemu -cdrom eb-5.4.1-ns8390.iso -net nic,macaddr=52:54:00:12:34:59 -net socket,connect=159.28.230.23:1234&lt;/tt&gt;<br /> <br /> WARNING: Not sure why, but running this networked version of Qemu is /very/ slow. If you have real hardware, consider using it instead.</div> Hunteke https://wiki.cs.earlham.edu/index.php?title=SE2006:group_bar:March_Deliverables&diff=1466 SE2006:group bar:March Deliverables 2006-03-31T15:53:18Z <p>Hunteke: A submission of the March Deliverables</p> <hr /> <div>=March Deliverables=<br /> As requested from Chris' email:<br /> <br /> 1) API Documentation<br /> *Developer documentation on usage<br /> **At this point we do not have API to the Data store.<br /> **We have an API for actually scraping Data. See http://cs.earlham.edu/~bar/doc/<br /> *How to add data new sources<br /> **Check out this url (linked to from above url) http://cs.earlham.edu/~bar/doc/edu/earlham/cs/scrapi/SourceDefinition.html<br /> <br /> 2) Test harness (with instructions) for the API<br /> *We use JUnit, and it must run from Eclipse (for now). Other hooks (to use it) coming soon.<br /> <br /> 3) Data store information<br /> *The data dictionary itself<br /> **Postgres Tobias on Millie.<br /> *Scripts/instructions for creating the schema in the database instance<br /> **There are none because this is done dynamically by our code. (Based on SourceDefinition, see above URL.)<br /> *Scripts/instructions to populate the database with your data sources and their source information<br /> **See above pointer. Just run the java program, and the Scheduler will take care of all the nitty/gritty details.</div> Hunteke https://wiki.cs.earlham.edu/index.php?title=SE2006:group_bar&diff=1524 SE2006:group bar 2006-03-31T15:42:45Z <p>Hunteke: added new section of march deliverables</p> <hr /> <div>* [[SE2006:group_bar:minutes|Meeting Minutes]]<br /> <br /> * [[SE2006:group_bar:roles|Job Titles]]<br /> <br /> * [[SE2006:group_bar:overview|Project Overview]]<br /> <br /> * [[SE2006:group_bar:todo|Todo List]]<br /> <br /> * [[SE2006:group_bar:scrapi|scrAPI Usage]]<br /> <br /> * [[SE2006:group_bar:sources|Data Sources]]<br /> <br /> * [[SE2006:group_bar:tools|Tools]]<br /> <br /> * [[SE2006:groub_bar:March Deliverables|March Deliverables]]</div> Hunteke https://wiki.cs.earlham.edu/index.php?title=SE2006:group_bar:scrapi&diff=5521 SE2006:group bar:scrapi 2006-03-31T15:41:33Z <p>Hunteke: making obsolete</p> <hr /> <div>==Adding New Types==<br /> Creating new types means modifying the Schema. Every time a Schema is instantiated the constructor calls createTypes() which fills in the typeNameSqlTypes and typeNameRegExps HashMaps. createTypes() in turn calls addType which takes the variable name, the sql data type, and the regular expression that will be expanded as arguments.<br /> <br /> &lt;pre&gt;<br /> /* add to me */<br /> private void createTypes() {<br /> addType(&quot;href_tag&quot;,&quot;text&quot;,&quot;(&lt;A href&gt;[\\\\s\\\\S]*?)&quot;);<br /> addType(&quot;string&quot;,&quot;text&quot;,&quot;([\\\\s\\\\S]*?)&quot;);<br /> addType(&quot;int&quot;,&quot;integer&quot;,&quot;(\\d*)&quot;);<br /> addType(&quot;state_abrev&quot;, &quot;varchar(2)&quot;,&quot;(\\\\w\\\\w)&quot;);<br /> addType(&quot;state_abrev&quot;, &quot;varchar(2)&quot;,&quot;(\\\\w\\\\w)&quot;);<br /> addType(&quot;state_census&quot;, &quot;varchar(9)&quot;, &quot;(04000US\\\\d\\\\d)&quot;);<br /> addType(&quot;theater_num&quot;,&quot;integer&quot;,&quot;([^0].*?)&quot;);<br /> addType(&quot;two_char&quot;,&quot;varchar(2)&quot;,&quot;(\\\\w\\\\w)&quot;);<br /> addType(&quot;one_char&quot;,&quot;varchar(1)&quot;,&quot;(\\\\w)&quot;);<br /> addType(&quot;float&quot;,&quot;float&quot;,&quot;([-+]?[0-9]*\\.?[0-9]+)&quot;);<br /> addType(&quot;big_int&quot;,&quot;int&quot;,&quot;([0-9,]*?)&quot;);<br /> }<br /> private void addType(String typeName,String sqlType, String RegExp) { .. }<br /> &lt;/pre&gt;<br /> <br /> ==Skipping Groups==<br /> Note that every type when expanded to a regExp becomes a group. We use the ordering of these groups in the regular expression to make a back reference number to variable name mapping. In order to ensure that any groups you add to a regular expression outside of what will be expanded by a variable will not be picked up as a value for a variable you must make sure that the group is not a back reference. Put a '?' as the first character in that group, e.g., (?.+)for the group you want and use that is in your regular expression.<br /> <br /> <br /> <br /> <br /> =Obsolete Stuff=<br /> ==Defining Sources==<br /> Begin by starting at the bottom of the scrape. Create a regular expression.<br /> &lt;pre&gt;<br /> Schema theaterInfoSchema = <br /> new Schema(&quot;&lt;B&gt;@@@name(string)@@@&lt;/B&gt;&lt;BR&gt;&lt;FONT .*?&gt;@@@street_address(string)@@@&lt;BR&gt;@@@city(string)@@@,[ ]?......&quot;);<br /> &lt;/pre&gt;<br /> <br /> Note that here we use variable names and variable types. The variable names are the eventual keys in the hash returned by the scrape and thus the eventual column names in the database. These names will be replaced by a regular expression associated with the type. The variable name is also associated with a SQL type.<br /> <br /> Next, based on this regular expression and a URL create a Source class.<br /> &lt;pre&gt;<br /> Source theaterInfo = <br /> new Source(&quot;http://www.kerasotes.com/Showtimes.aspx?SearchString=&amp;TheaterSearch=@@@theater_id@@@&amp;OptionTheater=++Go++&quot;,theaterInfoSchema);<br /> &lt;/pre&gt;<br /> <br /> Note that here we have a reference to @@@theater_id@@@ in the URL. This value will inherited from the parent source and filled in the URL. The parent Source will create a new Source for each regexp match it makes on its URL. It is defined with its subSource as an extra argument to the constructor. <br /> <br /> &lt;pre&gt;<br /> Schema kerasotesHome = <br /> new Schema(&quot;&lt;OPTION value=\&quot;@@@theater_id(theater_num)@@@\&quot;[^&gt;]*&gt;.......&quot;);<br /> Source kerasotes = <br /> new Source(&quot;http://www.kerasotes.com/Home.aspx&quot;,kerasotesHome,theaterInfo);<br /> &lt;/pre&gt;<br /> <br /> Here you can see how the Source will pick off @@@theater_id@@@ variable and pass it into its subSource, theaterInfo. Whatever variables appear in the subSource's URL will be expanded based on variable values it inherits from its parent.</div> Hunteke https://wiki.cs.earlham.edu/index.php?title=BCCD:Automated_liberation:Generalization:Initial_Talks&diff=5524 BCCD:Automated liberation:Generalization:Initial Talks 2006-03-23T02:18:23Z <p>Hunteke: fixed html</p> <hr /> <div>&lt;h3&gt;Conversation with skylar@im.cs.earlham.edu at 2006-03-22 20:55:05 on kevin@im.cs.earlham.edu/Gaim (jabber)&lt;/h3&gt;<br /> &lt;font color=&quot;#A82F2F&quot;&gt;&lt;font size=&quot;2&quot;&gt;(20:55:05)&lt;/font&gt; &lt;b&gt;Skylar Thompson:&lt;/b&gt;&lt;/font&gt; You know what we could do with gen_stating?&lt;br/&gt;<br /> &lt;font color=&quot;#A82F2F&quot;&gt;&lt;font size=&quot;2&quot;&gt;(20:55:15)&lt;/font&gt; &lt;b&gt;Skylar Thompson:&lt;/b&gt;&lt;/font&gt; /stating/staging&lt;br/&gt;<br /> &lt;font color=&quot;#16569E&quot;&gt;&lt;font size=&quot;2&quot;&gt;(20:55:22)&lt;/font&gt; &lt;b&gt;Kevo:&lt;/b&gt;&lt;/font&gt; umm, no, but I have a feeling you're going to tell me?&lt;br/&gt;<br /> &lt;font color=&quot;#A82F2F&quot;&gt;&lt;font size=&quot;2&quot;&gt;(20:55:36)&lt;/font&gt; &lt;b&gt;Skylar Thompson:&lt;/b&gt;&lt;/font&gt; Yup.&lt;br/&gt;<br /> &lt;font color=&quot;#16569E&quot;&gt;&lt;font size=&quot;2&quot;&gt;(20:55:36)&lt;/font&gt; &lt;b&gt;Kevo:&lt;/b&gt;&lt;/font&gt; (and a final slash ;) )&lt;br/&gt;<br /> &lt;font color=&quot;#A82F2F&quot;&gt;&lt;font size=&quot;2&quot;&gt;(20:56:10)&lt;/font&gt; &lt;b&gt;Skylar Thompson:&lt;/b&gt;&lt;/font&gt; How would you feel about executing mksingularity at the end of gen_staging, instead of just prompting for it?&lt;br/&gt;<br /> &lt;font color=&quot;#A82F2F&quot;&gt;&lt;font size=&quot;2&quot;&gt;(20:56:29)&lt;/font&gt; &lt;b&gt;Skylar Thompson:&lt;/b&gt;&lt;/font&gt; I guess you&amp;apos;re not guarenteed to want to generate an ISO right off the bat, but an option might be nice.&lt;br/&gt;<br /> &lt;font color=&quot;#16569E&quot;&gt;&lt;font size=&quot;2&quot;&gt;(20:56:43)&lt;/font&gt; &lt;b&gt;Kevo:&lt;/b&gt;&lt;/font&gt; actually, I thought about that, but I'm not ready to do that yet.&lt;br/&gt;<br /> &lt;font color=&quot;#A82F2F&quot;&gt;&lt;font size=&quot;2&quot;&gt;(20:56:51)&lt;/font&gt; &lt;b&gt;Skylar Thompson:&lt;/b&gt;&lt;/font&gt; This&amp;apos;ll let people without much experience take a BCCD and our changes, and only have to execute one script to make the liberation ISO.&lt;br/&gt;<br /> &lt;font color=&quot;#16569E&quot;&gt;&lt;font size=&quot;2&quot;&gt;(20:56:54)&lt;/font&gt; &lt;b&gt;Kevo:&lt;/b&gt;&lt;/font&gt; Specifically because of the stripping business&lt;br/&gt;<br /> &lt;font color=&quot;#16569E&quot;&gt;&lt;font size=&quot;2&quot;&gt;(20:57:02)&lt;/font&gt; &lt;b&gt;Kevo:&lt;/b&gt;&lt;/font&gt; that makes sense&lt;br/&gt;<br /> &lt;font color=&quot;#16569E&quot;&gt;&lt;font size=&quot;2&quot;&gt;(20:57:06)&lt;/font&gt; &lt;b&gt;Kevo:&lt;/b&gt;&lt;/font&gt; then we should have some optinos&lt;br/&gt;<br /> &lt;font color=&quot;#16569E&quot;&gt;&lt;font size=&quot;2&quot;&gt;(20:57:31)&lt;/font&gt; &lt;b&gt;Kevo:&lt;/b&gt;&lt;/font&gt; let the dead simple script run without any options do the standard thing,&lt;br/&gt;<br /> &lt;font color=&quot;#16569E&quot;&gt;&lt;font size=&quot;2&quot;&gt;(20:57:38)&lt;/font&gt; &lt;b&gt;Kevo:&lt;/b&gt;&lt;/font&gt; one of the options could be to stop at stages&lt;br/&gt;<br /> &lt;font color=&quot;#16569E&quot;&gt;&lt;font size=&quot;2&quot;&gt;(20:57:40)&lt;/font&gt; &lt;b&gt;Kevo:&lt;/b&gt;&lt;/font&gt; okay&lt;br/&gt;<br /> &lt;font color=&quot;#16569E&quot;&gt;&lt;font size=&quot;2&quot;&gt;(20:57:56)&lt;/font&gt; &lt;b&gt;Kevo:&lt;/b&gt;&lt;/font&gt; I like the idea&lt;br/&gt;<br /> &lt;font color=&quot;#A82F2F&quot;&gt;&lt;font size=&quot;2&quot;&gt;(20:58:08)&lt;/font&gt; &lt;b&gt;Skylar Thompson:&lt;/b&gt;&lt;/font&gt; Yeah.&lt;br/&gt;<br /> &lt;font color=&quot;#A82F2F&quot;&gt;&lt;font size=&quot;2&quot;&gt;(20:58:42)&lt;/font&gt; &lt;b&gt;Skylar Thompson:&lt;/b&gt;&lt;/font&gt; It&amp;apos;s not really clear to me how the end product is going to be distributed, but it could just be a CVS checkout from us, a stock BCCD ISO from UNI, and some documentation on what to do with them.&lt;br/&gt;<br /> &lt;font color=&quot;#16569E&quot;&gt;&lt;font size=&quot;2&quot;&gt;(20:59:14)&lt;/font&gt; &lt;b&gt;Kevo:&lt;/b&gt;&lt;/font&gt; yeah, that's my thinking too&lt;br/&gt;<br /> &lt;font color=&quot;#16569E&quot;&gt;&lt;font size=&quot;2&quot;&gt;(20:59:26)&lt;/font&gt; &lt;b&gt;Kevo:&lt;/b&gt;&lt;/font&gt; I'm not sure where this is going, so I'm sort of just developing for myself&lt;br/&gt;<br /> &lt;font color=&quot;#16569E&quot;&gt;&lt;font size=&quot;2&quot;&gt;(20:59:34)&lt;/font&gt; &lt;b&gt;Kevo:&lt;/b&gt;&lt;/font&gt; and making sure to keep up with documentation as best as I can&lt;br/&gt;<br /> &lt;font color=&quot;#16569E&quot;&gt;&lt;font size=&quot;2&quot;&gt;(21:00:01)&lt;/font&gt; &lt;b&gt;Kevo:&lt;/b&gt;&lt;/font&gt; it occurs to me&lt;br/&gt;<br /> &lt;font color=&quot;#16569E&quot;&gt;&lt;font size=&quot;2&quot;&gt;(21:00:23)&lt;/font&gt; &lt;b&gt;Kevo:&lt;/b&gt;&lt;/font&gt; after having committed the permissions changing of the group thing (g=u. ..)&lt;br/&gt;<br /> &lt;font color=&quot;#16569E&quot;&gt;&lt;font size=&quot;2&quot;&gt;(21:00:39)&lt;/font&gt; &lt;b&gt;Kevo:&lt;/b&gt;&lt;/font&gt; that that is only helpful to you and me because we are developing on the same machine&lt;br/&gt;<br /> &lt;font color=&quot;#A82F2F&quot;&gt;&lt;font size=&quot;2&quot;&gt;(21:01:07)&lt;/font&gt; &lt;b&gt;Skylar Thompson:&lt;/b&gt;&lt;/font&gt; Right.&lt;br/&gt;<br /> &lt;font color=&quot;#16569E&quot;&gt;&lt;font size=&quot;2&quot;&gt;(21:01:09)&lt;/font&gt; &lt;b&gt;Kevo:&lt;/b&gt;&lt;/font&gt; meaning we can write and copy files without having to sudo all the time&lt;br/&gt;<br /> &lt;font color=&quot;#16569E&quot;&gt;&lt;font size=&quot;2&quot;&gt;(21:01:15)&lt;/font&gt; &lt;b&gt;Kevo:&lt;/b&gt;&lt;/font&gt; I don't know why I got so into it then&lt;br/&gt;<br /> &lt;font color=&quot;#A82F2F&quot;&gt;&lt;font size=&quot;2&quot;&gt;(21:01:16)&lt;/font&gt; &lt;b&gt;Skylar Thompson:&lt;/b&gt;&lt;/font&gt; So maybe we should have a separate permission cleanup script for our own uses?&lt;br/&gt;<br /> &lt;font color=&quot;#16569E&quot;&gt;&lt;font size=&quot;2&quot;&gt;(21:01:24)&lt;/font&gt; &lt;b&gt;Kevo:&lt;/b&gt;&lt;/font&gt; that would make more sense, yes&lt;br/&gt;<br /> &lt;font color=&quot;#16569E&quot;&gt;&lt;font size=&quot;2&quot;&gt;(21:01:28)&lt;/font&gt; &lt;b&gt;Kevo:&lt;/b&gt;&lt;/font&gt; much more&lt;br/&gt;<br /> &lt;font color=&quot;#16569E&quot;&gt;&lt;font size=&quot;2&quot;&gt;(21:01:34)&lt;/font&gt; &lt;b&gt;Kevo:&lt;/b&gt;&lt;/font&gt; no&lt;br/&gt;<br /> &lt;font color=&quot;#16569E&quot;&gt;&lt;font size=&quot;2&quot;&gt;(21:01:37)&lt;/font&gt; &lt;b&gt;Kevo:&lt;/b&gt;&lt;/font&gt; actually no&lt;br/&gt;<br /> &lt;font color=&quot;#A82F2F&quot;&gt;&lt;font size=&quot;2&quot;&gt;(21:01:38)&lt;/font&gt; &lt;b&gt;Skylar Thompson:&lt;/b&gt;&lt;/font&gt; It is very useful for us, because we both need write access to the same files, but we don&amp;apos;t want to f&amp;apos;ing up the permissions within the BCCD.&lt;br/&gt;<br /> &lt;font color=&quot;#16569E&quot;&gt;&lt;font size=&quot;2&quot;&gt;(21:01:48)&lt;/font&gt; &lt;b&gt;Kevo:&lt;/b&gt;&lt;/font&gt; if we're going to package this up for others&lt;br/&gt;<br /> &lt;font color=&quot;#A82F2F&quot;&gt;&lt;font size=&quot;2&quot;&gt;(21:01:52)&lt;/font&gt; &lt;b&gt;Skylar Thompson:&lt;/b&gt;&lt;/font&gt; Your script does that, whereas mine was more indiscriminate.&lt;br/&gt;<br /> &lt;font color=&quot;#16569E&quot;&gt;&lt;font size=&quot;2&quot;&gt;(21:02:13)&lt;/font&gt; &lt;b&gt;Kevo:&lt;/b&gt;&lt;/font&gt; it's likely that someone else will be developing in pairs as well&lt;br/&gt;<br /> &lt;font color=&quot;#16569E&quot;&gt;&lt;font size=&quot;2&quot;&gt;(21:02:19)&lt;/font&gt; &lt;b&gt;Kevo:&lt;/b&gt;&lt;/font&gt; so we should leave the option in&lt;br/&gt;<br /> &lt;font color=&quot;#16569E&quot;&gt;&lt;font size=&quot;2&quot;&gt;(21:02:24)&lt;/font&gt; &lt;b&gt;Kevo:&lt;/b&gt;&lt;/font&gt; if we're going to make a big script&lt;br/&gt;<br /> &lt;font color=&quot;#16569E&quot;&gt;&lt;font size=&quot;2&quot;&gt;(21:02:27)&lt;/font&gt; &lt;b&gt;Kevo:&lt;/b&gt;&lt;/font&gt; and include it in the options&lt;br/&gt;<br /> &lt;font color=&quot;#16569E&quot;&gt;&lt;font size=&quot;2&quot;&gt;(21:02:53)&lt;/font&gt; &lt;b&gt;Kevo:&lt;/b&gt;&lt;/font&gt; very much more, if we start coalescing these scripts, we should either really start to functionalize the bash, or I'd suggest moving to Perl&lt;br/&gt;<br /> &lt;font color=&quot;#16569E&quot;&gt;&lt;font size=&quot;2&quot;&gt;(21:03:19)&lt;/font&gt; &lt;b&gt;Kevo:&lt;/b&gt;&lt;/font&gt; we're kind of just ragtagging it now to make it work, yes?&lt;br/&gt;<br /> &lt;font color=&quot;#16569E&quot;&gt;&lt;font size=&quot;2&quot;&gt;(21:03:43)&lt;/font&gt; &lt;b&gt;Kevo:&lt;/b&gt;&lt;/font&gt; what do you think?&lt;br/&gt;<br /> &lt;font color=&quot;#16569E&quot;&gt;&lt;font size=&quot;2&quot;&gt;(21:04:19)&lt;/font&gt; &lt;b&gt;Kevo:&lt;/b&gt;&lt;/font&gt; I seem to have lost you . . .&lt;br/&gt;<br /> &lt;font color=&quot;#A82F2F&quot;&gt;&lt;font size=&quot;2&quot;&gt;(21:04:27)&lt;/font&gt; &lt;b&gt;Skylar Thompson:&lt;/b&gt;&lt;/font&gt; Perl might not be a bad idea.&lt;br/&gt;<br /> &lt;font color=&quot;#A82F2F&quot;&gt;&lt;font size=&quot;2&quot;&gt;(21:04:46)&lt;/font&gt; &lt;b&gt;Skylar Thompson:&lt;/b&gt;&lt;/font&gt; I think we&amp;apos;re both more familiar with Perl than bash, and it&amp;apos;s more powerful anyways.&lt;br/&gt;<br /> &lt;font color=&quot;#A82F2F&quot;&gt;&lt;font size=&quot;2&quot;&gt;(21:05:22)&lt;/font&gt; &lt;b&gt;Skylar Thompson:&lt;/b&gt;&lt;/font&gt; Sorry about the delays; I&amp;apos;m playing Freeciv with my girlfriend while doing BCCD stuff. :)&lt;br/&gt;<br /> &lt;font color=&quot;#16569E&quot;&gt;&lt;font size=&quot;2&quot;&gt;(21:05:32)&lt;/font&gt; &lt;b&gt;Kevo:&lt;/b&gt;&lt;/font&gt; well, power is relative. I just discovered that you can do regular expressions natively in bash, and it has a host of tools sort of built into&lt;br/&gt;<br /> &lt;font color=&quot;#16569E&quot;&gt;&lt;font size=&quot;2&quot;&gt;(21:05:33)&lt;/font&gt; &lt;b&gt;Kevo:&lt;/b&gt;&lt;/font&gt; haha&lt;br/&gt;<br /> &lt;font color=&quot;#16569E&quot;&gt;&lt;font size=&quot;2&quot;&gt;(21:05:51)&lt;/font&gt; &lt;b&gt;Kevo:&lt;/b&gt;&lt;/font&gt; but I can get with the fact the we're stronger with perl&lt;br/&gt;<br /> &lt;font color=&quot;#16569E&quot;&gt;&lt;font size=&quot;2&quot;&gt;(21:06:05)&lt;/font&gt; &lt;b&gt;Kevo:&lt;/b&gt;&lt;/font&gt; and it's guaranteed at least to be on our development environments and that of the BCCD&lt;br/&gt;<br /> &lt;font color=&quot;#16569E&quot;&gt;&lt;font size=&quot;2&quot;&gt;(21:06:26)&lt;/font&gt; &lt;b&gt;Kevo:&lt;/b&gt;&lt;/font&gt; I think we can start with something like that next Wednesday night&lt;br/&gt;<br /> &lt;font color=&quot;#16569E&quot;&gt;&lt;font size=&quot;2&quot;&gt;(21:06:47)&lt;/font&gt; &lt;b&gt;Kevo:&lt;/b&gt;&lt;/font&gt; I'm about to pooh out because I've got a history paper to start writing. I'm likely to bow out for the rest of the week.&lt;br/&gt;<br /> &lt;font color=&quot;#A82F2F&quot;&gt;&lt;font size=&quot;2&quot;&gt;(21:06:57)&lt;/font&gt; &lt;b&gt;Skylar Thompson:&lt;/b&gt;&lt;/font&gt; Yeah.&lt;br/&gt;<br /> &lt;font color=&quot;#A82F2F&quot;&gt;&lt;font size=&quot;2&quot;&gt;(21:06:59)&lt;/font&gt; &lt;b&gt;Skylar Thompson:&lt;/b&gt;&lt;/font&gt; That works for me.&lt;br/&gt;<br /> &lt;font color=&quot;#A82F2F&quot;&gt;&lt;font size=&quot;2&quot;&gt;(21:07:07)&lt;/font&gt; &lt;b&gt;Skylar Thompson:&lt;/b&gt;&lt;/font&gt; Good luck on that paper.&lt;br/&gt;<br /> &lt;font color=&quot;#16569E&quot;&gt;&lt;font size=&quot;2&quot;&gt;(21:07:19)&lt;/font&gt; &lt;b&gt;Kevo:&lt;/b&gt;&lt;/font&gt; Thanks. I'm going to post this conversation to the notes, k?&lt;br/&gt;<br /> &lt;font color=&quot;#A82F2F&quot;&gt;&lt;font size=&quot;2&quot;&gt;(21:08:28)&lt;/font&gt; &lt;b&gt;Skylar Thompson:&lt;/b&gt;&lt;/font&gt; Sounds good.&lt;br/&gt;</div> Hunteke https://wiki.cs.earlham.edu/index.php?title=BCCD:Automated_liberation:Generalization:Initial_Talks&diff=1406 BCCD:Automated liberation:Generalization:Initial Talks 2006-03-23T02:12:55Z <p>Hunteke: </p> <hr /> <div>(20:55:05) Skylar Thompson: You know what we could do with gen_stating?<br /> (20:55:15) Skylar Thompson: /stating/staging<br /> (20:55:22) Kevo: umm, no, but I have a feeling you're going to tell me?<br /> (20:55:36) Skylar Thompson: Yup.<br /> (20:55:36) Kevo: (and a final slash ;) )<br /> (20:56:10) Skylar Thompson: How would you feel about executing mksingularity at the end of gen_staging, instead of just prompting for it?<br /> (20:56:29) Skylar Thompson: I guess you're not guarenteed to want to generate an ISO right off the bat, but an option might be nice.<br /> (20:56:43) Kevo: actually, I thought about that, but I'm not ready to do that yet.<br /> (20:56:51) Skylar Thompson: This'll let people without much experience take a BCCD and our changes, and only have to execute one script to make the liberation ISO.<br /> (20:56:54) Kevo: Specifically because of the stripping business<br /> (20:57:02) Kevo: that makes sense<br /> (20:57:06) Kevo: then we should have some optinos<br /> (20:57:31) Kevo: let the dead simple script run without any options do the standard thing,<br /> (20:57:38) Kevo: one of the options could be to stop at stages<br /> (20:57:40) Kevo: okay<br /> (20:57:56) Kevo: I like the idea<br /> (20:58:08) Skylar Thompson: Yeah.<br /> (20:58:42) Skylar Thompson: It's not really clear to me how the end product is going to be distributed, but it could just be a CVS checkout from us, a stock BCCD ISO from UNI, and some documentation on what to do with them.<br /> (20:59:14) Kevo: yeah, that's my thinking too<br /> (20:59:26) Kevo: I'm not sure where this is going, so I'm sort of just developing for myself<br /> (20:59:34) Kevo: and making sure to keep up with documentation as best as I can<br /> (21:00:01) Kevo: it occurs to me<br /> (21:00:23) Kevo: after having committed the permissions changing of the group thing (g=u. ..)<br /> (21:00:39) Kevo: that that is only helpful to you and me because we are developing on the same machine<br /> (21:01:07) Skylar Thompson: Right.<br /> (21:01:09) Kevo: meaning we can write and copy files without having to sudo all the time<br /> (21:01:15) Kevo: I don't know why I got so into it then<br /> (21:01:16) Skylar Thompson: So maybe we should have a separate permission cleanup script for our own uses?<br /> (21:01:24) Kevo: that would make more sense, yes<br /> (21:01:28) Kevo: much more<br /> (21:01:34) Kevo: no<br /> (21:01:37) Kevo: actually no<br /> (21:01:38) Skylar Thompson: It is very useful for us, because we both need write access to the same files, but we don't want to f'ing up the permissions within the BCCD.<br /> (21:01:48) Kevo: if we're going to package this up for others<br /> (21:01:52) Skylar Thompson: Your script does that, whereas mine was more indiscriminate.<br /> (21:02:13) Kevo: it's likely that someone else will be developing in pairs as well<br /> (21:02:19) Kevo: so we should leave the option in<br /> (21:02:24) Kevo: if we're going to make a big script<br /> (21:02:27) Kevo: and include it in the options<br /> (21:02:53) Kevo: very much more, if we start coalescing these scripts, we should either really start to functionalize the bash, or I'd suggest moving to Perl<br /> (21:03:19) Kevo: we're kind of just ragtagging it now to make it work, yes?<br /> (21:03:43) Kevo: what do you think?<br /> (21:04:19) Kevo: I seem to have lost you . . .<br /> (21:04:27) Skylar Thompson: Perl might not be a bad idea.<br /> (21:04:46) Skylar Thompson: I think we're both more familiar with Perl than bash, and it's more powerful anyways.<br /> (21:05:22) Skylar Thompson: Sorry about the delays; I'm playing Freeciv with my girlfriend while doing BCCD stuff. :)<br /> (21:05:32) Kevo: well, power is relative. I just discovered that you can do regular expressions natively in bash, and it has a host of tools sort of built into<br /> (21:05:33) Kevo: haha<br /> (21:05:51) Kevo: but I can get with the fact the we're stronger with perl<br /> (21:06:05) Kevo: and it's guaranteed at least to be on our development environments and that of the BCCD<br /> (21:06:26) Kevo: I think we can start with something like that next Wednesday night<br /> (21:06:47) Kevo: I'm about to pooh out because I've got a history paper to start writing. I'm likely to bow out for the rest of the week.<br /> (21:06:57) Skylar Thompson: Yeah.<br /> (21:06:59) Skylar Thompson: That works for me.<br /> (21:07:07) Skylar Thompson: Good luck on that paper.<br /> (21:07:19) Kevo: Thanks. I'm going to post this conversation to the notes, k?<br /> (21:08:28) Skylar Thompson: Sounds good.</div> Hunteke https://wiki.cs.earlham.edu/index.php?title=BCCD:Automated_liberation:Generalization&diff=5523 BCCD:Automated liberation:Generalization 2006-03-23T02:12:09Z <p>Hunteke: created page, added link to initial conversation</p> <hr /> <div>[[BCCD:Automated_liberation:Generalization:Initial_Talks|Initial Conversation]] The initial conversation between Skylar and Kevin</div> Hunteke https://wiki.cs.earlham.edu/index.php?title=BCCD:Automated_liberation&diff=1556 BCCD:Automated liberation 2006-03-23T02:10:56Z <p>Hunteke: added link to generalization</p> <hr /> <div>[[BCCD:Automated_liberation:Generalization|Generalization]] Work towards giving the liberation process a more general approach<br /> <br /> ''Do all these commands from /p0/bccd on acl13 (or the equivalent).''<br /> <br /> * Make a fresh work environment /p0/bccd from a BCCD ISO:<br /> &lt;tt&gt;./gen_staging.sh&lt;/tt&gt;<br /> <br /> * Make a new boot ISO (bccdserver.iso):<br /> &lt;tt&gt;./mksingularity.sh singularity staging&lt;/tt&gt;<br /> <br /> * Boot that ISO for liberation:<br /> &lt;tt&gt;qemu -hda lib.img -cdrom bccdserver.iso -boot d&lt;/tt&gt;<br /> <br /> * Look inside the qemu ISO (mount to /mnt/bccd):<br /> &lt;tt&gt;./lomount lib.img 2 /mnt/bccd&lt;/tt&gt;<br /> <br /> * Liberate to the hard drive after booting BCCD:<br /> &lt;tt&gt;/bin/liberate&lt;/tt&gt;<br /> <br /> * Make a server after liberation:<br /> &lt;tt&gt;/bin/prepareserver&lt;/tt&gt;<br /> <br /> * Boot a QEMU image with networking support between VMs (make sure MACs are unique!):<br /> &lt;tt&gt;qemu -hda lib.img -cdrom bccdserver.iso -net nic,macaddr=52:54:00:12:34:56 -net socket,mcast=230.0.0.1:1234 -boot d&lt;/tt&gt;</div> Hunteke https://wiki.cs.earlham.edu/index.php?title=File:Bar-model.jpg&diff=5519 File:Bar-model.jpg 2006-03-17T00:32:56Z <p>Hunteke: Group Bar's project model, spelled out on the whiteboard.</p> <hr /> <div>Group Bar's project model, spelled out on the whiteboard.</div> Hunteke https://wiki.cs.earlham.edu/index.php?title=SE2006:group_bar:overview&diff=1560 SE2006:group bar:overview 2006-03-17T00:30:53Z <p>Hunteke: </p> <hr /> <div>Here is (finally) the picture of our model.<br /> <br /> [[Image:bar-model.jpg]]</div> Hunteke https://wiki.cs.earlham.edu/index.php?title=SE2006:group_bar&diff=1388 SE2006:group bar 2006-03-17T00:29:45Z <p>Hunteke: add overview link</p> <hr /> <div>* [[SE2006:group_bar:minutes|Meeting Minutes]]<br /> <br /> * [[SE2006:group_bar:roles|Job Titles]]<br /> <br /> * [[SE2006:group_bar:overview|Project Overview]]</div> Hunteke https://wiki.cs.earlham.edu/index.php?title=BCCD:Fossilizing&diff=1384 BCCD:Fossilizing 2006-03-15T20:30:23Z <p>Hunteke: </p> <hr /> <div>=This page is now OLD or Stale=<br /> Your mileage may vary, and we are not updating this page any longer. We use it internally for reference, but we are working elsewhere. Thanks.<br /> <br /> =Liberating the BCCD=<br /> This section outlines the steps required to disassemble a BCCD ISO, manifest it on a hard disk drive, and boot from that hard drive. Most or all of this '''must be done as root'''.<br /> <br /> ==Mount the Images==<br /> <br /> These scripts, used for the lnx-bbc project, might prove to be helpful in working with the BCCD images: <br /> [[BCCD:FossilScripts|FossilScripts]]<br /> ===The Basic Images===<br /> &lt;pre&gt;<br /> cd /mnt # or where ever<br /> mkdir bccd<br /> mount -t iso9660 -o loop bccd-ppc-2005-08-30T00-0500.iso bccd<br /> <br /> # on PPC<br /> mkdir initrd<br /> gunzip &lt; bccd/boot/root.bin &gt; initrd.ext2<br /> mount -t ext2 -o loop initrd.ext2 initrd<br /> <br /> # on x86<br /> mkdir lnx<br /> mount -o loop bccd/lnx.img lnx<br /> mkdir root<br /> gunzip &lt; lnx/root.bin &gt; root.ext2<br /> mount -o loop root.ext2 root<br /> &lt;/pre&gt;<br /> <br /> ===The singularity===<br /> '''First, decompress the singularity with the cloop utility &lt;code&gt;extract_compressed_fs&lt;/code&gt;:'''<br /> &lt;pre&gt;<br /> wget http://developer.linuxtag.net/knoppix/sources/cloop_0.66-1.tar.gz<br /> tar xzf cloop_0.66-1.tar.gz<br /> cd cloop-0.66<br /> vim Makefile # add APPSONLY=1 at the top<br /> make zcode<br /> make extract_compressed_fs<br /> ./extract_compressed_fs ../bccd/singularity &gt; ../singularity.romfs<br /> cd ..<br /> &lt;/pre&gt;<br /> The latest currently-available version of cloop (2.01) doesn't work for this purpose; others might (I didn't experiment), but 0.66 definitely does.<br /> <br /> '''Next, mount the singularity (you must have romfs support compiled into the kernel):'''<br /> &lt;pre&gt;<br /> mkdir singularity<br /> mount -t romfs -o loop singularity.romfs singularity<br /> &lt;/pre&gt;<br /> <br /> ==Extract the singularity==<br /> &lt;pre&gt;<br /> cd singularity<br /> tar cf - . | (cd /path/to/destination/partition;tar xvf -)<br /> &lt;/pre&gt;<br /> <br /> ==Create a working initrd==<br /> Create an initrd for fossilized booting with the linuxrc at http://ppckernel.org/~tobias/bccd/linuxrc:<br /> &lt;pre&gt;<br /> cd /mnt/root # or where ever you mounted root.ext2 (from root.bin)<br /> wget http://ppckernel.org/~tobias/bccd/linuxrc # replace the existing linuxrc<br /> chmod a+x linuxrc<br /> cd ..<br /> umount root<br /> gzip &lt; root.ext2 &gt; /path/to/destination/partition/boot/root.bin<br /> &lt;/pre&gt;<br /> <br /> ==Edit singularity-init==<br /> ===Add / remount read-write hook===<br /> Edit &lt;code&gt;/sbin/singularity-init&lt;/code&gt; to remount / read-write during init, using the following command:<br /> &lt;pre&gt;<br /> debug &quot;Remounting / read-write...&quot;<br /> mount -o rw,remount /dev/root /<br /> &lt;/pre&gt;<br /> This can be placed somewhere around the proc mount command.<br /> <br /> ===Prepare for Fossilization of /mnt/rw===<br /> Comment out lines concerning /mnt/rw<br /> &lt;pre&gt;<br /> # mount -n -t tmpfs none /mnt/rw<br /> &lt;/pre&gt;<br /> <br /> ===Add network setup to singularity-init===<br /> &lt;pre&gt;<br /> ifconfig eth0 inet 192.168.10.1 netmask 255.255.255.0 broadcast 192.168.10.255 up<br /> route add default gw 192.168.10.1 eth0<br /> &lt;/pre&gt;<br /> <br /> ==Configure the bootloader==<br /> Configure your bootloader (e.g., yaboot, lilo, or grub) as follows:<br /> * boot the kernel &lt;code&gt;/boot/vmlinux&lt;/code&gt; on PowerPC or &lt;code&gt;/boot/bzImage&lt;/code&gt; on x86<br /> * use the initrd &lt;code&gt;/boot/root.bin&lt;/code&gt;<br /> * execute the init script &lt;code&gt;/linuxrc&lt;/code&gt;.<br /> <br /> Here is a sample [http://ppckernel.org/~tmcnulty/bccd/lilo.conf lilo.conf].<br /> <br /> ===Setup Compatibility Nodes===<br /> Add the following to /linuxrc:<br /> * /sbin/devfsd /dev<br /> <br /> ==De-Obfuscation==<br /> <br /> ===Remove Unneeded Symlinks===<br /> <br /> The deal is that the BCCD is now on a different (read/writeable) medium: a harddisk. Let's un-obfuscate some of the workings. An ls -l on / will reveal a few symlinks: /etc, /home, /local, /tmp, and /var. All of these point to an appropriate directory in /mnt/rw. What happens is that since the CD is not writeable, it creates a ramdisk, copies files from /etc.ro/ to /mnt/rw/etc/ (change etc accordingly), and then the /etc symlink becomes a writeable medium.<br /> <br /> Here's the works:<br /> &lt;pre&gt;<br /> rm /etc /home /local /tmp /var<br /> mkdir /etc /home /local /tmp /var<br /> cd /etc.ro &amp;&amp; tar cf - . | (cd /etc/; tar vf -)<br /> cd /home.ro &amp;&amp; tar cf - . | (cd /home/; tar vf -)<br /> cd /local.ro &amp;&amp; tar cf - . | (cd /local/; tar vf -)<br /> cd /tmp.ro &amp;&amp; tar cf - . | (cd /tmp/; tar vf -)<br /> cd /var.ro &amp;&amp; tar cf - . | (cd /var/; tar vf -)<br /> &lt;/pre&gt;<br /> <br /> You're almost done, except you should remove the place in the scripts where the bootup copies the files from /&lt;dir&gt;.ro/. Just comment out the lines in /sbin/singularity-init that do the copying (around line 105):<br /> <br /> &lt;pre&gt;<br /> # cp -a /etc.ro /mnt/rw/etc<br /> # cp -a /var.ro /mnt/rw/var<br /> &lt;/pre&gt;<br /> <br /> While you're editing /sbin/singularity-init, also comment out these lines:<br /> <br /> &lt;pre&gt;<br /> # rsync -plarv /lib/mozilla-1.6/plugins.ro/ /mnt/rw/plugins/<br /> # chmod 1777 /mnt/rw/tmp<br /> # debug &quot;Making /mnt/rw/tmp/build links&quot;<br /> # mkdir -p /mnt/rw/tmp/build/<br /> # mkdir -p /mnt/rw/tmp/build/staging<br /> # mkdir -p /mnt/rw/tmp/build/staging/singularity<br /> # mkdir -p /mnt/rw/tmp/build/staging/singularity/image<br /> # ln -s /lib /mnt/rw/tmp/build/staging/singularity/image/lib<br /> &lt;/pre&gt;<br /> <br /> ===Configure gcc Environment===<br /> <br /> Though the BCCD is now fossilized onto the harddrive, the gcc environment does not know this as it was compiled for the CD. It will look for files in (effectively) /tmp/build/staging/singularity/image/lib ... the directories and symlink creation that we just commented out. Since /tmp is a fossilized directory, just create a symlink inside of it:<br /> <br /> &lt;pre&gt;<br /> mkdir -p /tmp/build/staging/singularity/image<br /> cd /tmp/build/staging/singularity/image/<br /> ln -s /lib<br /> &lt;/pre&gt;<br /> <br /> ==TODO==<br /> * fix the mounting commands so that / is only mounted once (?)<br /> * decide how to handle directories like /etc that are mounted in ram at /dev/rw/etc and populated with items from /etc.ro (leave as is, or create a script to simplify the setup for hard disk booting?)<br /> ** Kevin's done this, we just need to document<br /> *** DONE<br /> * modify init scripts to make them appropriate for hard disk booting (e.g., remove the &quot;Enter a password for the default user&quot; prompt)<br /> ** This appears to be done<br /> * finish setting up networking<br /> * create a patch against the original singularity image for /sbin/singularity-init and other modified configuration files for automating the fossilize process<br /> * package up any binary additions with list-packages (see the package instructions in the wiki)<br /> * last but not least, keep track of all the changes we make!<br /> <br /> Good luck! Direct questions and comments to [mailto:tobias@cs.earlham.edu tobias@cs.earlham.edu].</div> Hunteke https://wiki.cs.earlham.edu/index.php?title=SE2006:group_bar:minutes&diff=1370 SE2006:group bar:minutes 2006-03-14T03:03:08Z <p>Hunteke: /* Mar 13 */</p> <hr /> <div>==Feb 15==<br /> <br /> '''Possible meeting time:''' Working M/W/F in the evening for 1 or 2 hours starting the 27th. Toby, Kevin, and I are going to be working this weekend on clustcomp projects and then going to a conference on Feb 22-26.<br /> <br /> *Languages:<br /> **php - most of us are familiar. big libraries. web stuff.<br /> **java with tomcat - web stuff. good development environment.<br /> **python - learn a new language.<br /> **perl - most of us are familiar. less good, but good web stuff.<br /> **ruby - learn a new language. there may be other reasons but we don't know what they are because we don't know ruby.<br /> <br /> *Caching Location data:<br /> **with memcache (http://www.danga.com/memcached/)<br /> **postgres<br /> **mysql<br /> <br /> *Communication<br /> **using a mailing list for now.<br /> **developing new methods as they seem fit (wiki,cvs,bulletin board).<br /> <br /> *Group name:<br /> **kartgoolers.<br /> **cartooglers.<br /> **pwners<br /> **colin's team.<br /> **group-b<br /> **group bar<br /> <br /> *Assignment:<br /> **send us your group name choice to list. we accept write ins. if anyone feels super strong about a name then tell us why.<br /> **submit your leader (self?)nominations.<br /> <br /> <br /> ==Feb 28==<br /> <br /> * We have decided on some of the roles:<br /> ** Aybars: Libarian<br /> ** Alex &amp; ColinC: Developers<br /> ** Tobias: Leader<br /> ** Kevin: Architect<br /> <br /> * We have roughly agreed on meeting Monday, Tuesday and Wednesdays.<br /> <br /> * We have discussed which language to use, and decided that we'll decide on that later after we break the project up a little bit more (possibly tomorrow).<br /> <br /> * Tomorrow we will discuss the documentation.<br /> <br /> * We will look at the lab 2 solutions soon.<br /> <br /> * Error checking?<br /> <br /> <br /> ==Mar 1==<br /> <br /> * We worked on breaking this project into smaller pieces.<br /> <br /> * For database we are going to use SQL and for the rest of the project, we will probably use Java.<br /> <br /> * We will use Javadoc for documentation of the API<br /> <br /> * Next meeting we are going to talk about:<br /> ** Lab 2 solutions<br /> ** Time budgeting<br /> ** Eclipse review<br /> ** Java prep<br /> ** Kevin will bug Skylar about getting Java API installed on Quark.<br /> ** We have two solutions so far on the table<br /> ** We will talk more about documentation<br /> <br /> ==Mar 6==<br /> * we went over our lab 2 solutions:<br /> &lt;blockquote&gt;<br /> We compared three of our Kerasotes lab scripts. We apparently all wrote them in PHP. The best innovations we found were Toby's data point definition abstraction and test suite. In essence, the data point definition abstraction allows one to describe a data source and data points that one would like to harvest in a general manner. The test suite is a basis for more general testing of the software that we will write. Also of note, were some of our findings as far as regular expressions. For instance, as a group we learned how to make a regular expression not greedy and how to not save a group (?).<br /> &lt;/blockquote&gt;<br /> <br /> &lt;blockquote&gt;<br /> Attached you will find an image of our general model thus far. We have already incorporated some of the ideas discussed in this session, including a more general data point abstraction and streamlined data flow between the programmer API, database, and WUI. As part of our plan, we intend to use Java as the base language, XML for temporary data storage and transfer, PostgreSQL or MySQL for data storage, and XHTML Transitional and JavaScript for the WUI.<br /> &lt;/blockquote&gt;<br /> * eclipse overview and java prep held till next mtg.<br /> * java API + doc has been installed on quark<br /> <br /> ==Mar 7==<br /> <br /> * Toby went over Eclipse basics with us<br /> * We set up a CVS repository on Quark in &lt;code&gt;/clients/groups/bar/cvs/&lt;/code&gt;<br /> ** So far, we're planning on using the repository through Eclipse's interface<br /> * We went over Java basics, and described the Javadoc idea<br /> <br /> *On the boiler plate:<br /> ** Have a discussion and get in writing exactly what our individual jobs entail.<br /> ** Show how Javadoc works<br /> *** Develop our group's commenting style<br /> ** Think about our coding style, especially as regards code formatting<br /> ** CVS plumbing (CVS spam, bugzilla, etc.)<br /> <br /> ==Mar 8==<br /> <br /> * We decided on the roles. [[SE2006:group_bar:roles]]<br /> <br /> * We went over using Javadoc feature of Eclipse.<br /> <br /> * Next time we are going to:<br /> ** Flesh out the model.<br /> ** Write the stubs of the code<br /> <br /> ==Mar 13==<br /> <br /> *Sources<br /> **[[http://factfinder.census.gov/home/saff/main.html fact finder]]<br /> **[[http://www.usairnet.com/cgi-bin/launch/code.cgi Surface Condition Weather Forecasting for Air Sports Aviators]]<br /> **[[http://www.eia.doe.gov/ Energy Information Administration]]<br /> **[[http://fisher.lib.virginia.edu/collections/ Geostat Center: Collections]]<br /> **[[http://www.census.gov/ipc/www/idbnew.html US Census Bureau: International Database (IDB)]]<br /> **<br /> <br /> *Perhaps useful sources<br /> **[[http://plue.sedac.ciesin.org/plue/ddviewer/ Demographic Data Viewer]]</div> Hunteke https://wiki.cs.earlham.edu/index.php?title=SE2006:group_bar:roles&diff=1411 SE2006:group bar:roles 2006-03-09T03:01:59Z <p>Hunteke: </p> <hr /> <div>In addition to developing code, we've assigned these extra jobs to ourselves.<br /> <br /> * Libarian (Aybars)<br /> ** maintain minutes<br /> *** What happens (at a high level, but include significant details)<br /> *** Maintain -- in the minutes -- an agenda or TODO list (for the next meeting or just in general)<br /> ** will keep group on task, and make sure individual choices fit with the whole.<br /> *** be aware of what project everyone is currently working on,<br /> *** and be sure to keep us on task in relation to where we would like to go<br /> ** in general keep notes<br /> <br /> * Developer (All of usex &amp; ColinC)<br /> ** write code<br /> ** write documentation<br /> ** help other developers<br /> *** be extra eyes,<br /> *** listen,<br /> *** help others clarify ideas<br /> ** work in teams (team code - &quot;One Keyboard, Two Minds&quot;)<br /> ** be friendly and generally good spirited<br /> ** rotate through Speedway runs<br /> <br /> * Leader (Tobias)<br /> ** Run the meetings<br /> *** keep us on task as regards the meeting's agenda<br /> *** make sure we stay on task (and don't dissipate into jokes)<br /> ** will be a backup librarian -&gt; make sure we're on task, help librarian think<br /> ** generally manage the human factor of the group<br /> ** if a disagreement arises, will be (unbiased) arbiter<br /> <br /> * Architect (Kevin)<br /> ** Will lead design of basic interfaces for different parts of the model<br /> ** facilitate modularization of development tasks<br /> *** break up problems into smaller, more manageable parts to code</div> Hunteke https://wiki.cs.earlham.edu/index.php?title=SE2006:group_bar:roles&diff=1351 SE2006:group bar:roles 2006-03-09T03:00:10Z <p>Hunteke: Fleshing out of roles</p> <hr /> <div>In addition to developing code, we've assigned these extra jobs to ourselves.<br /> <br /> * Libarian (Aybars) -<br /> - maintain minutes<br /> - What happens (at a high level, but include significant details)<br /> - Maintain -- in the minutes -- an agenda or TODO list (for the next meeting or just in general)<br /> - will keep group on task, and make sure individual choices fit with the whole.<br /> - be aware of what project everyone is currently working on,<br /> - and be sure to keep us on task in relation to where we would like to go<br /> - in general keep notes<br /> <br /> * Developer (All of usex &amp; ColinC: Developers<br /> - write code<br /> - write documentation<br /> - help other developers<br /> - be extra eyes,<br /> - listen,<br /> - help others clarify ideas<br /> - work in teams (team code - &quot;One Keyboard, Two Minds&quot;)<br /> - be friendly and generally good spirited<br /> - rotate through Speedway runs<br /> <br /> * Leader (Tobias)<br /> - Run the meetings<br /> - keep us on task as regards the meeting's agenda<br /> - make sure we stay on task (and don't dissipate into jokes)<br /> - will be a backup librarian -&gt; make sure we're on task, help librarian think<br /> - generally manage the human factor of the group<br /> - if a disagreement arises, will be (unbiased) arbiter<br /> <br /> * Architect (Kevin)<br /> - Will lead design of basic interfaces for different parts of the model<br /> - facilitate modularization of development tasks<br /> - break up problems into smaller, more manageable parts to code</div> Hunteke https://wiki.cs.earlham.edu/index.php?title=SE2006:group_bar&diff=1383 SE2006:group bar 2006-03-09T02:31:34Z <p>Hunteke: Job title link addition</p> <hr /> <div>* [[SE2006:group_bar:minutes|Meeting Minutes]]<br /> <br /> * [[SE2006:group_bar:roles|Job Titles]]</div> Hunteke https://wiki.cs.earlham.edu/index.php?title=SE2006:group_bar:minutes&diff=1352 SE2006:group bar:minutes 2006-03-08T03:29:56Z <p>Hunteke: </p> <hr /> <div>==Feb 15==<br /> <br /> '''Possible meeting time:''' Working M/W/F in the evening for 1 or 2 hours starting the 27th. Toby, Kevin, and I are going to be working this weekend on clustcomp projects and then going to a conference on Feb 22-26.<br /> <br /> *Languages:<br /> **php - most of us are familiar. big libraries. web stuff.<br /> **java with tomcat - web stuff. good development environment.<br /> **python - learn a new language.<br /> **perl - most of us are familiar. less good, but good web stuff.<br /> **ruby - learn a new language. there may be other reasons but we don't know what they are because we don't know ruby.<br /> <br /> *Caching Location data:<br /> **with memcache (http://www.danga.com/memcached/)<br /> **postgres<br /> **mysql<br /> <br /> *Communication<br /> **using a mailing list for now.<br /> **developing new methods as they seem fit (wiki,cvs,bulletin board).<br /> <br /> *Group name:<br /> **kartgoolers.<br /> **cartooglers.<br /> **pwners<br /> **colin's team.<br /> **group-b<br /> **group bar<br /> <br /> *Assignment:<br /> **send us your group name choice to list. we accept write ins. if anyone feels super strong about a name then tell us why.<br /> **submit your leader (self?)nominations.<br /> <br /> <br /> ==Feb 28==<br /> <br /> * We have decided on some of the roles:<br /> ** Aybars: Libarian<br /> ** Alex &amp; ColinC: Developers<br /> ** Tobias: Leader<br /> ** Kevin: Architect<br /> <br /> * We have roughly agreed on meeting Monday, Tuesday and Wednesdays.<br /> <br /> * We have discussed which language to use, and decided that we'll decide on that later after we break the project up a little bit more (possibly tomorrow).<br /> <br /> * Tomorrow we will discuss the documentation.<br /> <br /> * We will look at the lab 2 solutions soon.<br /> <br /> * Error checking?<br /> <br /> <br /> ==Mar 1==<br /> <br /> * We worked on breaking this project into smaller pieces.<br /> <br /> * For database we are going to use SQL and for the rest of the project, we will probably use Java.<br /> <br /> * We will use Javadoc for documentation of the API<br /> <br /> * Next meeting we are going to talk about:<br /> ** Lab 2 solutions<br /> ** Time budgeting<br /> ** Eclipse review<br /> ** Java prep<br /> ** Kevin will bug Skylar about getting Java API installed on Quark.<br /> ** We have two solutions so far on the table<br /> ** We will talk more about documentation<br /> <br /> ==Mar 6==<br /> * we went over our lab 2 solutions:<br /> &lt;blockquote&gt;<br /> We compared three of our Kerasotes lab scripts. We apparently all wrote them in PHP. The best innovations we found were Toby's data point definition abstraction and test suite. In essence, the data point definition abstraction allows one to describe a data source and data points that one would like to harvest in a general manner. The test suite is a basis for more general testing of the software that we will write. Also of note, were some of our findings as far as regular expressions. For instance, as a group we learned how to make a regular expression not greedy and how to not save a group (?).<br /> &lt;/blockquote&gt;<br /> <br /> &lt;blockquote&gt;<br /> Attached you will find an image of our general model thus far. We have already incorporated some of the ideas discussed in this session, including a more general data point abstraction and streamlined data flow between the programmer API, database, and WUI. As part of our plan, we intend to use Java as the base language, XML for temporary data storage and transfer, PostgreSQL or MySQL for data storage, and XHTML Transitional and JavaScript for the WUI.<br /> &lt;/blockquote&gt;<br /> * eclipse overview and java prep held till next mtg.<br /> * java API + doc has been installed on quark<br /> <br /> == Mar 7 ==<br /> <br /> * Toby went over Eclipse basics with us<br /> * We set up a CVS repository on Quark in &lt;code&gt;/clients/groups/bar/cvs/&lt;/code&gt;<br /> ** So far, we're planning on using the repository through Eclipse's interface<br /> * We went over Java basics, and described the Javadoc idea<br /> <br /> *On the boiler plate:<br /> ** Have a discussion and get in writing exactly what our individual jobs entail.<br /> ** Show how Javadoc works<br /> *** Develop our group's commenting style<br /> ** Think about our coding style, especially as regards code formatting<br /> ** CVS plumbing (CVS spam, bugzilla, etc.)</div> Hunteke https://wiki.cs.earlham.edu/index.php?title=SE2006:group_bar:minutes&diff=1346 SE2006:group bar:minutes 2006-03-08T03:29:37Z <p>Hunteke: </p> <hr /> <div>==Feb 15==<br /> <br /> '''Possible meeting time:''' Working M/W/F in the evening for 1 or 2 hours starting the 27th. Toby, Kevin, and I are going to be working this weekend on clustcomp projects and then going to a conference on Feb 22-26.<br /> <br /> *Languages:<br /> **php - most of us are familiar. big libraries. web stuff.<br /> **java with tomcat - web stuff. good development environment.<br /> **python - learn a new language.<br /> **perl - most of us are familiar. less good, but good web stuff.<br /> **ruby - learn a new language. there may be other reasons but we don't know what they are because we don't know ruby.<br /> <br /> *Caching Location data:<br /> **with memcache (http://www.danga.com/memcached/)<br /> **postgres<br /> **mysql<br /> <br /> *Communication<br /> **using a mailing list for now.<br /> **developing new methods as they seem fit (wiki,cvs,bulletin board).<br /> <br /> *Group name:<br /> **kartgoolers.<br /> **cartooglers.<br /> **pwners<br /> **colin's team.<br /> **group-b<br /> **group bar<br /> <br /> *Assignment:<br /> **send us your group name choice to list. we accept write ins. if anyone feels super strong about a name then tell us why.<br /> **submit your leader (self?)nominations.<br /> <br /> <br /> ==Feb 28==<br /> <br /> * We have decided on some of the roles:<br /> ** Aybars: Libarian<br /> ** Alex &amp; ColinC: Developers<br /> ** Tobias: Leader<br /> ** Kevin: Architect<br /> <br /> * We have roughly agreed on meeting Monday, Tuesday and Wednesdays.<br /> <br /> * We have discussed which language to use, and decided that we'll decide on that later after we break the project up a little bit more (possibly tomorrow).<br /> <br /> * Tomorrow we will discuss the documentation.<br /> <br /> * We will look at the lab 2 solutions soon.<br /> <br /> * Error checking?<br /> <br /> <br /> ==Mar 1==<br /> <br /> * We worked on breaking this project into smaller pieces.<br /> <br /> * For database we are going to use SQL and for the rest of the project, we will probably use Java.<br /> <br /> * We will use Javadoc for documentation of the API<br /> <br /> * Next meeting we are going to talk about:<br /> ** Lab 2 solutions<br /> ** Time budgeting<br /> ** Eclipse review<br /> ** Java prep<br /> ** Kevin will bug Skylar about getting Java API installed on Quark.<br /> ** We have two solutions so far on the table<br /> ** We will talk more about documentation<br /> <br /> ==Mar 6==<br /> * we went over our lab 2 solutions:<br /> &lt;blockquote&gt;<br /> We compared three of our Kerasotes lab scripts. We apparently all wrote them in PHP. The best innovations we found were Toby's data point definition abstraction and test suite. In essence, the data point definition abstraction allows one to describe a data source and data points that one would like to harvest in a general manner. The test suite is a basis for more general testing of the software that we will write. Also of note, were some of our findings as far as regular expressions. For instance, as a group we learned how to make a regular expression not greedy and how to not save a group (?).<br /> &lt;/blockquote&gt;<br /> <br /> &lt;blockquote&gt;<br /> Attached you will find an image of our general model thus far. We have already incorporated some of the ideas discussed in this session, including a more general data point abstraction and streamlined data flow between the programmer API, database, and WUI. As part of our plan, we intend to use Java as the base language, XML for temporary data storage and transfer, PostgreSQL or MySQL for data storage, and XHTML Transitional and JavaScript for the WUI.<br /> &lt;/blockquote&gt;<br /> * eclipse overview and java prep held till next mtg.<br /> * java API + doc has been installed on quark<br /> <br /> == Mar 7 ==<br /> <br /> * Toby went over Eclipse basics with us<br /> * We set up a CVS repository on Quark in &lt;code&gt;/clients/groups/bar/cvs/&lt;/code&gt;<br /> * So far, we're planning on using the repository through Eclipse's interface<br /> * We went over Java basics, and described the Javadoc idea<br /> <br /> *On the boiler plate:<br /> ** Have a discussion and get in writing exactly what our individual jobs entail.<br /> ** Show how Javadoc works<br /> *** Develop our group's commenting style<br /> ** Think about our coding style, especially as regards code formatting<br /> ** CVS plumbing (CVS spam, bugzilla, etc.)</div> Hunteke https://wiki.cs.earlham.edu/index.php?title=SE2006:group_bar:minutes&diff=1345 SE2006:group bar:minutes 2006-03-08T03:27:51Z <p>Hunteke: March 7th</p> <hr /> <div>==Feb 15==<br /> <br /> '''Possible meeting time:''' Working M/W/F in the evening for 1 or 2 hours starting the 27th. Toby, Kevin, and I are going to be working this weekend on clustcomp projects and then going to a conference on Feb 22-26.<br /> <br /> *Languages:<br /> **php - most of us are familiar. big libraries. web stuff.<br /> **java with tomcat - web stuff. good development environment.<br /> **python - learn a new language.<br /> **perl - most of us are familiar. less good, but good web stuff.<br /> **ruby - learn a new language. there may be other reasons but we don't know what they are because we don't know ruby.<br /> <br /> *Caching Location data:<br /> **with memcache (http://www.danga.com/memcached/)<br /> **postgres<br /> **mysql<br /> <br /> *Communication<br /> **using a mailing list for now.<br /> **developing new methods as they seem fit (wiki,cvs,bulletin board).<br /> <br /> *Group name:<br /> **kartgoolers.<br /> **cartooglers.<br /> **pwners<br /> **colin's team.<br /> **group-b<br /> **group bar<br /> <br /> *Assignment:<br /> **send us your group name choice to list. we accept write ins. if anyone feels super strong about a name then tell us why.<br /> **submit your leader (self?)nominations.<br /> <br /> <br /> ==Feb 28==<br /> <br /> * We have decided on some of the roles:<br /> ** Aybars: Libarian<br /> ** Alex &amp; ColinC: Developers<br /> ** Tobias: Leader<br /> ** Kevin: Architect<br /> <br /> * We have roughly agreed on meeting Monday, Tuesday and Wednesdays.<br /> <br /> * We have discussed which language to use, and decided that we'll decide on that later after we break the project up a little bit more (possibly tomorrow).<br /> <br /> * Tomorrow we will discuss the documentation.<br /> <br /> * We will look at the lab 2 solutions soon.<br /> <br /> * Error checking?<br /> <br /> <br /> ==Mar 1==<br /> <br /> * We worked on breaking this project into smaller pieces.<br /> <br /> * For database we are going to use SQL and for the rest of the project, we will probably use Java.<br /> <br /> * We will use Javadoc for documentation of the API<br /> <br /> * Next meeting we are going to talk about:<br /> ** Lab 2 solutions<br /> ** Time budgeting<br /> ** Eclipse review<br /> ** Java prep<br /> ** Kevin will bug Skylar about getting Java API installed on Quark.<br /> ** We have two solutions so far on the table<br /> ** We will talk more about documentation<br /> <br /> ==Mar 6==<br /> * we went over our lab 2 solutions:<br /> &lt;blockquote&gt;<br /> We compared three of our Kerasotes lab scripts. We apparently all wrote them in PHP. The best innovations we found were Toby's data point definition abstraction and test suite. In essence, the data point definition abstraction allows one to describe a data source and data points that one would like to harvest in a general manner. The test suite is a basis for more general testing of the software that we will write. Also of note, were some of our findings as far as regular expressions. For instance, as a group we learned how to make a regular expression not greedy and how to not save a group (?).<br /> &lt;/blockquote&gt;<br /> <br /> &lt;blockquote&gt;<br /> Attached you will find an image of our general model thus far. We have already incorporated some of the ideas discussed in this session, including a more general data point abstraction and streamlined data flow between the programmer API, database, and WUI. As part of our plan, we intend to use Java as the base language, XML for temporary data storage and transfer, PostgreSQL or MySQL for data storage, and XHTML Transitional and JavaScript for the WUI.<br /> &lt;/blockquote&gt;<br /> * eclipse overview and java prep held till next mtg.<br /> * java API + doc has been installed on quark<br /> <br /> == Mar 7 ==<br /> <br /> * Toby went over Eclipse basics with us<br /> * We set up a CVS repository on Quark in<br /> /clients/groups/bar/cvs/<br /> ** So far, we're planning on using the repository through Eclipse's interface<br /> * We went over Java basics, and described the Javadoc idea<br /> <br /> *On the boiler plate:<br /> ** Have a discussion and get in writing exactly what our individual jobs entail.<br /> ** Show how Javadoc works<br /> *** Develop our group's commenting style<br /> ** Think about our coding style, especially as regards code formatting<br /> ** CVS plumbing (CVS spam, bugzilla, etc.)</div> Hunteke https://wiki.cs.earlham.edu/index.php?title=BCCD:Log&diff=1306 BCCD:Log 2006-02-12T04:04:52Z <p>Hunteke: </p> <hr /> <div>=== 2006-01-18 ===<br /> <br /> * I've got both the Dell and the bazaar node PXE booting off hopper. I can get to a Busybox prompt but no further though. The problem is that the kernel that the BCCD uses provides no NIC support until after the modules are loaded from singularity. The problem is that we need to load singularity over the network (NFS probably), but that's a chicken-and-the-egg problem.<br /> <br /> === 2006-02-01 ===<br /> <br /> * Changing /linuxrc in root.bin to mount NFS, and then call pivot_root to change the current root filesystem from initrd to admin:/singularity (over NFS).<br /> <br /> * We decided initrd is not needed. We took it out, and are no worse off than we were before.<br /> <br /> * inittab's agetty entries are failing because devfsd is silently failing.<br /> <br /> * Disabled /etc/init.d/net* because networking support is already included in the kernel.<br /> <br /> === 2006-02-02 ===<br /> * Need to test run environments.<br /> * Errors appear, but are not important.<br /> <br /> === 2006-02-09 ===<br /> * Started using qemu<br /> ** had to enable tun/tap in kernel<br /> ** installed qemu 0.8.0 and associated kqemu on acl13<br /> ** qemu -hda skylar.img -cdrom bccd.iso -boot d -net nic,vlan=1 -net tap,vlan=1<br /> <br /> -hda &lt;image name&gt; says to use this file as a hard drive.<br /> -cdrom &lt;file name&gt; says to use this file as a cdrom drive. bonus if the file is already a cd (image)<br /> -boot &lt;bios device&gt; says to boot from this device<br /> -net [options] is how to initialize options within qemu<br /> - nic,vlan=1 says to create a network interface card for guest system, and create vlan with id 1<br /> - tap,vlan=1 says to associate tapX with vlan id 1<br /> <br /> Also looked at UserModeLinux, but having troubles compiling the kernel.<br /> <br /> === 2006-02-11 ===<br /> <br /> We've got User-mode-linux booting, although we're still stuck on making it a usable boot. At this point, qemu is still an option because it presents a packaged solution: with UML, we've got the kernel at boot time, which is not /exactly/ what happens when booting from the cd.</div> Hunteke https://wiki.cs.earlham.edu/index.php?title=BCCD:Log&diff=1298 BCCD:Log 2006-02-09T09:45:20Z <p>Hunteke: </p> <hr /> <div>=== 2006-01-18 ===<br /> <br /> * I've got both the Dell and the bazaar node PXE booting off hopper. I can get to a Busybox prompt but no further though. The problem is that the kernel that the BCCD uses provides no NIC support until after the modules are loaded from singularity. The problem is that we need to load singularity over the network (NFS probably), but that's a chicken-and-the-egg problem.<br /> <br /> === 2006-02-01 ===<br /> <br /> * Changing /linuxrc in root.bin to mount NFS, and then call pivot_root to change the current root filesystem from initrd to admin:/singularity (over NFS).<br /> <br /> * We decided initrd is not needed. We took it out, and are no worse off than we were before.<br /> <br /> * inittab's agetty entries are failing because devfsd is silently failing.<br /> <br /> * Disabled /etc/init.d/net* because networking support is already included in the kernel.<br /> <br /> === 2006-02-02 ===<br /> * Need to test run environments.<br /> * Errors appear, but are not important.<br /> <br /> === 2006-02-09 ===<br /> * Started using qemu<br /> ** had to enable tun/tap in kernel<br /> ** installed qemu 0.8.0 and associated kqemu on acl13<br /> ** qemu -hda skylar.img -cdrom bccd.iso -boot d -net nic,vlan=1 -net tap,vlan=1<br /> <br /> -hda &lt;image name&gt; says to use this file as a hard drive.<br /> -cdrom &lt;file name&gt; says to use this file as a cdrom drive. bonus if the file is already a cd (image)<br /> -boot &lt;bios device&gt; says to boot from this device<br /> -net [options] is how to initialize options within qemu<br /> - nic,vlan=1 says to create a network interface card for guest system, and create vlan with id 1<br /> - tap,vlan=1 says to associate tapX with vlan id 1<br /> <br /> Also looked at UserModeLinux, but having troubles compiling the kernel.</div> Hunteke https://wiki.cs.earlham.edu/index.php?title=BCCD:Log&diff=1294 BCCD:Log 2006-02-09T09:43:19Z <p>Hunteke: /* 2006-02-09 */</p> <hr /> <div>=== 2006-01-18 ===<br /> <br /> * I've got both the Dell and the bazaar node PXE booting off hopper. I can get to a Busybox prompt but no further though. The problem is that the kernel that the BCCD uses provides no NIC support until after the modules are loaded from singularity. The problem is that we need to load singularity over the network (NFS probably), but that's a chicken-and-the-egg problem.<br /> <br /> === 2006-02-01 ===<br /> <br /> * Changing /linuxrc in root.bin to mount NFS, and then call pivot_root to change the current root filesystem from initrd to admin:/singularity (over NFS).<br /> <br /> * We decided initrd is not needed. We took it out, and are no worse off than we were before.<br /> <br /> * inittab's agetty entries are failing because devfsd is silently failing.<br /> <br /> * Disabled /etc/init.d/net* because networking support is already included in the kernel.<br /> <br /> === 2006-02-02 ===<br /> * Need to test run environments.<br /> * Errors appear, but are not important.<br /> <br /> === 2006-02-09 ===<br /> * Started using qemu<br /> ** had to enable tun/tap in kernel<br /> ** installed qemu 0.8.0 and associated kqemu on acl13<br /> ** qemu -hda skylar.img -cdrom bccd.iso -boot d -net nic,vlan=1 -net tap,vlan=1<br /> <br /> - -hda &lt;image name&gt; says to use this file as a hard drive.<br /> - -cdrom &lt;file name&gt; says to use this file as a cdrom drive. bonus if the file is already a cd (image)<br /> - -boot &lt;bios device&gt; says to boot from this device<br /> - -net [options] is how to initialize options within qemu<br /> - nic,vlan=1 says to create a network interface card for guest system, and create vlan with id 1<br /> - tap,vlan=1 says to associate tapX with vlan id 1<br /> <br /> Also looked at UserModeLinux, but having troubles compiling the kernel.</div> Hunteke https://wiki.cs.earlham.edu/index.php?title=BCCD:Log&diff=1293 BCCD:Log 2006-02-09T09:42:20Z <p>Hunteke: working on BCCD server edition</p> <hr /> <div>=== 2006-01-18 ===<br /> <br /> * I've got both the Dell and the bazaar node PXE booting off hopper. I can get to a Busybox prompt but no further though. The problem is that the kernel that the BCCD uses provides no NIC support until after the modules are loaded from singularity. The problem is that we need to load singularity over the network (NFS probably), but that's a chicken-and-the-egg problem.<br /> <br /> === 2006-02-01 ===<br /> <br /> * Changing /linuxrc in root.bin to mount NFS, and then call pivot_root to change the current root filesystem from initrd to admin:/singularity (over NFS).<br /> <br /> * We decided initrd is not needed. We took it out, and are no worse off than we were before.<br /> <br /> * inittab's agetty entries are failing because devfsd is silently failing.<br /> <br /> * Disabled /etc/init.d/net* because networking support is already included in the kernel.<br /> <br /> === 2006-02-02 ===<br /> * Need to test run environments.<br /> * Errors appear, but are not important.<br /> <br /> === 2006-02-09 ===<br /> * Started using qemu<br /> ** had to enable tun/tap in kernel<br /> ** installed qemu 0.8.0 and associated kqemu on acl13<br /> ** qemu -hda skylar.img -cdrom bccd.iso -boot d -net nic,vlan=1 -net tap,vlan=1<br /> <br /> -hda &lt;image name&gt; says to use this file as a hard drive.<br /> -cdrom &lt;file name&gt; says to use this file as a cdrom drive. bonus if the file is already a cd (image)<br /> -boot &lt;bios device&gt; says to boot from this device<br /> -net [options] is how to initialize options within qemu<br /> - nic,vlan=1 says to create a network interface card for guest system, and create vlan with id 1<br /> - tap,vlan=1 says to associate tapX with vlan id 1<br /> <br /> Also looked at UserModeLinux, but having troubles compiling the kernel.</div> Hunteke https://wiki.cs.earlham.edu/index.php?title=Kevin_SS_WeeklyJournal2005&diff=5426 Kevin SS WeeklyJournal2005 2005-11-16T05:40:59Z <p>Hunteke: minor edit, plus 9-16 Nov</p> <hr /> <div>Kevin's Weekly Journals for Senior Seminar 2005<br /> <br /> ==31 Aug - 07 Sep==<br /> <br /> My capstone is currently sitting in my mind, looking like a fearsome thing. I was supposed to have an abstract ready this week, but I did not know on what I could write. I would like to do something in terms of User Interface and design, but I'm not sure that this would be untrod ground. Obviously, I'm only an undergraduate student, so I'm not expecting to do PHd research, but I get the sense that my capstone should be at least somewhat original. Perhaps, since I have an interest in operating systems, I can think about doing something with [http://www.reactos.org/ ReactOS].<br /> <br /> ==07 Sep - 14 Sep==<br /> <br /> My main work this week has been cognition. I'm jealous of some of my peers who have ideas already. I'm completely at a loss. I know that if I ask Charlie, his canned response will be &quot;Well, what's your itch?&quot; I've got nails, but nothing to itch, that's the problem. I've come up with a project that I think would be entirely cool, but I'm not sure how to create it. It's [[Teaching Language, The|The Teaching Language]]. Unfortunately, I'm not exactly sure how to implement it. I've never written a langauge before. I'm kind of thinking of something similar to HTML and CSS, but in the context of objects as opposed to text. I'm not initially sure how to go about this. The language creation will probably come second as I'm going to have to research how to describe these objects in my own mind first. I ''really'' want them to be manipulatable, so the complexity is ginormous. If I can get past that the first hurdle ... man! I'm so psyched.<br /> <br /> ==14 Sep - 21 Sep==<br /> <br /> Even as I was writing [[Teaching Language, The|The Teaching Language]] abstract last week, I knew that I didn't (don't) have the background to complete such a project in one semester. However, the ideas are there: I just need to focus them. I think I've decided on the direction that has already proven to have some merit: CSLets. I [[Initial_Abstract|mentioned]] them in the context of not knowing exactly where I wanted to go, but I think that they might prove the best direction. I'm currently cogitating about ideas for CSLets.<br /> <br /> ==21 Sep - 28 Sep==<br /> <br /> I spent the majority of this week brainstorming about tools that I would like to create. I seem to be having delusions of grandeur though, because a lot of the CSlets that I might want to create are probably just a bit beyond my current capabilities (or at least time scope). One CSlet that is worming its way through my mind is the C-string Let that I [[New_Direction,_A|mentioned last week]]. I started trying to write it, but I found, in the midst of working on a consistent interface for the user, that I have more of a desire for a visual memory manager. I'm not entirely sure of the structure, but this has implications of extensability, much more so than the C-string Let idea. For one thing, if I do it right, the C-string Let could sit on top of this. Thinking continues ...<br /> <br /> ==28 Sep - 05 Oct==<br /> <br /> A teacher once told me that the best way to tackle problems is to draw a picture. True to form, I have drawn a picture [[Image:memsketch.png|thumb|Visual Memory Manager sketch]] of my initial ideas regarding a memory manager. What I'm thinking is that users can click on the buttons in the lower left hand part of the screen to create and access variables. The contents would be displayed in the gray bar on the bottom, as well as the location &quot;physically&quot; identified by the purple circle. The idea of this program is to represent the memory in a visual manner that is accessible to new students. Ideally this would be something with which students could at first rotely interact, but then also find other uses for it such helping to visualize problems they will encounter as they continue in CS. Thought it is still not complete, -- I haven't thought entirely through how I'm going to deal with some of the details of implementation -- I'm kind of excited.<br /> <br /> ==05 Oct - 12 Oct==<br /> <br /> In the meeting last week, it became apparent that Tom and I are working on projects of an extremely similar nature. It was clear that we should work together, especially as we both have hopes that our code gets used and is extensible. Charlie pointed out that the easiest way to make something extensible is to write it to conform with two different ideas (in so many words ...).<br /> <br /> To this end, I started to write the implentation behind my Visual Memory Manager Let. I got lost in some of the implementation details, however. Tom and I found some time to talk about how we might make some headway. We came up with some great ideas.<br /> <br /> For extensability, we are still thinking in terms of modules and packages, but our scope suddenly has some wider prospects. Currently, it looks like we're going to make a Memory Manager and then make modules that lie on top of that. One of Tom's project ideas is to teach data structures in a visual manner. One of my project ideas is to (partially) demystify the workings of the memory. My current drive is to create a memory system that can be interfaced via an API. Then Tom can write his program to conform to the API: at the same time his module is demonstrating a data stucture concept, my program can show ''exactly'' what is happening behind the scenes.<br /> <br /> ==12 Oct - 19 Oct==<br /> <br /> This past week was hampered by Fall Break, but I did manage to change the code that I had written to begin to conform to what Tom and I talked about in our meeting last week. A personal failing that I'm having is an inability to ''step back from the code''. I'm still having some problems with the implementation, and I think it's because I haven't completely thought out the structure to which I want to conform. But, as the old adage goes, &quot;Time stops for no man;&quot; so I'd better hurry up and get my head in gear.<br /> <br /> In other news, I have read some of the [http://www.cc.gatech.edu/gvu/people/Faculty/Mark.Guzdial.html website] provided by Alex (Thank you!). Mark Guzdial has done some interesting work, but it is not quite the same avenue that Tom and I are wishing to explore. Guzdial's work is centered around bringing out the things that can be done with a computer and making it accessible. The main thrust of what I read is about using computers to play with different multimedia (pictures, movies). A couple of examples include his explainations of how to manipulate images with some python programs, and how Disney did/does some of its digital animation. A fun read, with some real output potential for people who don't want to be deeply involved in CS. However, not for Tom or myself.<br /> <br /> ==19 Oct - 21 Oct==<br /> <br /> SUCCESS!!! I completed the underlying MemoryManager class code! Gotta say that at this point, it looks like I was doing just fine in my struggles last week. The inability to ''step back from the code'' proved a good thing as I was much more facile with what I had created. I've written the basic MemoryManager class, as well as &lt;code&gt;Variable&lt;/code&gt; class that inherits from it. On top of that &lt;code&gt;Variable&lt;/code&gt; class I've written a two extensions: &lt;code&gt;VariableInt&lt;/code&gt; and &lt;code&gt;VariableChar&lt;/code&gt;. Since I'm taking somewhat of a C approach to the process, I felt it also necessary to write a &lt;code&gt;VariablePointer&lt;/code&gt; classs. This class has shown me some errors in logic in my other two classes, and some functions that I needed to write in my base classes. In other words, I'm still working on the &lt;code&gt;VariablePointer&lt;/code&gt; class.<br /> <br /> ==21 Oct - 28 Oct==<br /> <br /> The &lt;code&gt;VariablePointer&lt;/code&gt; finally fell into place last night. The key was that I realized that having pointers is an integral decision to a &quot;language&quot; &amp;ndash; meaning that every class that is written must have support for pointers. I had to add a couple of functions into each of the other &lt;code&gt;Variable&lt;/code&gt; extension classes, but so far, things are looking great. I'm to a point now where I'm think I'm ready to start working on a GUI to look at the memory in a visual manner. So far it's all been in my head. (What a mind job!)<br /> <br /> ==28 Oct - 02 Nov==<br /> <br /> Tom and I are struggling with how to combine our projects. Neither has quite the experience in Java to immediately know how they are going to mesh. We have an inkling of inheritance, but we haven't actually gotten it to work yet. Tom is still fervently working on the GUI side of his project, and hasn't had much time to work developing an ADT. Since he has been working with a stack as his test case, I decided to go ahead and implement a stack.<br /> <br /> This has proven harder than I was expecting because I had forgotten about all of the niceties given to one by the language in which they're working. More importantly however, we had a part of our paper due today. I had to turn my attention to solidifying what I'd been reading. This was especially hard and time consuming because I haven't been doing the best at keeping track of what I've been reading where. (A little bit lack of focus early on in the semester coupled with a sense of complacency because nothing was immediately due. Whoops!) Luckily I had some browser history that I could peruse to find what I had missed.<br /> <br /> ==02 Nov - 09 Nov==<br /> <br /> I completed the Stack class on Friday. The trick was to decide how to implement it. I haven't implemented array functionality yet, so I thought that I would create a pointer based stack. This led way to extending the VariablePointerClass. Once I did this, some things fell into place, but not everything. The gist of what I was missing was that, again, I was thinking that things would just &quot;take care of themselves.&quot; Not so. Since I'm writing this memory, if I haven't told it do something, it isn't going to do it. Basically, I'm getting a new found respect for the memory issues with which the old timers had to deal.<br /> <br /> At some point while I was working on the &lt;code&gt;VariablePointerClass&lt;/code&gt; code, I realized that I should probably start storing class Variables in the memory as well. However, at this early developmental stage I'm not going to worry about it. The storage and access functionality will be the same, so it should be a minor change later. For now, I'm more worried about making sure that what I've got going on is correct. I want to get something working and on screen first. However, before that can get started, I need to make sure that Tom's project can actually use mine. I started looking at that on Sunday morning.<br /> <br /> Looking for how to do it brought me to the notion of libraries, or, in Java-speak, packages. They aren't difficult in concept, but it took me 3 hours to nail down just how to do it. The gist is this:<br /> <br /> If you want to make a class (file) part of a package, you must put<br /> <br /> &lt;code&gt;package packageName;&lt;/code&gt;<br /> <br /> at the head of your file. That was easy. The difficult part came in getting the compiler to compile the different parts of my program as part of the package. The problem was the directory structure and ''place of invocation'' of the compiler. How the Java compiler interprets the &lt;code&gt;package&lt;/code&gt; statement is as a directory structure. The above would mean that from ''where the compiler'' is invoked, there should be a subdirectory named &quot;packageName&quot; that contains all the files. So, if I had my java files A.java, B.java, and C.java, and I wanted to put them in the edu.earlham.cs.Graphics package I would add this to the very beginning of each file (excluding comments, it must be the ''first'' line):<br /> <br /> &lt;code&gt;package edu.earlham.cs.Graphics;&lt;/code&gt;<br /> <br /> Then, you would need to create a directory structure that matched that package line. (The '.' character delineates a subdirectory.) I would need to find somewhere to create the structure and copy the files into it. On Windows and *nix:<br /> <br /> Windows:<br /> <br /> &lt;code&gt;C:\Documents and Settings\Kevin\My Documents\Classes\SeniorSem\7dGraphics\&gt;md edu\earlham\cs\7dGraphics&lt;br /&gt;&lt;br /&gt;<br /> C:\Documents and Settings\Kevin\My Documents\Classes\SeniorSem\7dGraphics\&gt;copy *.java edu\earlham\cs\7dGraphics&lt;br /&gt;&lt;br /&gt;<br /> C:\Documents and Settings\Kevin\My Documents\Classes\SeniorSem\7dGraphics\&gt;&lt;/code&gt;<br /> <br /> *nix:<br /> <br /> &lt;code&gt;~/class/seniorsem/7dGraphics/&lt;br /&gt;<br /> $: mkdir edu/earlham/cs/7dGraphics&lt;br /&gt;&lt;br /&gt;<br /> ~/class/seniorsem/7dGraphics/&lt;br /&gt;<br /> $: cp *.java edu/earlham/cs/7dGraphics&lt;br /&gt;&lt;br /&gt;<br /> ~/class/seniorsem/7dGraphics/&lt;br /&gt;<br /> $:&lt;/code&gt;<br /> <br /> The trick is ''to compile from here'', not in the subdirectory like you might think:<br /> <br /> &lt;code&gt;~/class/seniorsem/7dGraphics/&lt;br /&gt;<br /> $: javac edu/earlham/cs/7dGraphics/Visualizer.java&lt;br /&gt;&lt;br /&gt;<br /> ~/class/seniorsem/7dGraphics/&lt;br /&gt;<br /> $:&lt;/code&gt;<br /> <br /> ==09 Nov - 16 Nov==<br /> <br /> This week has been stale as nothing ''new'' has surfaced. There was some good success with Tom on the 10th (Thursday) as I rewrote/reorganized a major portion of his and my code to finally make the two projects work together. Since that's done, I'm letting myself think more about the visual aspect of ''my'' project. I spent the major portion of this past week working on my code and am thinking about how to organize the visual layout of the Memory Viewer. (Actually, I've named it MemoryWatcher, but I'm not fully settled on that name. Inconsequential, I know.) I'm mostly struggling now with Java and the visual components, trying to give myself places on which to draw. (It's frustrating to receive a NullPointerException when Java supposedly has no pointers. It's not true of course, Java just tries to hide them, but it's still funny.) And finally, the presentation has been looming. I'm still working on it as I write this log entry. We'll see how it goes tomorrow.</div> Hunteke https://wiki.cs.earlham.edu/index.php?title=Kevin_SS_WeeklyJournal2005&diff=917 Kevin SS WeeklyJournal2005 2005-11-06T09:42:16Z <p>Hunteke: /* 02 Nov - 09 Nov */</p> <hr /> <div>Kevin's Weekly Journals for Senior Seminar 2005<br /> <br /> ==31 Aug - 07 Sep==<br /> <br /> My capstone is currently sitting in my mind, looking like a fearsome thing. I was supposed to have an abstract ready this week, but I did not know on what I could write. I would like to do something in terms of User Interface and design, but I'm not sure that this would be untrod ground. Obviously, I'm only an undergraduate student, so I'm not expecting to do PHd research, but I get the sense that my capstone should be at least somewhat original. Perhaps, since I have an interest in operating systems, I can think about doing something with [http://www.reactos.org/ ReactOS].<br /> <br /> ==07 Sep - 14 Sep==<br /> <br /> My main work this week has been cognition. I'm jealous of some of my peers who have ideas already. I'm completely at a loss. I know that if I ask Charlie, his canned response will be &quot;Well, what's your itch?&quot; I've got nails, but nothing to itch, that's the problem. I've come up with a project that I think would be entirely cool, but I'm not sure how to create it. It's [[Teaching Language, The|The Teaching Language]]. Unfortunately, I'm not exactly sure how to implement it. I've never written a langauge before. I'm kind of thinking of something similar to HTML and CSS, but in the context of objects as opposed to text. I'm not initially sure how to go about this. The language creation will probably come second as I'm going to have to research how to describe these objects in my own mind first. I ''really'' want them to be manipulatable, so the complexity is ginormous. If I can get past that the first hurdle ... man! I'm so psyched.<br /> <br /> ==14 Sep - 21 Sep==<br /> <br /> Even as I was writing [[Teaching Language, The|The Teaching Language]] abstract last week, I knew that I didn't (don't) have the background to complete such a project in one semester. However, the ideas are there: I just need to focus them. I think I've decided on the direction that has already proven to have some merit: CSLets. I [[Initial_Abstract|mentioned]] them in the context of not knowing exactly where I wanted to go, but I think that they might prove the best direction. I'm currently cogitating about ideas for CSLets.<br /> <br /> ==21 Sep - 28 Sep==<br /> <br /> I spent the majority of this week brainstorming about tools that I would like to create. I seem to be having delusions of grandeur though, because a lot of the CSlets that I might want to create are probably just a bit beyond my current capabilities (or at least time scope). One CSlet that is worming its way through my mind is the C-string Let that I [[New_Direction,_A|mentioned last week]]. I started trying to write it, but I found, in the midst of working on a consistent interface for the user, that I have more of a desire for a visual memory manager. I'm not entirely sure of the structure, but this has implications of extensability, much more so than the C-string Let idea. For one thing, if I do it right, the C-string Let could sit on top of this. Thinking continues ...<br /> <br /> ==28 Sep - 05 Oct==<br /> <br /> A teacher once told me that the best way to tackle problems is to draw a picture. True to form, I have drawn a picture [[Image:memsketch.png|thumb|Visual Memory Manager sketch]] of my initial ideas regarding a memory manager. What I'm thinking is that users can click on the buttons in the lower left hand part of the screen to create and access variables. The contents would be displayed in the gray bar on the bottom, as well as the location &quot;physically&quot; identified by the purple circle. The idea of this program is to represent the memory in a visual manner that is accessible to new students. Ideally this would be something with which students could at first rotely interact, but then also find other uses for it such helping to visualize problems they will encounter as they continue in CS. Thought it is still not complete, -- I haven't thought entirely through how I'm going to deal with some of the details of implementation -- I'm kind of excited.<br /> <br /> ==05 Oct - 12 Oct==<br /> <br /> In the meeting last week, it became apparent that Tom and I are working on projects of an extremely similar nature. It was clear that we should work together, especially as we both have hopes that our code gets used and is extensible. Charlie pointed out that the easiest way to make something extensible is to write it to conform with two different ideas (in so many words ...).<br /> <br /> To this end, I started to write the implentation behind my Visual Memory Manager Let. I got lost in some of the implementation details, however. Tom and I found some time to talk about how we might make some headway. We came up with some great ideas.<br /> <br /> For extensability, we are still thinking in terms of modules and packages, but our scope suddenly has some wider prospects. Currently, it looks like we're going to make a Memory Manager and then make modules that lie on top of that. One of Tom's project ideas is to teach data structures in a visual manner. One of my project ideas is to (partially) demystify the workings of the memory. My current drive is to create a memory system that can be interfaced via an API. Then Tom can write his program to conform to the API: at the same time his module is demonstrating a data stucture concept, my program can show ''exactly'' what is happening behind the scenes.<br /> <br /> ==12 Oct - 19 Oct==<br /> <br /> This past week was hampered by Fall Break, but I did manage to change the code that I had written to begin to conform to what Tom and I talked about in our meeting last week. A personal failing that I'm having is an inability to ''step back from the code''. I'm still having some problems with the implementation, and I think it's because I haven't completely thought out the structure to which I want to conform. But, as the old adage goes, &quot;Time stops for no man;&quot; so I'd better hurry up and get my head in gear.<br /> <br /> In other news, I have read some of the [http://www.cc.gatech.edu/gvu/people/Faculty/Mark.Guzdial.html website] provided by Alex (Thank you!). Mark Guzdial has done some interesting work, but it is not quite the same avenue that Tom and I are wishing to explore. Guzdial's work is centered around bringing out the things that can be done with a computer and making it accessible. The main thrust of what I read is about using computers to play with different multimedia (pictures, movies). A couple of examples include his explainations of how to manipulate images with some python programs, and how Disney did/does some of its digital animation. A fun read, with some real output potential for people who don't want to be deeply involved in CS. However, not for Tom or myself.<br /> <br /> ==19 Oct - 21 Oct==<br /> <br /> SUCCESS!!! I completed the underlying MemoryManager class code! Gotta say that at this point, it looks like I was doing just fine in my struggles last week. The inability to ''step back from the code'' proved a good thing as I was much more facile with what I had created. I've written the basic MemoryManager class, as well as &lt;code&gt;Variable&lt;/code&gt; class that inherits from it. On top of that &lt;code&gt;Variable&lt;/code&gt; class I've written a two extensions: &lt;code&gt;VariableInt&lt;/code&gt; and &lt;code&gt;VariableChar&lt;/code&gt;. Since I'm taking somewhat of a C approach to the process, I felt it also necessary to write a &lt;code&gt;VariablePointer&lt;/code&gt; classs. This class has shown me some errors in logic in my other two classes, and some functions that I needed to write in my base classes. In other words, I'm still working on the &lt;code&gt;VariablePointer&lt;/code&gt; class.<br /> <br /> ==21 Oct - 28 Oct==<br /> <br /> The &lt;code&gt;VariablePointer&lt;/code&gt; finally fell into place last night. The key was that I realized that having pointers is an integral decision to a &quot;language&quot; &amp;ndash; meaning that every class that is written must have support for pointers. I had to add a couple of functions into each of the other &lt;code&gt;Variable&lt;/code&gt; extension classes, but so far, things are looking great. I'm to a point now where I'm think I'm ready to start working on a GUI to look at the memory in a visual manner. So far it's all been in my head. (What a mind job!)<br /> <br /> ==28 Oct - 02 Nov==<br /> <br /> Tom and I are struggling with how to combine our projects. Neither has quite the experience in Java to immediately know how they are going to mesh. We have an inkling of inheritance, but we haven't actually gotten it to work yet. Tom is still fervently working on the GUI side of his project, and hasn't had much time to work developing an ADT. Since he has been working with a stack as his test case, I decided to go ahead and implement a stack.<br /> <br /> This has proven harder than I was expecting because I had forgotten about all of the niceties given to one by the language in which they're working. More importantly however, we had a part of our paper due today. I had to turn my attention to solidifying what I'd been reading. This was especially hard and time consuming because I haven't been doing the best at keeping track of what I've been reading where. (A little bit lack of focus early on in the semester coupled with a sense of complacency because nothing was immediately due. Whoops!) Luckily I had some browser history that I could peruse to find what I had missed.<br /> <br /> ==02 Nov - 09 Nov==<br /> <br /> I completed the Stack class on Friday. The trick was to decide how to implement it. I haven't implemented array functionality yet, so I thought that I would create a pointer based stack. This led way to extending the VariablePointerClass. Once I did this, some things fell into place, but not everything. The gist of what I was missing was that, again, I was thinking that things would just &quot;take care of themselves.&quot; Not so. Since I'm writing this memory, if I haven't told it do something, it isn't going to do it. Basically, I'm getting a new found respect for the memory issues with which the old timers had to deal.<br /> <br /> At some point while I was working on the &lt;code&gt;VariablePointerClass&lt;/code&gt; code, I realized that I should probably start storing class Variables in the memory as well. However, at this early developmental stage I'm not going to worry about it. The storage an access functionality will be the same, so it should be a minor change later. For now, I make sure what I've got going on is correct. I want to get something working and on screen first. However, before that can get started, I need to make sure that Tom's project can actually use mine. I started looking at that on Sunday morning.<br /> <br /> Looking for how to do it brought me to the notion of libraries, or, in Java-speak, packages. They aren't difficult in concept, but it took me 3 hours to nail down just how to do it. The gist is this:<br /> <br /> If you want to make a class (file) part of a package, you must put<br /> <br /> &lt;code&gt;package packageName;&lt;/code&gt;<br /> <br /> at the head of your file. That was easy. The difficult part came in getting the compiler to compile the different parts of my program as part of the package. The problem was the directory structure and ''place of invocation'' of the compiler. How the Java compiler interprets the &lt;code&gt;package&lt;/code&gt; statement is as a directory structure. The above would mean that from ''where the compiler'' is invoked, there should be a subdirectory named &quot;packageName&quot; that contains all the files. So, if I had my java files A.java, B.java, and C.java, and I wanted to put them in the edu.earlham.cs.Graphics package I would add this to the very beginning of each file (excluding comments, it must be the ''first'' line):<br /> <br /> &lt;code&gt;package edu.earlham.cs.Graphics;&lt;/code&gt;<br /> <br /> Then, you would need to create a directory structure that matched that package line. (The '.' character delineates a subdirectory.) I would need to find somewhere to create the structure and copy the files into it. On Windows and *nix:<br /> <br /> Windows:<br /> <br /> &lt;code&gt;C:\Documents and Settings\Kevin\My Documents\Classes\SeniorSem\7dGraphics\&gt;md edu\earlham\cs\7dGraphics&lt;br /&gt;&lt;br /&gt;<br /> C:\Documents and Settings\Kevin\My Documents\Classes\SeniorSem\7dGraphics\&gt;copy *.java edu\earlham\cs\7dGraphics&lt;br /&gt;&lt;br /&gt;<br /> C:\Documents and Settings\Kevin\My Documents\Classes\SeniorSem\7dGraphics\&gt;&lt;/code&gt;<br /> <br /> *nix:<br /> <br /> &lt;code&gt;~/class/seniorsem/7dGraphics/&lt;br /&gt;<br /> $: mkdir edu/earlham/cs/7dGraphics&lt;br /&gt;&lt;br /&gt;<br /> ~/class/seniorsem/7dGraphics/&lt;br /&gt;<br /> $: cp *.java edu/earlham/cs/7dGraphics&lt;br /&gt;&lt;br /&gt;<br /> ~/class/seniorsem/7dGraphics/&lt;br /&gt;<br /> $:&lt;/code&gt;<br /> <br /> The trick is ''to compile from here'', not in the subdirectory like you might think:<br /> <br /> &lt;code&gt;~/class/seniorsem/7dGraphics/&lt;br /&gt;<br /> $: javac edu/earlham/cs/7dGraphics/Visualizer.java&lt;br /&gt;&lt;br /&gt;<br /> ~/class/seniorsem/7dGraphics/&lt;br /&gt;<br /> $:&lt;/code&gt;</div> Hunteke https://wiki.cs.earlham.edu/index.php?title=Kevin_SS_WeeklyJournal2005&diff=871 Kevin SS WeeklyJournal2005 2005-11-06T09:36:21Z <p>Hunteke: flushed buffer for three weeks (finally!)</p> <hr /> <div>Kevin's Weekly Journals for Senior Seminar 2005<br /> <br /> ==31 Aug - 07 Sep==<br /> <br /> My capstone is currently sitting in my mind, looking like a fearsome thing. I was supposed to have an abstract ready this week, but I did not know on what I could write. I would like to do something in terms of User Interface and design, but I'm not sure that this would be untrod ground. Obviously, I'm only an undergraduate student, so I'm not expecting to do PHd research, but I get the sense that my capstone should be at least somewhat original. Perhaps, since I have an interest in operating systems, I can think about doing something with [http://www.reactos.org/ ReactOS].<br /> <br /> ==07 Sep - 14 Sep==<br /> <br /> My main work this week has been cognition. I'm jealous of some of my peers who have ideas already. I'm completely at a loss. I know that if I ask Charlie, his canned response will be &quot;Well, what's your itch?&quot; I've got nails, but nothing to itch, that's the problem. I've come up with a project that I think would be entirely cool, but I'm not sure how to create it. It's [[Teaching Language, The|The Teaching Language]]. Unfortunately, I'm not exactly sure how to implement it. I've never written a langauge before. I'm kind of thinking of something similar to HTML and CSS, but in the context of objects as opposed to text. I'm not initially sure how to go about this. The language creation will probably come second as I'm going to have to research how to describe these objects in my own mind first. I ''really'' want them to be manipulatable, so the complexity is ginormous. If I can get past that the first hurdle ... man! I'm so psyched.<br /> <br /> ==14 Sep - 21 Sep==<br /> <br /> Even as I was writing [[Teaching Language, The|The Teaching Language]] abstract last week, I knew that I didn't (don't) have the background to complete such a project in one semester. However, the ideas are there: I just need to focus them. I think I've decided on the direction that has already proven to have some merit: CSLets. I [[Initial_Abstract|mentioned]] them in the context of not knowing exactly where I wanted to go, but I think that they might prove the best direction. I'm currently cogitating about ideas for CSLets.<br /> <br /> ==21 Sep - 28 Sep==<br /> <br /> I spent the majority of this week brainstorming about tools that I would like to create. I seem to be having delusions of grandeur though, because a lot of the CSlets that I might want to create are probably just a bit beyond my current capabilities (or at least time scope). One CSlet that is worming its way through my mind is the C-string Let that I [[New_Direction,_A|mentioned last week]]. I started trying to write it, but I found, in the midst of working on a consistent interface for the user, that I have more of a desire for a visual memory manager. I'm not entirely sure of the structure, but this has implications of extensability, much more so than the C-string Let idea. For one thing, if I do it right, the C-string Let could sit on top of this. Thinking continues ...<br /> <br /> ==28 Sep - 05 Oct==<br /> <br /> A teacher once told me that the best way to tackle problems is to draw a picture. True to form, I have drawn a picture [[Image:memsketch.png|thumb|Visual Memory Manager sketch]] of my initial ideas regarding a memory manager. What I'm thinking is that users can click on the buttons in the lower left hand part of the screen to create and access variables. The contents would be displayed in the gray bar on the bottom, as well as the location &quot;physically&quot; identified by the purple circle. The idea of this program is to represent the memory in a visual manner that is accessible to new students. Ideally this would be something with which students could at first rotely interact, but then also find other uses for it such helping to visualize problems they will encounter as they continue in CS. Thought it is still not complete, -- I haven't thought entirely through how I'm going to deal with some of the details of implementation -- I'm kind of excited.<br /> <br /> ==05 Oct - 12 Oct==<br /> <br /> In the meeting last week, it became apparent that Tom and I are working on projects of an extremely similar nature. It was clear that we should work together, especially as we both have hopes that our code gets used and is extensible. Charlie pointed out that the easiest way to make something extensible is to write it to conform with two different ideas (in so many words ...).<br /> <br /> To this end, I started to write the implentation behind my Visual Memory Manager Let. I got lost in some of the implementation details, however. Tom and I found some time to talk about how we might make some headway. We came up with some great ideas.<br /> <br /> For extensability, we are still thinking in terms of modules and packages, but our scope suddenly has some wider prospects. Currently, it looks like we're going to make a Memory Manager and then make modules that lie on top of that. One of Tom's project ideas is to teach data structures in a visual manner. One of my project ideas is to (partially) demystify the workings of the memory. My current drive is to create a memory system that can be interfaced via an API. Then Tom can write his program to conform to the API: at the same time his module is demonstrating a data stucture concept, my program can show ''exactly'' what is happening behind the scenes.<br /> <br /> ==12 Oct - 19 Oct==<br /> <br /> This past week was hampered by Fall Break, but I did manage to change the code that I had written to begin to conform to what Tom and I talked about in our meeting last week. A personal failing that I'm having is an inability to ''step back from the code''. I'm still having some problems with the implementation, and I think it's because I haven't completely thought out the structure to which I want to conform. But, as the old adage goes, &quot;Time stops for no man;&quot; so I'd better hurry up and get my head in gear.<br /> <br /> In other news, I have read some of the [http://www.cc.gatech.edu/gvu/people/Faculty/Mark.Guzdial.html website] provided by Alex (Thank you!). Mark Guzdial has done some interesting work, but it is not quite the same avenue that Tom and I are wishing to explore. Guzdial's work is centered around bringing out the things that can be done with a computer and making it accessible. The main thrust of what I read is about using computers to play with different multimedia (pictures, movies). A couple of examples include his explainations of how to manipulate images with some python programs, and how Disney did/does some of its digital animation. A fun read, with some real output potential for people who don't want to be deeply involved in CS. However, not for Tom or myself.<br /> <br /> ==19 Oct - 21 Oct==<br /> <br /> SUCCESS!!! I completed the underlying MemoryManager class code! Gotta say that at this point, it looks like I was doing just fine in my struggles last week. The inability to ''step back from the code'' proved a good thing as I was much more facile with what I had created. I've written the basic MemoryManager class, as well as &lt;code&gt;Variable&lt;/code&gt; class that inherits from it. On top of that &lt;code&gt;Variable&lt;/code&gt; class I've written a two extensions: &lt;code&gt;VariableInt&lt;/code&gt; and &lt;code&gt;VariableChar&lt;/code&gt;. Since I'm taking somewhat of a C approach to the process, I felt it also necessary to write a &lt;code&gt;VariablePointer&lt;/code&gt; classs. This class has shown me some errors in logic in my other two classes, and some functions that I needed to write in my base classes. In other words, I'm still working on the &lt;code&gt;VariablePointer&lt;/code&gt; class.<br /> <br /> ==21 Oct - 28 Oct==<br /> <br /> The &lt;code&gt;VariablePointer&lt;/code&gt; finally fell into place last night. The key was that I realized that having pointers is an integral decision to a &quot;language&quot; &amp;ndash; meaning that every class that is written must have support for pointers. I had to add a couple of functions into each of the other &lt;code&gt;Variable&lt;/code&gt; extension classes, but so far, things are looking great. I'm to a point now where I'm think I'm ready to start working on a GUI to look at the memory in a visual manner. So far it's all been in my head. (What a mind job!)<br /> <br /> ==28 Oct - 02 Nov==<br /> <br /> Tom and I are struggling with how to combine our projects. Neither has quite the experience in Java to immediately know how they are going to mesh. We have an inkling of inheritance, but we haven't actually gotten it to work yet. Tom is still fervently working on the GUI side of his project, and hasn't had much time to work developing an ADT. Since he has been working with a stack as his test case, I decided to go ahead and implement a stack.<br /> <br /> This has proven harder than I was expecting because I had forgotten about all of the niceties given to one by the language in which they're working. More importantly however, we had a part of our paper due today. I had to turn my attention to solidifying what I'd been reading. This was especially hard and time consuming because I haven't been doing the best at keeping track of what I've been reading where. (A little bit lack of focus early on in the semester coupled with a sense of complacency because nothing was immediately due. Whoops!) Luckily I had some browser history that I could peruse to find what I had missed.<br /> <br /> ==02 Nov - 09 Nov==<br /> <br /> I completed the Stack class on Friday. The trick was to decide how to implement it. I haven't implemented array functionality yet, so I thought that I would create a pointer based stack. This led way to extending the VariablePointerClass. Once I did this, some things fell into place, but not everything. The gist of what I was missing was that, again, I was thinking that things would just &quot;take care of themselves.&quot; Not so. Since I'm writing this memory, if I haven't told it do something, it isn't going to do it. Basically, I'm getting a new found respect for the memory issues with which the old timers had to deal.<br /> <br /> At some point while I was working on the &lt;code&gt;VariablePointerClass&lt;/code&gt; code, I realized that I should probably start storing class Variables in the memory as well. However, at this early developmental stage I'm not going to worry about it. The storage an access functionality will be the same, so it should be a minor change later. For now, I make sure what I've got going on is correct. I want to get something working and on screen first. However, before that can get started, I need to make sure that Tom's project can actually use mine. I started looking at that on Sunday morning.<br /> <br /> Looking for how to do it brought me to the notion of libraries, or, in Java-speak, packages. They aren't difficult in concept, but it took me 3 hours to nail down just how to do it. The gist is this:<br /> <br /> If you want to make a class (file) part of a package, you must put<br /> <br /> &lt;code&gt;package packageName;&lt;/code&gt;<br /> <br /> at the head of your file. That was easy. The difficult part came in getting the compiler to compile the different parts of my program as part of the package. The problem was the directory structure and ''place of invocation'' of the compiler. How the Java compiler interprets the &lt;code&gt;package&lt;/code&gt; statement is as a directory structure. The above would mean that from ''where the compiler'' is invoked, there should be a subdirectory named &quot;packageName&quot; that contains all the files. So, if I had my java files A.java, B.java, and C.java, and I wanted to put them in the edu.earlham.cs.Graphics package I would add this to the very beginning of each file (excluding comments, it must be the ''first'' line):<br /> <br /> &lt;code&gt;package edu.earlham.cs.Graphics;&lt;/code&gt;<br /> <br /> Then, you would need to create a directory structure that matched that package line. (The '.' character delineates a subdirectory.) I would need to find somewhere to create the structure and copy the files into it. On Windows and *nix:<br /> <br /> Windows:<br /> <br /> &lt;code&gt;C:\Documents and Settings\Kevin\My Documents\Classes\SeniorSem\7dGraphics\&gt;md edu\earlham\cs\7dGraphics&lt;br /&gt;&lt;br /&gt;<br /> C:\Documents and Settings\Kevin\My Documents\Classes\SeniorSem\7dGraphics\&gt;copy *.java edu\earlham\cs\7dGraphics&lt;br /&gt;&lt;br /&gt;<br /> C:\Documents and Settings\Kevin\My Documents\Classes\SeniorSem\7dGraphics\&gt;&lt;/code&gt;<br /> <br /> *nix:<br /> <br /> &lt;code&gt;~/class/seniorsem/7dGraphics/&lt;br /&gt;<br /> $: mkdir edu/earlham/cs/7dGraphics&lt;br /&gt;&lt;br /&gt;<br /> ~/class/seniorsem/7dGraphics/<br /> $: cp *.java edu/earlham/cs/7dGraphics<br /> <br /> ~/class/seniorsem/7dGraphics/<br /> $:&lt;/code&gt;<br /> <br /> The trick is ''to compile from here'', not in the subdirectory like you might think:<br /> <br /> &lt;code&gt;~/class/seniorsem/7dGraphics/<br /> $: javac edu/earlham/cs/7dGraphics/Visualizer.java&lt;br /&gt;&lt;br /&gt;<br /> ~/class/seniorsem/7dGraphics/<br /> $:&lt;/code&gt;</div> Hunteke https://wiki.cs.earlham.edu/index.php?title=BCCD:Fossilizing&diff=868 BCCD:Fossilizing 2005-10-21T07:13:28Z <p>Hunteke: /* Fossilize /mnt/rw */</p> <hr /> <div>=Fossilizing the BCCD=<br /> This section outlines the steps required to disassemble a BCCD ISO, manifest it on a hard disk drive, and boot from that hard drive. Most or all of this '''must be done as root'''.<br /> <br /> ==Mount the Images==<br /> ===The Basic Images===<br /> &lt;pre&gt;<br /> cd /mnt # or where ever<br /> mkdir bccd<br /> mount -t iso9660 -o loop bccd-ppc-2005-08-30T00-0500.iso bccd<br /> <br /> # on PPC<br /> mkdir initrd<br /> gunzip &lt; bccd/boot/root.bin &gt; initrd.ext2<br /> mount -t ext2 -o loop initrd.ext2 initrd<br /> <br /> # on x86<br /> mkdir lnx<br /> mount -o loop bccd/lnx.img lnx<br /> mkdir root<br /> gunzip &lt; lnx/root.bin &gt; root.ext2<br /> mount -o loop root.ext2 root<br /> &lt;/pre&gt;<br /> <br /> ===The singularity===<br /> '''First, decompress the singularity with the cloop utility &lt;code&gt;extract_compressed_fs&lt;/code&gt;:'''<br /> &lt;pre&gt;<br /> wget http://developer.linuxtag.net/knoppix/sources/cloop_0.66-1.tar.gz<br /> tar xzf cloop_0.66-1.tar.gz<br /> cd cloop-0.66<br /> vim Makefile # add APPSONLY=1 at the top<br /> make zcode<br /> make extract_compressed_fs<br /> ./extract_compressed_fs ../bccd/singularity &gt; ../singularity.romfs<br /> cd ..<br /> &lt;/pre&gt;<br /> The latest currently-available version of cloop (2.01) doesn't work for this purpose; others might (I didn't experiment), but 0.66 definitely does.<br /> <br /> '''Next, mount the singularity (you must have romfs support compiled into the kernel):'''<br /> &lt;pre&gt;<br /> mkdir singularity<br /> mount -t romfs -o loop singularity.romfs singularity<br /> &lt;/pre&gt;<br /> <br /> ==Extract the singularity==<br /> &lt;pre&gt;<br /> cd singularity<br /> tar cf - . | (cd /path/to/destination/partition;tar xvf -)<br /> &lt;/pre&gt;<br /> <br /> ==Create a working initrd==<br /> Create an initrd for fossilized booting with the linuxrc at http://ppckernel.org/~tmcnulty/bccd/linuxrc:<br /> &lt;pre&gt;<br /> cd /mnt/root # or where ever you mounted root.ext2 (from root.bin)<br /> wget http://ppckernel.org/~tmcnulty/bccd/linuxrc # replace the existing linuxrc<br /> chmod a+x linuxrc<br /> cd ..<br /> umount root<br /> gzip &lt; root.ext2 &gt; /path/to/destination/partition/boot/root.bin<br /> &lt;/pre&gt;<br /> <br /> ==Edit singularity-init==<br /> ===Add / remount read-write hook===<br /> Edit &lt;code&gt;/sbin/singularity-init&lt;/code&gt; to remount / read-write during init, using the following command:<br /> &lt;pre&gt;<br /> debug &quot;Remounting / read-write...&quot;<br /> mount -o rw,remount /dev/root /<br /> &lt;/pre&gt;<br /> This can be placed somewhere around the proc mount command.<br /> <br /> ===Prepare for Fossilization of /mnt/rw===<br /> Comment out lines concerning /mnt/rw<br /> &lt;pre&gt;<br /> # mount -n -t tmpfs none /mnt/rw<br /> &lt;/pre&gt;<br /> <br /> ===Add network setup to singularity-init===<br /> &lt;pre&gt;<br /> ifconfig eth0 inet 192.168.10.1 netmask 255.255.255.0 broadcast 192.168.10.255 up<br /> route add default gw 192.168.10.1 eth0<br /> &lt;/pre&gt;<br /> <br /> ==Configure the bootloader==<br /> Configure your bootloader (e.g., yaboot, lilo, or grub) as follows:<br /> * boot the kernel &lt;code&gt;/boot/vmlinux&lt;/code&gt; on PowerPC or &lt;code&gt;/boot/bzImage&lt;/code&gt; on x86<br /> * use the initrd &lt;code&gt;/boot/root.bin&lt;/code&gt;<br /> * execute the init script &lt;code&gt;/linuxrc&lt;/code&gt;.<br /> <br /> Here is a sample [http://ppckernel.org/~tmcnulty/bccd/lilo.conf lilo.conf].<br /> <br /> ===Setup Compatibility Nodes===<br /> Add the following to /linuxrc:<br /> * /sbin/devfsd /dev<br /> <br /> ==De-Obfuscation==<br /> <br /> ===Remove Unneeded Symlinks===<br /> <br /> The deal is that the BCCD is now on a different (read/writeable) medium: a harddisk. Let's un-obfuscate some of the workings. An ls -l on / will reveal a few symlinks: /etc, /home, /local, /tmp, and /var. All of these point to an appropriate directory in /mnt/rw. What happens is that since the CD is not writeable, it creates a ramdisk, copies files from /etc.ro/ to /mnt/rw/etc/ (change etc accordingly), and then the /etc symlink becomes a writeable medium.<br /> <br /> Here's the works:<br /> &lt;pre&gt;<br /> rm /etc /home /local /tmp /var<br /> mkdir /etc /home /local /tmp /var<br /> cd /etc.ro &amp;&amp; tar cf - . | (cd /etc/; tar vf -)<br /> cd /home.ro &amp;&amp; tar cf - . | (cd /home/; tar vf -)<br /> cd /local.ro &amp;&amp; tar cf - . | (cd /local/; tar vf -)<br /> cd /tmp.ro &amp;&amp; tar cf - . | (cd /tmp/; tar vf -)<br /> cd /var.ro &amp;&amp; tar cf - . | (cd /var/; tar vf -)<br /> &lt;/pre&gt;<br /> <br /> You're almost done, except you should remove the place in the scripts where the bootup copies the files from /&lt;dir&gt;.ro/. Just comment out the lines in /sbin/singularity-init that do the copying (around line 105):<br /> <br /> &lt;pre&gt;<br /> # cp -a /etc.ro /mnt/rw/etc<br /> # cp -a /var.ro /mnt/rw/var<br /> &lt;/pre&gt;<br /> <br /> While you're editing /sbin/singularity-init, also comment out these lines:<br /> <br /> &lt;pre&gt;<br /> # rsync -plarv /lib/mozilla-1.6/plugins.ro/ /mnt/rw/plugins/<br /> # chmod 1777 /mnt/rw/tmp<br /> # debug &quot;Making /mnt/rw/tmp/build links&quot;<br /> # mkdir -p /mnt/rw/tmp/build/<br /> # mkdir -p /mnt/rw/tmp/build/staging<br /> # mkdir -p /mnt/rw/tmp/build/staging/singularity<br /> # mkdir -p /mnt/rw/tmp/build/staging/singularity/image<br /> # ln -s /lib /mnt/rw/tmp/build/staging/singularity/image/lib<br /> &lt;/pre&gt;<br /> <br /> ===Configure gcc Environment===<br /> <br /> Though the BCCD is now fossilized onto the harddrive, the gcc environment does not know this as it was compiled for the CD. It will look for files in (effectively) /tmp/build/staging/singularity/image/lib ... the directories and symlink creation that we just commented out. Since /tmp is a fossilized directory, just create a symlink inside of it:<br /> <br /> &lt;pre&gt;<br /> mkdir -p /tmp/build/staging/singularity/image<br /> cd /tmp/build/staging/singularity/image/<br /> ln -s /lib<br /> &lt;/pre&gt;<br /> <br /> ==TODO==<br /> * add Paul's scripts that will simplify parts of this process.<br /> * fix the mounting commands so that / is only mounted once (?)<br /> * decide how to handle directories like /etc that are mounted in ram at /dev/rw/etc and populated with items from /etc.ro (leave as is, or create a script to simplify the setup for hard disk booting?)<br /> ** Kevin's done this, we just need to document<br /> *** DONE<br /> * modify init scripts to make them appropriate for hard disk booting (e.g., remove the &quot;Enter a password for the default user&quot; prompt)<br /> ** This appears to be done<br /> * finish setting up networking<br /> * create a patch against the original singularity image for /sbin/singularity-init and other modified configuration files for automating the fossilize process<br /> * package up any binary additions with list-packages (see the package instructions in the wiki)<br /> * last but not least, keep track of all the changes we make!<br /> <br /> Good luck! Direct questions and comments to [mailto:tmcnulty@ppckernel.org tmcnulty@ppckernel.org].</div> Hunteke https://wiki.cs.earlham.edu/index.php?title=BCCD:Fossilizing&diff=812 BCCD:Fossilizing 2005-10-21T07:13:00Z <p>Hunteke: /* Edit singularity-init */</p> <hr /> <div>=Fossilizing the BCCD=<br /> This section outlines the steps required to disassemble a BCCD ISO, manifest it on a hard disk drive, and boot from that hard drive. Most or all of this '''must be done as root'''.<br /> <br /> ==Mount the Images==<br /> ===The Basic Images===<br /> &lt;pre&gt;<br /> cd /mnt # or where ever<br /> mkdir bccd<br /> mount -t iso9660 -o loop bccd-ppc-2005-08-30T00-0500.iso bccd<br /> <br /> # on PPC<br /> mkdir initrd<br /> gunzip &lt; bccd/boot/root.bin &gt; initrd.ext2<br /> mount -t ext2 -o loop initrd.ext2 initrd<br /> <br /> # on x86<br /> mkdir lnx<br /> mount -o loop bccd/lnx.img lnx<br /> mkdir root<br /> gunzip &lt; lnx/root.bin &gt; root.ext2<br /> mount -o loop root.ext2 root<br /> &lt;/pre&gt;<br /> <br /> ===The singularity===<br /> '''First, decompress the singularity with the cloop utility &lt;code&gt;extract_compressed_fs&lt;/code&gt;:'''<br /> &lt;pre&gt;<br /> wget http://developer.linuxtag.net/knoppix/sources/cloop_0.66-1.tar.gz<br /> tar xzf cloop_0.66-1.tar.gz<br /> cd cloop-0.66<br /> vim Makefile # add APPSONLY=1 at the top<br /> make zcode<br /> make extract_compressed_fs<br /> ./extract_compressed_fs ../bccd/singularity &gt; ../singularity.romfs<br /> cd ..<br /> &lt;/pre&gt;<br /> The latest currently-available version of cloop (2.01) doesn't work for this purpose; others might (I didn't experiment), but 0.66 definitely does.<br /> <br /> '''Next, mount the singularity (you must have romfs support compiled into the kernel):'''<br /> &lt;pre&gt;<br /> mkdir singularity<br /> mount -t romfs -o loop singularity.romfs singularity<br /> &lt;/pre&gt;<br /> <br /> ==Extract the singularity==<br /> &lt;pre&gt;<br /> cd singularity<br /> tar cf - . | (cd /path/to/destination/partition;tar xvf -)<br /> &lt;/pre&gt;<br /> <br /> ==Create a working initrd==<br /> Create an initrd for fossilized booting with the linuxrc at http://ppckernel.org/~tmcnulty/bccd/linuxrc:<br /> &lt;pre&gt;<br /> cd /mnt/root # or where ever you mounted root.ext2 (from root.bin)<br /> wget http://ppckernel.org/~tmcnulty/bccd/linuxrc # replace the existing linuxrc<br /> chmod a+x linuxrc<br /> cd ..<br /> umount root<br /> gzip &lt; root.ext2 &gt; /path/to/destination/partition/boot/root.bin<br /> &lt;/pre&gt;<br /> <br /> ==Edit singularity-init==<br /> ===Add / remount read-write hook===<br /> Edit &lt;code&gt;/sbin/singularity-init&lt;/code&gt; to remount / read-write during init, using the following command:<br /> &lt;pre&gt;<br /> debug &quot;Remounting / read-write...&quot;<br /> mount -o rw,remount /dev/root /<br /> &lt;/pre&gt;<br /> This can be placed somewhere around the proc mount command.<br /> <br /> ===Fossilize /mnt/rw===<br /> Comment out lines concerning /mnt/rw<br /> &lt;pre&gt;<br /> # mount -n -t tmpfs none /mnt/rw<br /> &lt;/pre&gt;<br /> <br /> ===Add network setup to singularity-init===<br /> &lt;pre&gt;<br /> ifconfig eth0 inet 192.168.10.1 netmask 255.255.255.0 broadcast 192.168.10.255 up<br /> route add default gw 192.168.10.1 eth0<br /> &lt;/pre&gt;<br /> <br /> ==Configure the bootloader==<br /> Configure your bootloader (e.g., yaboot, lilo, or grub) as follows:<br /> * boot the kernel &lt;code&gt;/boot/vmlinux&lt;/code&gt; on PowerPC or &lt;code&gt;/boot/bzImage&lt;/code&gt; on x86<br /> * use the initrd &lt;code&gt;/boot/root.bin&lt;/code&gt;<br /> * execute the init script &lt;code&gt;/linuxrc&lt;/code&gt;.<br /> <br /> Here is a sample [http://ppckernel.org/~tmcnulty/bccd/lilo.conf lilo.conf].<br /> <br /> ===Setup Compatibility Nodes===<br /> Add the following to /linuxrc:<br /> * /sbin/devfsd /dev<br /> <br /> ==De-Obfuscation==<br /> <br /> ===Remove Unneeded Symlinks===<br /> <br /> The deal is that the BCCD is now on a different (read/writeable) medium: a harddisk. Let's un-obfuscate some of the workings. An ls -l on / will reveal a few symlinks: /etc, /home, /local, /tmp, and /var. All of these point to an appropriate directory in /mnt/rw. What happens is that since the CD is not writeable, it creates a ramdisk, copies files from /etc.ro/ to /mnt/rw/etc/ (change etc accordingly), and then the /etc symlink becomes a writeable medium.<br /> <br /> Here's the works:<br /> &lt;pre&gt;<br /> rm /etc /home /local /tmp /var<br /> mkdir /etc /home /local /tmp /var<br /> cd /etc.ro &amp;&amp; tar cf - . | (cd /etc/; tar vf -)<br /> cd /home.ro &amp;&amp; tar cf - . | (cd /home/; tar vf -)<br /> cd /local.ro &amp;&amp; tar cf - . | (cd /local/; tar vf -)<br /> cd /tmp.ro &amp;&amp; tar cf - . | (cd /tmp/; tar vf -)<br /> cd /var.ro &amp;&amp; tar cf - . | (cd /var/; tar vf -)<br /> &lt;/pre&gt;<br /> <br /> You're almost done, except you should remove the place in the scripts where the bootup copies the files from /&lt;dir&gt;.ro/. Just comment out the lines in /sbin/singularity-init that do the copying (around line 105):<br /> <br /> &lt;pre&gt;<br /> # cp -a /etc.ro /mnt/rw/etc<br /> # cp -a /var.ro /mnt/rw/var<br /> &lt;/pre&gt;<br /> <br /> While you're editing /sbin/singularity-init, also comment out these lines:<br /> <br /> &lt;pre&gt;<br /> # rsync -plarv /lib/mozilla-1.6/plugins.ro/ /mnt/rw/plugins/<br /> # chmod 1777 /mnt/rw/tmp<br /> # debug &quot;Making /mnt/rw/tmp/build links&quot;<br /> # mkdir -p /mnt/rw/tmp/build/<br /> # mkdir -p /mnt/rw/tmp/build/staging<br /> # mkdir -p /mnt/rw/tmp/build/staging/singularity<br /> # mkdir -p /mnt/rw/tmp/build/staging/singularity/image<br /> # ln -s /lib /mnt/rw/tmp/build/staging/singularity/image/lib<br /> &lt;/pre&gt;<br /> <br /> ===Configure gcc Environment===<br /> <br /> Though the BCCD is now fossilized onto the harddrive, the gcc environment does not know this as it was compiled for the CD. It will look for files in (effectively) /tmp/build/staging/singularity/image/lib ... the directories and symlink creation that we just commented out. Since /tmp is a fossilized directory, just create a symlink inside of it:<br /> <br /> &lt;pre&gt;<br /> mkdir -p /tmp/build/staging/singularity/image<br /> cd /tmp/build/staging/singularity/image/<br /> ln -s /lib<br /> &lt;/pre&gt;<br /> <br /> ==TODO==<br /> * add Paul's scripts that will simplify parts of this process.<br /> * fix the mounting commands so that / is only mounted once (?)<br /> * decide how to handle directories like /etc that are mounted in ram at /dev/rw/etc and populated with items from /etc.ro (leave as is, or create a script to simplify the setup for hard disk booting?)<br /> ** Kevin's done this, we just need to document<br /> *** DONE<br /> * modify init scripts to make them appropriate for hard disk booting (e.g., remove the &quot;Enter a password for the default user&quot; prompt)<br /> ** This appears to be done<br /> * finish setting up networking<br /> * create a patch against the original singularity image for /sbin/singularity-init and other modified configuration files for automating the fossilize process<br /> * package up any binary additions with list-packages (see the package instructions in the wiki)<br /> * last but not least, keep track of all the changes we make!<br /> <br /> Good luck! Direct questions and comments to [mailto:tmcnulty@ppckernel.org tmcnulty@ppckernel.org].</div> Hunteke https://wiki.cs.earlham.edu/index.php?title=LittleFe:PXE_Booting&diff=5372 LittleFe:PXE Booting 2005-10-21T03:16:38Z <p>Hunteke: fixed typo</p> <hr /> <div>In order to setup PXE booting the client nodes must get their DHCP information from the node serving the kernel. We have setup dhcpd on littlefe0 with the following entry for each littlefe node to know where to get it's kernel.<br /> &lt;br&gt;&lt;tt&gt;<br /> group {<br /> next-server 192.168.10.100;<br /> filename &quot;pxelinux.0&quot;;<br /> use-host-decl-names on;<br /> <br /> host littlefe1 { hardware ethernet 00:40:63:d8:a2:2c; fixed-address 192.168.10.101; }<br /> host littlefe2 { hardware ethernet 00:40:63:d8:a2:93; fixed-address 192.168.10.102; }<br /> ....<br /> &lt;br&gt;<br /> }<br /> &lt;/tt&gt;&lt;br&gt;<br /> The host entry gives the remote its own hostname through dhcp. The &quot;filename&quot; entry here specifies the pxe boot loader. We use the pxe linux bootloader based on the syslinux bootloader (http://syslinux.zytor.com/pxe.php ). The filename is relative to the tftpd root directory, /tftpboot/ on littlefe0. The &quot;/tftpboot/pxelinux.cfg&quot; file specifies the kernel binary, again relative to the tftp root directory, and kernel options to be passed on client nodes. We pass the following options:<br /> &lt;br&gt;&lt;tt&gt;<br /> DEFAULT vmlinuz-2.6.12 ramdisk_size=16384 ip=dhcp root=/dev/nfs nfsroot=192.168.10.100:/diskless/<br /> &lt;/tt&gt;&lt;br&gt;<br /> This specifies which kernel binary to load. Thus, to change the kernel loaded by the diskless nodes you either copy over the file that the config points to or point the config at the new kernel binary. It also prepares a ramdisk and tells the client to mount /diskless/ nfs export from littlefe0. The /diskless/ directory on littlefe0 is the root directory of each of the client nodes.<br /> <br /> The ramdisk on each client node is further prepared by the /init/local script. This script formats the ramdisk, mounts it to /mnt/ramdisk, and copies the skeleton ramdisk directory sturcture from /mnt/ramdisk_skel. Currently we put three directories on the ramdisk, /var/lock/ , /var/run/ , and /var/spool/ each of these are linked to the equivalent ramdisk directory, ie /var/lock -&gt; /mnt/ramdisk/lock.<br /> <br /> In order to make changes to client nodes, first boot littlefe0 and another node with all of the networking in place so that they can communicate. Next, login to the client node. This node has littlefe0's /diskless/ directory mounted as its root directory, / . In order to make changes that affect each client node simply modify the root directory on the single booted client node. These changes will be updated on /diskless/ on littlefe0 and thus on every other client node. For example, running &quot;apt-get install&quot; on littlefe1 will add a package to every littlefe client node. To modify scripts or configuration, in /etc/ for example, it is also possible to modify the /diskless/ directory on littlefe0 directly from the root node. <br /> <br /> Making changes to the root node, littlefe0 is done in the normal way. In order to modify all the nodes, root and clients, the commands must be run on both littlefe0 and one client node.<br /> <br /> To add rc scripts, for example kdm, to particular runlevels in debian use the following<br /> <br /> &lt;tt&gt;update-rc.d kdm defaults&lt;/tt&gt;<br /> <br /> To remove rc scripts, for example, from every runlevel while leaving the /etc/init.d/ script intact use the following<br /> <br /> &lt;tt&gt;update-rc.d -f kdm remove&lt;/tt&gt;<br /> <br /> For this example if we wanted to run kdm on some subset of the diskless nodes we would need to modify the kdm init.d script to check the hostname of the local machine and only execute kdm if the local hostname matches a node on which we want kdm running.<br /> <br /> Since the littlefe0's hard drive has every node's filesystem it is important to backup regularly. There is a backup script in root's home directory on the diskless nodes, backupfe0.sh. It requires that there is a hard drive connected to the diskless node's ide0 channel. This script mounts littlefe0's root directory to /mnt/fe0, the local hard drive to /mnt/part1 . Then, it rsyncs the /mnt/part1 to a copy of /mnt/fe0.</div> Hunteke https://wiki.cs.earlham.edu/index.php?title=Kevin_SS_WeeklyJournal2005&diff=870 Kevin SS WeeklyJournal2005 2005-10-19T08:57:05Z <p>Hunteke: /* 12 Oct - 19 Oct */</p> <hr /> <div>Kevin's Weekly Journals for Senior Seminar 2005<br /> <br /> ==31 Aug - 07 Sep==<br /> <br /> My capstone is currently sitting in my mind, looking like a fearsome thing. I was supposed to have an abstract ready this week, but I did not know on what I could write. I would like to do something in terms of User Interface and design, but I'm not sure that this would be untrod ground. Obviously, I'm only an undergraduate student, so I'm not expecting to do PHd research, but I get the sense that my capstone should be at least somewhat original. Perhaps, since I have an interest in operating systems, I can think about doing something with [http://www.reactos.org/ ReactOS].<br /> <br /> ==07 Sep - 14 Sep==<br /> <br /> My main work this week has been cognition. I'm jealous of some of my peers who have ideas already. I'm completely at a loss. I know that if I ask Charlie, his canned response will be &quot;Well, what's your itch?&quot; I've got nails, but nothing to itch, that's the problem. I've come up with a project that I think would be entirely cool, but I'm not sure how to create it. It's [[Teaching Language, The|The Teaching Language]]. Unfortunately, I'm not exactly sure how to implement it. I've never written a langauge before. I'm kind of thinking of something similar to HTML and CSS, but in the context of objects as opposed to text. I'm not initially sure how to go about this. The language creation will probably come second as I'm going to have to research how to describe these objects in my own mind first. I ''really'' want them to be manipulatable, so the complexity is ginormous. If I can get past that the first hurdle ... man! I'm so psyched.<br /> <br /> ==14 Sep - 21 Sep==<br /> <br /> Even as I was writing [[Teaching Language, The|The Teaching Language]] abstract last week, I knew that I didn't (don't) have the background to complete such a project in one semester. However, the ideas are there: I just need to focus them. I think I've decided on the direction that has already proven to have some merit: CSLets. I [[Initial_Abstract|mentioned]] them in the context of not knowing exactly where I wanted to go, but I think that they might prove the best direction. I'm currently cogitating about ideas for CSLets.<br /> <br /> ==21 Sep - 28 Sep==<br /> <br /> I spent the majority of this week brainstorming about tools that I would like to create. I seem to be having delusions of grandeur though, because a lot of the CSlets that I might want to create are probably just a bit beyond my current capabilities (or at least time scope). One CSlet that is worming its way through my mind is the C-string Let that I [[New_Direction,_A|mentioned last week]]. I started trying to write it, but I found, in the midst of working on a consistent interface for the user, that I have more of a desire for a visual memory manager. I'm not entirely sure of the structure, but this has implications of extensability, much more so than the C-string Let idea. For one thing, if I do it right, the C-string Let could sit on top of this. Thinking continues ...<br /> <br /> ==28 Sep - 05 Oct==<br /> <br /> A teacher once told me that the best way to tackle problems is to draw a picture. True to form, I have drawn a picture [[Image:memsketch.png|thumb|Visual Memory Manager sketch]] of my initial ideas regarding a memory manager. What I'm thinking is that users can click on the buttons in the lower left hand part of the screen to create and access variables. The contents would be displayed in the gray bar on the bottom, as well as the location &quot;physically&quot; identified by the purple circle. The idea of this program is to represent the memory in a visual manner that is accessible to new students. Ideally this would be something with which students could at first rotely interact, but then also find other uses for it such helping to visualize problems they will encounter as they continue in CS. Thought it is still not complete, -- I haven't thought entirely through how I'm going to deal with some of the details of implementation -- I'm kind of excited.<br /> <br /> ==05 Oct - 12 Oct==<br /> <br /> In the meeting last week, it became apparent that Tom and I are working on projects of an extremely similar nature. It was clear that we should work together, especially as we both have hopes that our code gets used and is extensible. Charlie pointed out that the easiest way to make something extensible is to write it to conform with two different ideas (in so many words ...).<br /> <br /> To this end, I started to write the implentation behind my Visual Memory Manager Let. I got lost in some of the implementation details, however. Tom and I found some time to talk about how we might make some headway. We came up with some great ideas.<br /> <br /> For extensability, we are still thinking in terms of modules and packages, but our scope suddenly has some wider prospects. Currently, it looks like we're going to make a Memory Manager and then make modules that lie on top of that. One of Tom's project ideas is to teach data structures in a visual manner. One of my project ideas is to (partially) demystify the workings of the memory. My current drive is to create a memory system that can be interfaced via an API. Then Tom can write his program to conform to the API: at the same time his module is demonstrating a data stucture concept, my program can show ''exactly'' what is happening behind the scenes.<br /> <br /> ==12 Oct - 19 Oct==<br /> <br /> This past week was hampered by Fall Break, but I did manage to change the code that I had written to begin to conform to what Tom and I talked about in our meeting last week. A personal failing that I'm having is an inability to ''step back from the code''. I'm still having some problems with the implementation, and I think it's because I haven't completely thought out the structure to which I want to conform. But, as the old adage goes, &quot;Time stops for no man;&quot; so I'd better hurry up and get my head in gear.<br /> <br /> In other news, I have read some of the [http://www.cc.gatech.edu/gvu/people/Faculty/Mark.Guzdial.html website] provided by Alex. Mark Guzdial has done some interesting work, but it is not quite the same avenue that Tom and I are wishing to explore. Guzdial's work is centered around bringing out the things that can be done with a computer and making it accessible. The main thrust of what I read is about using computers to play with different multimedia (pictures, movies). A couple of examples include his explainations of how to manipulate images with some python programs, and how Disney did/does some of its digital animation. A fun read, with some real output potential for people who don't want to be deeply involved in CS. However, not for Tom or myself.</div> Hunteke https://wiki.cs.earlham.edu/index.php?title=Kevin_SS_WeeklyJournal2005&diff=802 Kevin SS WeeklyJournal2005 2005-10-19T08:52:57Z <p>Hunteke: /* 05 Oct - 12 Oct */</p> <hr /> <div>Kevin's Weekly Journals for Senior Seminar 2005<br /> <br /> ==31 Aug - 07 Sep==<br /> <br /> My capstone is currently sitting in my mind, looking like a fearsome thing. I was supposed to have an abstract ready this week, but I did not know on what I could write. I would like to do something in terms of User Interface and design, but I'm not sure that this would be untrod ground. Obviously, I'm only an undergraduate student, so I'm not expecting to do PHd research, but I get the sense that my capstone should be at least somewhat original. Perhaps, since I have an interest in operating systems, I can think about doing something with [http://www.reactos.org/ ReactOS].<br /> <br /> ==07 Sep - 14 Sep==<br /> <br /> My main work this week has been cognition. I'm jealous of some of my peers who have ideas already. I'm completely at a loss. I know that if I ask Charlie, his canned response will be &quot;Well, what's your itch?&quot; I've got nails, but nothing to itch, that's the problem. I've come up with a project that I think would be entirely cool, but I'm not sure how to create it. It's [[Teaching Language, The|The Teaching Language]]. Unfortunately, I'm not exactly sure how to implement it. I've never written a langauge before. I'm kind of thinking of something similar to HTML and CSS, but in the context of objects as opposed to text. I'm not initially sure how to go about this. The language creation will probably come second as I'm going to have to research how to describe these objects in my own mind first. I ''really'' want them to be manipulatable, so the complexity is ginormous. If I can get past that the first hurdle ... man! I'm so psyched.<br /> <br /> ==14 Sep - 21 Sep==<br /> <br /> Even as I was writing [[Teaching Language, The|The Teaching Language]] abstract last week, I knew that I didn't (don't) have the background to complete such a project in one semester. However, the ideas are there: I just need to focus them. I think I've decided on the direction that has already proven to have some merit: CSLets. I [[Initial_Abstract|mentioned]] them in the context of not knowing exactly where I wanted to go, but I think that they might prove the best direction. I'm currently cogitating about ideas for CSLets.<br /> <br /> ==21 Sep - 28 Sep==<br /> <br /> I spent the majority of this week brainstorming about tools that I would like to create. I seem to be having delusions of grandeur though, because a lot of the CSlets that I might want to create are probably just a bit beyond my current capabilities (or at least time scope). One CSlet that is worming its way through my mind is the C-string Let that I [[New_Direction,_A|mentioned last week]]. I started trying to write it, but I found, in the midst of working on a consistent interface for the user, that I have more of a desire for a visual memory manager. I'm not entirely sure of the structure, but this has implications of extensability, much more so than the C-string Let idea. For one thing, if I do it right, the C-string Let could sit on top of this. Thinking continues ...<br /> <br /> ==28 Sep - 05 Oct==<br /> <br /> A teacher once told me that the best way to tackle problems is to draw a picture. True to form, I have drawn a picture [[Image:memsketch.png|thumb|Visual Memory Manager sketch]] of my initial ideas regarding a memory manager. What I'm thinking is that users can click on the buttons in the lower left hand part of the screen to create and access variables. The contents would be displayed in the gray bar on the bottom, as well as the location &quot;physically&quot; identified by the purple circle. The idea of this program is to represent the memory in a visual manner that is accessible to new students. Ideally this would be something with which students could at first rotely interact, but then also find other uses for it such helping to visualize problems they will encounter as they continue in CS. Thought it is still not complete, -- I haven't thought entirely through how I'm going to deal with some of the details of implementation -- I'm kind of excited.<br /> <br /> ==05 Oct - 12 Oct==<br /> <br /> In the meeting last week, it became apparent that Tom and I are working on projects of an extremely similar nature. It was clear that we should work together, especially as we both have hopes that our code gets used and is extensible. Charlie pointed out that the easiest way to make something extensible is to write it to conform with two different ideas (in so many words ...).<br /> <br /> To this end, I started to write the implentation behind my Visual Memory Manager Let. I got lost in some of the implementation details, however. Tom and I found some time to talk about how we might make some headway. We came up with some great ideas.<br /> <br /> For extensability, we are still thinking in terms of modules and packages, but our scope suddenly has some wider prospects. Currently, it looks like we're going to make a Memory Manager and then make modules that lie on top of that. One of Tom's project ideas is to teach data structures in a visual manner. One of my project ideas is to (partially) demystify the workings of the memory. My current drive is to create a memory system that can be interfaced via an API. Then Tom can write his program to conform to the API: at the same time his module is demonstrating a data stucture concept, my program can show ''exactly'' what is happening behind the scenes.<br /> <br /> ==12 Oct - 19 Oct==<br /> <br /> This past week was hampered by Fall Break, but I did manage to change the code that I had written to begin to conform to what Tom and I talked about in our meeting last week. A personal failing that I'm having is an inability to ''step back from the code''. I'm still having some problems with the implementation, and I think it's because I haven't completely thought out the structure to which I want to conform. But, as they say, time stops for no man: I'd better hurry up and get my head in gear.<br /> <br /> In other news, I have read some of the [http://www.cc.gatech.edu/gvu/people/Faculty/Mark.Guzdial.html website] provided by Alex. Mark Guzdial has done some interesting work, but it is not quite the same avenue that Tom and I are wishing to explore. Guzdial's work is centered around bringing out the things that can be done with a computer and making it accessible. The main thrust of what I read is about bringing media out with computers. A couple of examples include his explaining how to manipulate images with some pyhton programs, and how Disney did some digital animation. A fun read, with some real output for people who don't want to be deeply involved in CS.</div> Hunteke