James C. Liu wrote: > Dave: > > A pretty detailed document. Nice work. > > To ponder the concept and conundrums learned from Linux - > > A) we must co-exist on the disk - hence it was imperative to develop > filesystem support for as many filesystems out there. ZFS basically > has problems because now the data cannot be shared across instances > of OS. This has many implications to usability and choice. With > Linux, I can do my work and share the files on static slices of the > FS. If I need Win32, I boot it, and it has the same/similar access > to files. ZFS as a default in Caiman is dictating to users that they > must drink all the cool-aid, unless we provide Win32, BSD and Linux > equivalents to ZFS modules. >
I don't agree that it's attempting to dictate anything in particular - right now we have exactly one choice for filesystems to which you can install, UFS, which isn't necessarily readable on any other OS (and certainly isn't across ISA's with different endianness). In terms of user data, yes, we're not providing a cross-platform place for them to drop their data, but ZFS isn't making that requirement any better or worse initially, though the thought that it will be ported to other platforms might make it better long-term. What I guess I'm interpreting here is that you're arguing we should provide some sort of capability to create a FAT32 or some sort of "interoperable" filesystem for user data as part of the installer? > B) Drivers, Drivers, Drivers - The problem with solaris install is > that it doesn't have the drivers it needs to install itself, let > alone the network drivers for the network install. Chicken and egg > problem. We need a quick way to at least enable users to add drivers > legally and then to incorporate them into the miniroot. Otherwise, > booting PXE might be fine, until the miniroot loads and boots and its > game-over, or until we try to touch the SATA-RAID controller and we > break again. Linux has an inate advantage here. It's the GPL. > Viral in nature and quick to spread. Anyone can incorporated source > and rebuild the modules needed. Solaris is encumbered by CDDL and it > makes it hard to get that stuff quickly into the source base, let > alone the installation image. We need to reduce the barrier to > getting drivers into the installation, and that means off-line tools > that manipulate the installation methods, whether it be ISO media, > FLARs, PXE/nfs images, etc. > I can't do anything about the license situation, but I agree that the need to add drivers to an image is a requirement; in fact it's #14 on the list in chapter 3. But I also see I probably should have said more about it than the rather passing reference that's in 4.1 (end of 3rd paragraph). > C) We need to understand who and what Opensolaris customers are and > not make the mistakes that Marketing and many Trade publications > make. They [Marketing] still don't understand Linux or BSD users in > many aspects, and what is still driving Linux development. Decisions > and priorities should be driven by our prized users (i.e. the Higher > IQ home/work/school hacker) and not the SMB except when their needs > coincide. The SMB are unlikely to be early adopters until Open > Solaris has established a stronger hold in the mainstream, but even > then, SMB don't drive much of the core architecture of install. That > said, catering an install to the SMB such as by providing a fancy > GUI, is likely to divert attention to priorities (A) and (B). For > example, the Anaconda installer still core dumps on quite a few > graphics cards and so text install is safer and more robust on > Redhat. That's a fact that many Marketing organizations that don't > do their own Linux installs wouldn't know. I completely agree that a simpler install isn't enough to get Solaris into an SMB market; it's a necessary condition, but not sufficient. But even so, I don't regard a GUI as a diversion - it's a requirement, so we will do it, and do it well. We'll also do a text interface that's similarly usable, because that's a requirement, too. We're certainly hostage to the stability of X for the GUI, but I'm sure Sun's X team (and I'd hope the whole X community, though I don't know any of them at all) is committed to fixing those things when they know about them. Thanks for the comments! Dave
