Girts,

No offense taken, but please, try being both more specific about what 
you're proposing and taking a less alarmist approach to making your points.

Girts Zeltins wrote:
> Hello,
> 
> Why I am writing this text, I am writing to talk about mistakes which
> is founding in Solaris in its future. I see two prototypes of
> installation system and I want to say all two are bad, sorry bad.
> Why? Because these graphical GUI which will need lots of memory to
> use. As we know that there are millions of people who wants to use
> Solaris on their machines but they cannot run it because it now need
> more memory than long time ago when there was Solaris 8. Sorry Sun
> guys, developers, you are making big mistake and this is bad for
> Solaris popularity and this is why people will prefer Linux!!! JDS
> which is now in Solaris Express Community Build 57 and Solaris
> Express Developer need more memory to run and there is no need such
> GUI as JDS (Java GNOME) but there is need clean GNOME where can be
> two Sun Microsystems created themes which can be used if you have
> very fast computer. Think please what you are doing! The one of

On what basis do you believe that we will end up requiring more memory? 
   Do you have data you can point to?  And what do you think is a 
reasonable memory requirement for a graphical installation?

We believe that, when all's said and done, the Caiman GUI will require 
no more memory than the current graphical installer.  We don't have data 
yet, either, but that's because we're only just starting to work out the 
design issues for the changes needed in supporting the new 
implementation.  I'm expecting we'll be able to keep the required memory 
around 512 MB for the graphical case.

> correct ways is to use Anaconda (Text, Graphical) installer and
> incorporate GParted technology for partitioning. There must be no
> need to use other partitioning tools to resize, delete partitions
> which are already on computer (QNX, FreeBSD, OpenBSD, BeOS, Linux,
> Windows,...)
> 

In the strategy I wrote a year ago and posted here, I suggested that we 
would investigate both Anaconda and GParted as technologies we might use 
for Caiman.  Some slides Sarah wrote summarizing our analysis of 
Anaconda are posted at

http://opensolaris.org/os/community/install/files/anaconda.pdf

Ultimately, we concluded that it didn't match our requirements sufficiently.

We also looked at GParted, though we didn't post a formal analysis.  Our 
main interest in providing it would be to include integrated shrinking 
of a Windows install to create space for Solaris; if you already have 
Linux installed and are adding Solaris, then there seems to be no need 
for us to supply a Solaris version of the tool since you already have 
it.  Once we actually looked at the code in libparted, we found that its 
current approach to shrinking NTFS was fundamentally unsafe, and 
probably not something we could support for our customers.  So at this 
point we're not intending to provide it, but if that support improves to 
where we believe it would be safe, then we'd perhaps reconsider.  Has it 
improved recently?

> There is need to rename project JDS to GNOME and allow people of
> community to work on improving GNOME and there must be new KDE
> project where people of community can work on discussing and
> recommendations for KDE in Solaris. This must be for CDE too and
> special community opened for CDE.
> 

This is the wrong forum for this particular discussion.  Try 
desktop-discuss at opensolaris.org.

> I want to ask developers to think again about Solaris future. Sorry
> Sun Microsystems, please think about people which don't have fast
> computers and think how to improve CDE!!!
> 

We're absolutely thinking about the Solaris future, and with our limited 
resources we actually tend to focus more on optimizing for that future 
than on the past.  We're not wholly insensitive to the desires of 
developers who don't have the latest and greatest hardware, but by the 
time Nevada becomes an actual Solaris release, does it make sense to 
optimize our decision-making around, say, systems with a single 1 GHz 
processor and 256 MB of memory?  It doesn't seem likely to me.

Dave

Reply via email to