>> I feel very strongly >> that we should pick one architecture and one platform and build for >> that. > > I would agree with platform. We should aim to provide a complete > solution, and this means bundling some kind of kernel and userland. > I disagree that we should only target one architecture, however, > because it would be very difficult to choose between x86 and macppc. > x86 has the larger install base, but Mac has the largest install base > of people who are obsessive about their UI - which might be a larger > potential target for Étoilé.
If we are able to work with a team already producing their OS (kernal/userland) for multiple architectures, and the maturity of each arch we want to target is fairly equivalent, then I would have no problem with doing what you suggest, as long as the impact on our workload is minimal. I do agree that x86 and PPC are the top two platforms to work towards, with amd64 as the next in line. Etoile on x86 seems like a no-brainer. Most free software OSs are developed with x86 in mind, and if we're going to run Etoile on a free OS (Linux, BSD or other), then x86 support is virtually a given. And, like you said, it has the largest install base. I question who the userbase of Etoile on PPC would be though. My first thoughts are Free Software advocates, users with older or minimal hardware (original iMacs and G3s), Cocoa developers and perhaps GUI aficionados. I assume there must be a market for Linux on PPC with the number of distros supporting that setup... but I always thought that was so that sites with different architectures (schools, etc) could present a consistent UI to users. Most of our development pool will be OS X users, though, so maybe Etoile on PPC is more important than I originally thought. One additional thing to think about if we want to support multiple architectures is software distribution. Do we want to allow users on different arches to be able to swap binaries? Do we want to make it easy for users to get and install software, without having to think about what arch they're on? If so, we need a mechanism for handling fat binaries then. Perhaps we can get around some of this with a really good sofware distribution/package management service, but our audience is home users (as far as I can tell), and we all seem extremely concerned about ease of use, so let's keep this in mind while we're determining the bundle structure of services and components. J.
