Tonys Mac Page

(I have moved all of my development stuff from Mac to here. There is a link there back to here. -tr 1jan07)
(As of 20may07, a lot of this information is obsolete and should be updated: in place? new page? - tr)

Mac Build process implentation might proceed in three phases:

1. process definition/development
2. ramp-up
3. integration into mainstream build

During process definition/development, it should not be expected that many systems will make it from prototype build to the store. Discovery of problem solutions, few people, learning about new Mac platforms (and incorporationg that into the process definition), and lack of storage space limit the number of systems that will be looked at.

During ramp-up, build teachers will be trained in the process and recruits (interested guinea pigs) brought in to polish the build process.

The integration phase represents the full blown incorporation of the Mac Build process into the currently activer PC build process.

Drivers

• Unused available hardware
• Contribute to revenue stream
• Expand HW knowledge in Programs
• ???

Constraints

• Storage space limitation
• Few knowledgeable volunteers
• CRT hazard in recycle

What are we building: an iMac or a Linux box?
There seems to be some thought in the community that the rebuilt iMacs should retain an Apple Mac personality: hardware configuration should match the original label, one-button mouse, etc. I have some of arguments against this.

1. Rebuilt iMac boxes already have a significantly different hardware configuration than is indicated on any label. Ubuntu installation requires/suggests 256MB of ram; the labels we see say 32MB, 64MB, or 128MB. Many iMacs that we see have hard drives that are 4GB or 6GB. Those are being replaced with 20GB drives.
2. Macs that arrive may already have been upgraded with larger drives and/or more memory. The suggested practice of retaining those configurations, or trying to match label configurations, has led to the suggestion to test memory and hard drives in place. Testing in place adds several hours to the Mac Eval/Build process. It would be more efficient, and more in keeping with the existing build process, to remove all memory and hard drives, send them to Advanced Testing, and replace them from the tested memory and hard drive stacks to produce a standard store configuration.
3. The Mac 'personality' is a combination of hardware, Mac OS, Mac software, and Mac UI. The installation of Linux replaces three of the four parts. With the exception of the way the box looks, the Mac personality is gone.
4. The Mac OS 9 (and OS X ?) UI is tailored to a one-button mouse. The Linux/Ubuntu UI expects a two-button or three button mouse. Getting at the 2-3 button functionality of the Ubuntu UI is awkward at best with a one-button mouse.

My contention is that we are rebuilding the Macs to be, for the moment, Freegeek Store Linux Boxes. They should be configured as a standard low-end store box with 256MB, 10-15G HD, and a 3-button mouse. This approach allows for a more efficient MacBuild process and better use of the existing triage/test/build stations.

What Macs should FreeGeek keep to rebuild?
FreeGeek receives more Apple/Macintosh systems than it currently has resource to triage/rebuild. There are two volunteers actively working on Macs for resale and defining the Mac process. There is very limited space to store the received systems, and even less space to store systems destined for rebuild. Mac systems do not currently go through the Eval1/Eval2 triage process, but accumulate on the Mac shelf and are picked up by a MacRenewal representative once a week. Since the Mac triage/rebuild process is in the earliest stages of development, getting one system through the process takes a relatively long time. For these reasons I will propose here some criteria for accepting Mac systems into the Mac triage/rebuild process.

• Only accept systems if there is room in the triage/rebuild storage area
• Accept higher speed systems and Towers. Lower speed 'bubble' systems are problematical for several reasons (see another section TBD). I suggest a lower limit acceptance cpu speed of 450MHz, with the qualifications that all G3 and G4 Towers be accepted. Should the triage/build queue empty, 400MHz systems on the Mac shelf could be accepted.
• Do not accept any tray load CD systems. These are the older, slower systems (233,266,300,333), use 144-pin SODIMMs, usually 32MB or 64MB, and are generally harder to work with. (need more discussion

about RevA/B low-)end tray loaders.

Here is first cut at an overview

Mac Triage

• Current in-work version is at User:Tonyr/MacTriage/Current
• history of this graph is at User:Tonyr/MacTriage

Notes

• Mac Triage should maintain a pool of small hard drives, good batteries
• Should any hard drive or memory be tested in place?
• Add POST explanation
• CPU is not normally observable on logic board in 'bubble' systems; HasCPU node should probably be removed. What should be done instead?
• Add node for general condition inspection.

Mac Rebuild

Tonys_MacRebuild_Checklist