[indiana-discuss] Indiana Problem Statement

[John Sonnenschein]

Here's my picking at nits, comments inline -->

On 6/11/07, Glynn Foster <Glynn.Foster at sun.com> wrote:

> Indiana Requirements Document v0.5

>    The distribution will showcase much of the work continuing in the
>    OpenSolaris community and the best of breed open source software
>    available within other open source communities. Moverover, the
>    distribution will include work that closes the familiarity gap with
>    existing GNU/Linux users eg. install and packaging.

Are you implying we should abandon the Solaris userspace in favour of
GNU tools, because I'm not okay with that. I very much dislike 90% of
the GNU tools


>    2.1) Adoption Barriers
>
>    Solaris is a world class operating system with many innovative
>    features. However, in a few areas the user experience has
>    been sub-optimal, causing a potential adoption barrier. Those
>    areas in particular include ease of management, ease of install
>    of the core operating system, the management of additional
>    software and configuration and the availability of hardware
>    support. Added to this is the frustration caused by the outdated
>    nature of existing software, and the poor availability of
>    certain development tools.

One man's "outdated" is another man's "stable". If there's a problem
with outdated software at all, it's that certain consolidations don't
backport bug fixes to older versions, choosing instead to force their
users to "upgrade" to the latest when it's out.

Also, which development tools? gcc, gmake, the whole bit are included
in nevada...


>    2.3) Source or Distribution
>
>    Despite the success of the OpenSolaris community over the last 2
>    years, and the phenomenal growth it has seen, confusion has also
>    grown over the expectations of whether OpenSolaris is a source
>    base or a binary distribution. Many newcomers to the community
>    assume there is an official OpenSolaris distribution to
>    download and install.

There is no official "Linux" either, but that hasn't been a
significant barrier to their adoption. OpenSolaris is a source base
and should remain that way, ambiguities about that should be dealt
with by education, not by redefining what OpenSolaris is.


>         INS-4: A LiveCD should be available for a 'try first,
>                install later' experience. The LiveCD functionality
>                should be integrated into the core install CD.

Does it need to be the same CD a la Ubuntu? or can it be split among
two ( livecd and installCD ), because a functional copy of all the
useful software takes up space that could be better served by
including choices on the CD IMO. there can be a fully functional
version of staroffice, or we could ship packages like KDE /and/ GNOME
to give users some choices...

>         PKG-3: Software should also be available in meta clusters
>                for people to install specific to their needs eg.
>                Web 2.0 meta cluster.

+1, and I'd take it further to say that software should /only/ be
available in meta-clusters. This is the point I was making a few days
ago about fencing off software so as to have well tested version
bundles to greatly reduce the permutations of software likely to be on
a system, plus ensuring that any communications between the software
are done with either Sun stable interfaces ( like libc ) or through
proper IPC mechanisms ( like TCP ).

That, I believe, would cut down on bugs immensely and be a gigantic
improvement over the chaos of Linux distributions.



>         PKG-6: Packages will be upgraded as appropriate
>                through an automatic update facility and
>                notification to the user.

Absolutely not. If my machine does anything without my explicitly
telling it to, it's a bug at best and a security violation at worst.
-1x10^23

>         PKG-7: It should be possible to preserve the current
>                environment prior to an update so that a
>                rollback is possible in case of breakages.

+1. If zfs is used as the default filesystem, it's trivial to create a
snapshot before any major system updates are done

>    3.3) Familiarization
>
>         FAM-1: Provide a set of packages in the default install
>                and network repositories that users would typically
>                expect to see with a similar UNIX operating system
>                eg. GNU/Linux.

caveat: only if there's choice in the matter. Prompt on install if
/usr/gnu will be added to the front of $PATH so that I and other
comfortable Solaris users can say "no". for that matter, prompt if
/usr/gnu should be installed as well, so I can again choose "no"

>         FAM-2: Provide an environment such that migrating (particularly
>                GNU/Linux) users will be familiar with the utilities
>                available, while preserving the binary compatibility
>                story that people want and expect.

see above...


>         LAP-2: The user environment should support basic power
>                management, both suspend and resume. The user should
>                be notified when their battery is low, and offer to
>                shutdown or suspend. The system should also suspend
>                in times of inactivity.

This is still a problem with ON, and no amount of packaging things up
in novel ways will fix it.

>         LAP-3: The system should automatically connect to an available
>                network, whether through a network cable or wireless
>                connection.

No automatic, see my gripe with it before.

Fixed:
LAP-3: The system should prompt the user whether to automatically
connect to an available
               network, whether through a network cable or wireless connection.


>    3.5) Derivative Distributions
>
>         DST-1: Indiana should be created out of solely re-distributable,
>                modular binary components that are open source. Indiana
>                should value a strong commitment to freedom - the freedom to
>                download, run, copy, share, change and improve.

Sure, but that's part of the emancipation project. Given the choice
between GNU sed(1) and the closed source sed(1) in closed_bins, I'd
rather have the closed source but non-GNU copy


-- 
PGP Public Key 0x437AF1A1
Availiable on hkp://pgp.mit.edu