|
Replies:
154
-
Last Post:
Nov 3, 2008 8:10 AM
by: gheet
|
|
|
Posts:
1,992
From:
US
Registered:
3/9/05
|
|
|
|
Posts:
542
From:
US
Registered:
11/22/05
|
|
|
|
Re: CD Space analysis and recommendations
Posted:
Aug 7, 2008 12:19 PM
in response to: dminer
|
|
HI
IIf I am not mistaken, SUNWsmagt is SNMP Agent and I wonder why we need
this within live CD. Probably some one need to look into to find out if
and how we can remove this dependency. Saving 4.5 Mb sounds like a good
start...
Just my 2c.
- Sriram
Dave Miner wrote:
> As we all know, the live CD has grown quite a bit since the 2008.05
> release. I've spent some time analyzing how we're using the space and
> where the growth between build 86 and build 94 occurred, and worked up
> some recommendations.
>
> The analysis data is now posted at:
>
> http://www.opensolaris.org/os/project/indiana/cd_space/
>
> The recommendations are posted at:
>
> http://www.opensolaris.org/os/project/indiana/cd_recommendations/
>
> I would especially appreciate feedback from the desktop, X, and l10n
> teams on the recommendations. We'll work up an actual plan once we've
> discussed a bit.
>
> Thanks go to Sanjay and Glynn for their assistance with this.
>
> Thanks,
> Dave
> _______________________________________________
> indiana-discuss mailing list
> indiana-discuss at opensolaris dot org
> http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
>
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
1,992
From:
US
Registered:
3/9/05
|
|
|
|
Re: CD Space analysis and recommendations
Posted:
Aug 7, 2008 2:52 PM
in response to: srinatar
|
|
Sriram Natarajan wrote:
> HI
> IIf I am not mistaken, SUNWsmagt is SNMP Agent and I wonder why we need
> this within live CD. Probably some one need to look into to find out if
> and how we can remove this dependency. Saving 4.5 Mb sounds like a good
> start...
>
Yes, it's the SNMP agent. The noted dependencies need to be examined,
but I believe based on some cursory inspection that neither one is a
hard dependency so that's why it's listed as a candidate package to remove.
Dave
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
5,504
From:
US
Registered:
3/9/05
|
|
|
|
Re: CD Space analysis and recommendations
Posted:
Aug 7, 2008 1:54 PM
in response to: dminer
|
|
Dave Miner wrote:
> As we all know, the live CD has grown quite a bit since the 2008.05
> release. I've spent some time analyzing how we're using the space and
> where the growth between build 86 and build 94 occurred, and worked up
> some recommendations.
>
> The analysis data is now posted at:
>
> http://www.opensolaris.org/os/project/indiana/cd_space/
>
> The recommendations are posted at:
>
> http://www.opensolaris.org/os/project/indiana/cd_recommendations/
>
> I would especially appreciate feedback from the desktop, X, and l10n
> teams on the recommendations. We'll work up an actual plan once we've
> discussed a bit.
>From the X perspective, dropping the screensaver hacks certainly makes sense
- they won't even be active in the default configuration, and are pure eye candy.
The fontconfig-docs are mostly developer documentation, so if we're not having
a full developer environment on the LiveCD, it doesn't make much sense to have
them either. (The only ones I'd think are really useful to the end-user
are the fonts.conf and fc-* utility man pages.)
For FSWxorg-fonts, all the PCF bitmap fonts are currently shipped as
*.gz files - we can also ship uncompressed if the LiveCD compression
is better than individually gzip'ed files, or as *.bz2 if minimal size
on the CD is most important. (In Solaris, we ship them uncompressed,
for best speed at runtime, and because the WOS media compresses the
entire cpio archive of the package at once, which gets much better
compression on our uncompressed files than gzip of each individual
file can get - and for many C locale fonts, the difference between a
16kb uncompressed font and a 12kb gzipped font is not any real disk
space - for Asian fonts the difference can be huge though).
Unfortunately, the *bz2 support is currently not working in Xorg, but
I'm working on fixing that.
--
-Alan Coopersmith- alan dot coopersmith at sun dot com
Sun Microsystems, Inc. - X Window System Engineering
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
20
From:
US
Registered:
2/19/08
|
|
|
|
Re: CD Space analysis and recommendations
Posted:
Aug 7, 2008 2:40 PM
in response to: alanc
|
|
Hi Dave, gang,
> As we all know, the live CD has grown quite a bit since the 2008.05
> release. I've spent some time analyzing how we're using the space and
> where the growth between build 86 and build 94 occurred, and worked up
> some recommendations.
>
> The analysis data is now posted at:
>
> http://www.opensolaris.org/os/project/indiana/cd_space/
>
> The recommendations are posted at:
>
> http://www.opensolaris.org/os/project/indiana/cd_recommendations/
>
> I would especially appreciate feedback from the desktop, X, and l10n
> teams on the recommendations. We'll work up an actual plan once we've
> discussed a bit.
As noted by the analysis data, it may prove difficult to remove
SUNWgnome-a11y-libs. Looking at the rest of the accessibility packages
(11MB), I suspect most of the 8MB Dasher package is from the very large
set of language models (including such critical languages as Klingon :-)
that we certainly don't need on a non-global CD.
For LiveCD accessible install support, the most significant use case is
unassisted installation by blind users. GOK & Dasher users are more
likely to have assistance with OS installation - their disabilities are
typically severe enough that these users generally need assistance with
overall computer setup, connecting cables, inserting media, etc. Blind
users by contrast typically don't need assistance with computer
setup/install, and we should avoid introducing a requirement for sighted
assistance in OpenSolaris for these users. Especially if the cost in
space is only 1.5 - 2.4MB (less than 0.4% of the CD).
Looking at the analysis and goals (to shrink by ~70MB), the CD
Recommendations page estimates 45MB savings from splitting 32- & 64-bit
kernel & libraries, plus another 25MB savings from fonts (together
totaling the 70MB goal). Remove another 6MB for include files, plus the
analyzed "redundant" packages for another 36MB, and you've saved 112MB -
significantly in excess of the 70MB target. If after all that, more
space is still needed, we could save another 8MB by dropping Dasher and
0.6MB by dropping GOK. I hope this will leave more than enough room to
keep the 10-11.4MB needed for blind accessibility on the Live CD, while
still having lots of room left over for driver growth, etc.
I also note that while the other distros don't include all of the
accessibility functionality on their Live CDs, Ubuntu at least includes
blind accessibility with theirs. In fact, that inclusion is one of the
main reason why Ubuntu is one of the most popular distros among blind
users on the Orca mailing list. We should at least do that much. That
said, my preference would be to also keep GOK & Dasher for the main
languages if possible. If my guess is correct, Dasher for the languages
supported on the LiveCD won't be very large (though it'll take a little
work to separate out core language from the remainder).
Regards,
Peter Korn
Accessibility Architect & Principal Engineer,
Sun Microsystems, Inc.
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
1,992
From:
US
Registered:
3/9/05
|
|
|
|
Re: CD Space analysis and recommendations
Posted:
Aug 8, 2008 8:45 AM
in response to: peterkor
|
|
Peter Korn wrote:
> Hi Dave, gang,
>
>> As we all know, the live CD has grown quite a bit since the 2008.05
>> release. I've spent some time analyzing how we're using the space and
>> where the growth between build 86 and build 94 occurred, and worked up
>> some recommendations.
>>
>> The analysis data is now posted at:
>>
>> http://www.opensolaris.org/os/project/indiana/cd_space/
>>
>> The recommendations are posted at:
>>
>> http://www.opensolaris.org/os/project/indiana/cd_recommendations/
>>
>> I would especially appreciate feedback from the desktop, X, and l10n
>> teams on the recommendations. We'll work up an actual plan once we've
>> discussed a bit.
>
> As noted by the analysis data, it may prove difficult to remove
> SUNWgnome-a11y-libs. Looking at the rest of the accessibility packages
> (11MB), I suspect most of the 8MB Dasher package is from the very large
> set of language models (including such critical languages as Klingon :-)
> that we certainly don't need on a non-global CD.
>
> For LiveCD accessible install support, the most significant use case is
> unassisted installation by blind users. GOK & Dasher users are more
> likely to have assistance with OS installation - their disabilities are
> typically severe enough that these users generally need assistance with
> overall computer setup, connecting cables, inserting media, etc. Blind
> users by contrast typically don't need assistance with computer
> setup/install, and we should avoid introducing a requirement for sighted
> assistance in OpenSolaris for these users. Especially if the cost in
> space is only 1.5 - 2.4MB (less than 0.4% of the CD).
>
Thanks for your feedback, Peter. Just to be clear about the suggestion
I made, in case you're not familiar with the product structure, we
presently ship two different live CD's. One has only the 14 primary
languages, while the second one (the global CD) contains all of those
plus the rest of the languages, and uses different (and slower)
compression technology to allow all of that to fit. This proposal
relates only to the primary languages CD. An unstated assumption (which
I probably should have stated, though it too is up for negotiation, I
guess) is that we will continue to ship those two CD versions because we
will not be able to spend time on improving the global CD's performance
before 2008.11. The global CD still has a fair bit of room on it; we
might apply some of the suggestions to it as well for consistency, but
there's currently no requirement to do so.
> Looking at the analysis and goals (to shrink by ~70MB), the CD
> Recommendations page estimates 45MB savings from splitting 32- & 64-bit
> kernel & libraries, plus another 25MB savings from fonts (together
> totaling the 70MB goal). Remove another 6MB for include files, plus the
> analyzed "redundant" packages for another 36MB, and you've saved 112MB -
> significantly in excess of the 70MB target. If after all that, more
In reality, each avenue has some cost inequality, of course, and some
may not be achievable in time for 2008.11, so we might have to take some
expedient and less palatable choices for the short term. Also, some
have drawbacks. For example, splitting 32- and 64-bit can make it
harder for users to obtain a CD that works on their platform, and
potentially complicates stocking and distribution. We chose to split
along languages because we think that's an easier choice for users to
make - they almost certainly know what languages they want to use and
that will be consistent, while having both 32- and 64-bit platforms in
their environment is highly likely (especially since virtualization
technologies like VirtualBox emulate only 32-bit presently) and thus the
distro download size effectively doubles. I'm personally not in favor
of this one because of that issue; I've included it as a potential
choice since I knew it would be brought up.
> space is still needed, we could save another 8MB by dropping Dasher and
> 0.6MB by dropping GOK. I hope this will leave more than enough room to
> keep the 10-11.4MB needed for blind accessibility on the Live CD, while
> still having lots of room left over for driver growth, etc.
> I also note that while the other distros don't include all of the
> accessibility functionality on their Live CDs, Ubuntu at least includes
> blind accessibility with theirs. In fact, that inclusion is one of the
> main reason why Ubuntu is one of the most popular distros among blind
> users on the Orca mailing list. We should at least do that much. That
> said, my preference would be to also keep GOK & Dasher for the main
> languages if possible. If my guess is correct, Dasher for the languages
> supported on the LiveCD won't be very large (though it'll take a little
> work to separate out core language from the remainder).
>
Yes, Will has continually reminded me of Ubuntu's popularity here ;-)
I'd appreciate some help in estimating the size reduction possible in
Dasher, that would be a useful option for us to consider. Will also
suggested I've mistakenly included SUNWspeex here, though if anyone can
comment on that I'd appreciate it.
Dave
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
20
From:
US
Registered:
2/19/08
|
|
|
|
Re: CD Space analysis and recommendations
Posted:
Aug 8, 2008 10:17 AM
in response to: dminer
|
|
Hi Dave,
> Peter Korn wrote:
>> Hi Dave, gang,
>>
>>> As we all know, the live CD has grown quite a bit since the 2008.05
>>> release. I've spent some time analyzing how we're using the space and
>>> where the growth between build 86 and build 94 occurred, and worked
>>> up some recommendations.
>>>
>>> The analysis data is now posted at:
>>>
>>> http://www.opensolaris.org/os/project/indiana/cd_space/
>>>
>>> The recommendations are posted at:
>>>
>>> http://www.opensolaris.org/os/project/indiana/cd_recommendations/
>>>
>>> I would especially appreciate feedback from the desktop, X, and l10n
>>> teams on the recommendations. We'll work up an actual plan once
>>> we've discussed a bit.
>>
>> As noted by the analysis data, it may prove difficult to remove
>> SUNWgnome-a11y-libs. Looking at the rest of the accessibility
>> packages (11MB), I suspect most of the 8MB Dasher package is from the
>> very large set of language models (including such critical languages
>> as Klingon :-) that we certainly don't need on a non-global CD.
>>
>> For LiveCD accessible install support, the most significant use case
>> is unassisted installation by blind users. GOK & Dasher users are
>> more likely to have assistance with OS installation - their
>> disabilities are typically severe enough that these users generally
>> need assistance with overall computer setup, connecting cables,
>> inserting media, etc. Blind users by contrast typically don't need
>> assistance with computer setup/install, and we should avoid
>> introducing a requirement for sighted assistance in OpenSolaris for
>> these users. Especially if the cost in space is only 1.5 - 2.4MB
>> (less than 0.4% of the CD).
>>
>
> Thanks for your feedback, Peter. Just to be clear about the
> suggestion I made, in case you're not familiar with the product
> structure, we presently ship two different live CD's. One has only
> the 14 primary languages, while the second one (the global CD)
> contains all of those plus the rest of the languages, and uses
> different (and slower) compression technology to allow all of that to
> fit. This proposal relates only to the primary languages CD. An
> unstated assumption (which I probably should have stated, though it
> too is up for negotiation, I guess) is that we will continue to ship
> those two CD versions because we will not be able to spend time on
> improving the global CD's performance before 2008.11. The global CD
> still has a fair bit of room on it; we might apply some of the
> suggestions to it as well for consistency, but there's currently no
> requirement to do so.
I appreciate the distinction, and the time pressure. Given the fact
that there is no guarantee that we will continue to ship a global
LiveCD, that the accessibility bits we can remove (especially for blind
LiveCD installation support) are small, and that we haven't finished
evaluating all of the options for removing things we don't need to ship,
I would very much like us to keep the option of shipping the primary
languages LiveCD with accessibility support on the table.
>> Looking at the analysis and goals (to shrink by ~70MB), the CD
>> Recommendations page estimates 45MB savings from splitting 32- &
>> 64-bit kernel & libraries, plus another 25MB savings from fonts
>> (together totaling the 70MB goal). Remove another 6MB for include
>> files, plus the analyzed "redundant" packages for another 36MB, and
>> you've saved 112MB - significantly in excess of the 70MB target. If
>> after all that, more
>
> In reality, each avenue has some cost inequality, of course, and some
> may not be achievable in time for 2008.11, so we might have to take
> some expedient and less palatable choices for the short term. Also,
> some have drawbacks. For example, splitting 32- and 64-bit can make
> it harder for users to obtain a CD that works on their platform, and
> potentially complicates stocking and distribution. We chose to split
> along languages because we think that's an easier choice for users to
> make - they almost certainly know what languages they want to use and
> that will be consistent, while having both 32- and 64-bit platforms in
> their environment is highly likely (especially since virtualization
> technologies like VirtualBox emulate only 32-bit presently) and thus
> the distro download size effectively doubles. I'm personally not in
> favor of this one because of that issue; I've included it as a
> potential choice since I knew it would be brought up.
Understood. It's great to see the other e-mails in this thread with
thoughtful suggestions for ways we can trim space. Again I come back to
how little we save by pulling accessibility - especially (again) the
support for blind users.
>> space is still needed, we could save another 8MB by dropping Dasher
>> and 0.6MB by dropping GOK. I hope this will leave more than enough
>> room to keep the 10-11.4MB needed for blind accessibility on the Live
>> CD, while still having lots of room left over for driver growth, etc.
>> I also note that while the other distros don't include all of the
>> accessibility functionality on their Live CDs, Ubuntu at least
>> includes blind accessibility with theirs. In fact, that inclusion is
>> one of the main reason why Ubuntu is one of the most popular distros
>> among blind users on the Orca mailing list. We should at least do
>> that much. That said, my preference would be to also keep GOK &
>> Dasher for the main languages if possible. If my guess is correct,
>> Dasher for the languages supported on the LiveCD won't be very large
>> (though it'll take a little work to separate out core language from
>> the remainder).
>>
>
> Yes, Will has continually reminded me of Ubuntu's popularity here ;-)
> I'd appreciate some help in estimating the size reduction possible in
> Dasher, that would be a useful option for us to consider. Will also
> suggested I've mistakenly included SUNWspeex here, though if anyone
> can comment on that I'd appreciate it.
I'm not sufficiently familiar with how packages are put together to give
you a solid estimate, but...
Dasher installs into /usr/bin/, /usr/share/gnome/help, /usr/share/omf,
and /usr/share. The language support is in /usr/share/dasher (all of
the "alphabet* and "training*" files). Collecting all of this together,
we have an installed size of ~22MB for Dasher. If we strip out the
non-English "alphabet*" and "training*" files, and a couple other things
that are obviously not needed for English use, we drop to an installed
size of 3.2MB. File-by-file gzipped, this minimal collection of files
is 975k. 931k if you gzip the tar file. If you can point me to the
list of 14 primary languages, I can refine the estimate. But it looks
like we should be able to trim most of the 8MB of a Dasher for the
primary languages LiveCD. Also - what compression technologies do we
use for these two LiveCDs?
Regards,
Peter Korn
Accessibility Architect & Principal Engineer,
Sun Microsystems, Inc.
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
1,992
From:
US
Registered:
3/9/05
|
|
|
|
Re: CD Space analysis and recommendations
Posted:
Aug 8, 2008 1:03 PM
in response to: peterkor
|
|
Hi Peter,
> I'm not sufficiently familiar with how packages are put together to give
> you a solid estimate, but...
> Dasher installs into /usr/bin/, /usr/share/gnome/help, /usr/share/omf,
> and /usr/share. The language support is in /usr/share/dasher (all of
> the "alphabet* and "training*" files). Collecting all of this together,
> we have an installed size of ~22MB for Dasher. If we strip out the
> non-English "alphabet*" and "training*" files, and a couple other things
> that are obviously not needed for English use, we drop to an installed
> size of 3.2MB. File-by-file gzipped, this minimal collection of files
> is 975k. 931k if you gzip the tar file. If you can point me to the
> list of 14 primary languages, I can refine the estimate. But it looks
> like we should be able to trim most of the 8MB of a Dasher for the
> primary languages LiveCD. Also - what compression technologies do we
> use for these two LiveCDs?
>
It's actually 12 languages, somehow I had the number wrong. The list is:
1. Chinese - Simplified
2. Chinese - Traditional
3. English
4. French
5. German
6. Italian
7. Japanese
8. Korean
9. Portuguese - Brazil
10. Russian
11. Spanish
12. Swedish
We're using gzip (default level 6) for the primary CD. The global one
uses lzma. (7z command does this on OpenSolaris).
Dave
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
20
From:
US
Registered:
2/19/08
|
|
|
|
Re: CD Space analysis and recommendations
Posted:
Aug 8, 2008 1:31 PM
in response to: dminer
|
|
Hi Dave,
> Hi Peter,
>
>> I'm not sufficiently familiar with how packages are put together to
>> give you a solid estimate, but...
>> Dasher installs into /usr/bin/, /usr/share/gnome/help,
>> /usr/share/omf, and /usr/share. The language support is in
>> /usr/share/dasher (all of the "alphabet* and "training*" files).
>> Collecting all of this together, we have an installed size of ~22MB
>> for Dasher. If we strip out the non-English "alphabet*" and
>> "training*" files, and a couple other things that are obviously not
>> needed for English use, we drop to an installed size of 3.2MB.
>> File-by-file gzipped, this minimal collection of files is 975k. 931k
>> if you gzip the tar file. If you can point me to the list of 14
>> primary languages, I can refine the estimate. But it looks like we
>> should be able to trim most of the 8MB of a Dasher for the primary
>> languages LiveCD. Also - what compression technologies do we use for
>> these two LiveCDs?
>>
>
> It's actually 12 languages, somehow I had the number wrong. The list is:
>
>
> 1. Chinese - Simplified
> 2. Chinese - Traditional
> 3. English
> 4. French
> 5. German
> 6. Italian
> 7. Japanese
> 8. Korean
> 9. Portuguese - Brazil
> 10. Russian
> 11. Spanish
> 12. Swedish
>
> We're using gzip (default level 6) for the primary CD. The global one
> uses lzma. (7z command does this on OpenSolaris).
OK. Dasher support for some of those languages is significant in size.
Using file-level gzip, we're looking at 4.8MB. Tar-gzip 4.7MB. Support
for many of those languages includes training files that, even when
compressed, are several hundred KB each; Spanish is particularly weighty
at 457KB gzipped.
So I return to my original request - let us please at least include
blind access in the 12-language LiveCD.
Regards,
Peter Korn
Accessibility Architect & Principal Engineer,
Sun Microsystems, Inc.
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
1,992
From:
US
Registered:
3/9/05
|
|
|
|
Re: CD Space analysis and recommendations
Posted:
Aug 11, 2008 11:18 AM
in response to: peterkor
|
|
Peter Korn wrote:
> Hi Dave,
>
>> Hi Peter,
>>
>>> I'm not sufficiently familiar with how packages are put together to
>>> give you a solid estimate, but...
>>> Dasher installs into /usr/bin/, /usr/share/gnome/help,
>>> /usr/share/omf, and /usr/share. The language support is in
>>> /usr/share/dasher (all of the "alphabet* and "training*" files).
>>> Collecting all of this together, we have an installed size of ~22MB
>>> for Dasher. If we strip out the non-English "alphabet*" and
>>> "training*" files, and a couple other things that are obviously not
>>> needed for English use, we drop to an installed size of 3.2MB.
>>> File-by-file gzipped, this minimal collection of files is 975k. 931k
>>> if you gzip the tar file. If you can point me to the list of 14
>>> primary languages, I can refine the estimate. But it looks like we
>>> should be able to trim most of the 8MB of a Dasher for the primary
>>> languages LiveCD. Also - what compression technologies do we use for
>>> these two LiveCDs?
>>>
>> It's actually 12 languages, somehow I had the number wrong. The list is:
>>
>>
>> 1. Chinese - Simplified
>> 2. Chinese - Traditional
>> 3. English
>> 4. French
>> 5. German
>> 6. Italian
>> 7. Japanese
>> 8. Korean
>> 9. Portuguese - Brazil
>> 10. Russian
>> 11. Spanish
>> 12. Swedish
>>
>> We're using gzip (default level 6) for the primary CD. The global one
>> uses lzma. (7z command does this on OpenSolaris).
>
> OK. Dasher support for some of those languages is significant in size.
> Using file-level gzip, we're looking at 4.8MB. Tar-gzip 4.7MB. Support
> for many of those languages includes training files that, even when
> compressed, are several hundred KB each; Spanish is particularly weighty
> at 457KB gzipped.
>
> So I return to my original request - let us please at least include
> blind access in the 12-language LiveCD.
>
Thanks for looking into this further. So, just to be clear, you'd be
requesting that we at most remove dasher and gok?
Dave
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
20
From:
US
Registered:
2/19/08
|
|
|
|
Re: CD Space analysis and recommendations
Posted:
Aug 11, 2008 11:44 AM
in response to: dminer
|
|
Hi Dave,
> Peter Korn wrote:
>> ...
>>
> So, just to be clear, you'd be requesting that we at most remove
> dasher and gok?
Yes.
Note that GOK, too, is small, and is focused on general desktop access
(vs. optimized entry of text for someone who has a severe physical
disability). So my full request is:
1. If you must remove accessibility stuff, start with Dasher languages
other than the "core 12"
2. If you still must remove stuff after that, remove all of Dasher (but
please keep it on the Global CD)
3. If that still isn't enough, then yes, remove GOK (but please keep it
on the Global CD)
4. But whatever you do, please don't remove Orca (from the 12 languages
CD or the Global CD)
Peter Korn
Accessibility Architect & Principal Engineer,
Sun Microsystems, Inc.
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
567
From:
Registered:
3/17/07
|
|
|
|
Re: CD Space analysis and recommendations
Posted:
Aug 8, 2008 1:36 PM
in response to: dminer
To: Projects » indiana » discuss
|
|
> The global CD still has a fair bit of room on it
Does that one use 7zip? Whatever compression it uses, is the faster compression on the standard image really worth the hassle of having people going out of their ways to cut space?
It sounds to me like using higher compression now and cutting down the fonts and java later is the best way to go.
|
|
|
|
|
Dave Miner
dminer@opensolaris.org
|
|
|
|
Re: CD Space analysis and recommendations
Posted:
Aug 8, 2008 2:08 PM
in response to: loomy
|
|
MC wrote:
>> The global CD still has a fair bit of room on it
>
> Does that one use 7zip? Whatever compression it uses, is the faster
> compression on the standard image really worth the hassle of having
> people going out of their ways to cut space?
>
Issuing only the lzma image was our original plan for 2008.05, but
because the performance wasn't satisfactory in a significant percentage
of cases, we decided to provide the two images. Best case, lzma is
about 50% slower, worst cases are several times slower.
> It sounds to me like using higher compression now and cutting down
> the fonts and java later is the best way to go.
Not viewed as an acceptable option at this point.
Dave
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
1,992
From:
US
Registered:
3/9/05
|
|
|
|
Re: CD Space analysis and recommendations
Posted:
Aug 7, 2008 3:01 PM
in response to: alanc
|
|
Thanks for the feedback, Alan.
Alan Coopersmith wrote:
> Dave Miner wrote:
>> As we all know, the live CD has grown quite a bit since the 2008.05
>> release. I've spent some time analyzing how we're using the space and
>> where the growth between build 86 and build 94 occurred, and worked up
>> some recommendations.
>>
>> The analysis data is now posted at:
>>
>> http://www.opensolaris.org/os/project/indiana/cd_space/
>>
>> The recommendations are posted at:
>>
>> http://www.opensolaris.org/os/project/indiana/cd_recommendations/
>>
>> I would especially appreciate feedback from the desktop, X, and l10n
>> teams on the recommendations. We'll work up an actual plan once we've
>> discussed a bit.
>
>>From the X perspective, dropping the screensaver hacks certainly makes sense
> - they won't even be active in the default configuration, and are pure eye candy.
>
> The fontconfig-docs are mostly developer documentation, so if we're not having
> a full developer environment on the LiveCD, it doesn't make much sense to have
> them either. (The only ones I'd think are really useful to the end-user
> are the fonts.conf and fc-* utility man pages.)
>
> For FSWxorg-fonts, all the PCF bitmap fonts are currently shipped as
> *.gz files - we can also ship uncompressed if the LiveCD compression
> is better than individually gzip'ed files, or as *.bz2 if minimal size
> on the CD is most important. (In Solaris, we ship them uncompressed,
> for best speed at runtime, and because the WOS media compresses the
> entire cpio archive of the package at once, which gets much better
> compression on our uncompressed files than gzip of each individual
> file can get - and for many C locale fonts, the difference between a
> 16kb uncompressed font and a 12kb gzipped font is not any real disk
> space - for Asian fonts the difference can be huge though).
> Unfortunately, the *bz2 support is currently not working in Xorg, but
> I'm working on fixing that.
>
An interesting set of options, I'm open to any of them and we can figure
out how to test some of them out. My main observation is that we appear
to be shipping a lot more fonts (not all of which come from
FSWxorg-fonts, I'm sure) than either of the Linux distros examined
(xlsfonts reports around 5200 for OpenSolaris, 2600-3000 for them,
corresponding file system area on Ubuntu is about 40% smaller). Can we
remove some with minimal impact on user experience? I'm not the expert
here, so you guys tell me what makes the most sense.
Dave
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
5,504
From:
US
Registered:
3/9/05
|
|
|
|
Re: CD Space analysis and recommendations
Posted:
Aug 7, 2008 3:15 PM
in response to: dminer
|
|
Dave Miner wrote:
> An interesting set of options, I'm open to any of them and we can figure
> out how to test some of them out. My main observation is that we appear
> to be shipping a lot more fonts (not all of which come from
> FSWxorg-fonts, I'm sure) than either of the Linux distros examined
> (xlsfonts reports around 5200 for OpenSolaris, 2600-3000 for them,
> corresponding file system area on Ubuntu is about 40% smaller). Can we
> remove some with minimal impact on user experience? I'm not the expert
> here, so you guys tell me what makes the most sense.
We can probably whittle down the set quite a bit if someone has time
to go through them. In Solaris, where the fonts are split into a
bunch of smaller packages, only a few of those packages are in the
miniroot used during install - certainly we don't plan to keep having
a single jumbo font package forever, it was just an expedient Moinak
did to get the LiveCD up and going that I've not had time to split into
more logical package boundaries (mostly because I want to make it go
away completely by getting back to the Solaris font packages, and then
refactoring those as previously discussed, but haven't had time for those
either).
--
-Alan Coopersmith- alan dot coopersmith at sun dot com
Sun Microsystems, Inc. - X Window System Engineering
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Moinak Ghosh
moinakg@belenix.org
|
|
|
|
Re: CD Space analysis and recommendations
Posted:
Aug 8, 2008 8:42 AM
in response to: alanc
|
|
On Fri, Aug 8, 2008 at 3:45 AM, Alan Coopersmith
<Alan dot Coopersmith at sun dot com> wrote:
> Dave Miner wrote:
>> An interesting set of options, I'm open to any of them and we can figure
>> out how to test some of them out. My main observation is that we appear
>> to be shipping a lot more fonts (not all of which come from
>> FSWxorg-fonts, I'm sure) than either of the Linux distros examined
>> (xlsfonts reports around 5200 for OpenSolaris, 2600-3000 for them,
>> corresponding file system area on Ubuntu is about 40% smaller). Can we
>> remove some with minimal impact on user experience? I'm not the expert
>> here, so you guys tell me what makes the most sense.
>
> We can probably whittle down the set quite a bit if someone has time
> to go through them. In Solaris, where the fonts are split into a
> bunch of smaller packages, only a few of those packages are in the
> miniroot used during install - certainly we don't plan to keep having
> a single jumbo font package forever, it was just an expedient Moinak
> did to get the LiveCD up and going that I've not had time to split into
> more logical package boundaries (mostly because I want to make it go
> away completely by getting back to the Solaris font packages, and then
> refactoring those as previously discussed, but haven't had time for those
> either).
This is something I can take a look at.
Regards,
Moinak.
>
> --
> -Alan Coopersmith- alan dot coopersmith at sun dot com
> Sun Microsystems, Inc. - X Window System Engineering
>
> _______________________________________________
> indiana-discuss mailing list
> indiana-discuss at opensolaris dot org
> http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
>
--
================================
http://www.belenix.org/
http://moinakg.wordpress.com/
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
3,657
From:
DE
Registered:
6/16/05
|
|
|
|
Removing fonts in Indiana ? / was: Re: CD Space
analysis and recommendations
Posted:
Aug 10, 2008 5:34 PM
in response to: dminer
|
|
Dave Miner wrote:
[snip]
> Alan Coopersmith wrote:
> > Dave Miner wrote:
[snip]
> An interesting set of options, I'm open to any of them and we can figure
> out how to test some of them out. My main observation is that we appear
> to be shipping a lot more fonts (not all of which come from
> FSWxorg-fonts, I'm sure) than either of the Linux distros examined
> (xlsfonts reports around 5200 for OpenSolaris, 2600-3000 for them,
> corresponding file system area on Ubuntu is about 40% smaller). Can we
> remove some with minimal impact on user experience? I'm not the expert
> here, so you guys tell me what makes the most sense.
I wouldn't recommend removing fonts. Indiana already has a big problem
because it lacks many many of the commercial fonts shipped with Solaris
making the "font experience" of users not very good (compared to what
ships to a full install of Solaris 10) and some locales have real
problems because glyphs are missing. IMO we _urgendly_ need more fonts
installed by default and not less.
For the space issue there may be several options:
1. Use better font compression (e.g. *.bz2 vs. *.gz) as discussed in
this thread (or none if we use LOFI compression, see item [4] below)
2. Combine some of the bitmap (BDF/PCF) fonts into TrueType wrappers
3. Teach the Xserver font code to do bitmap font re-encoding itself
(currently Xorg ships one *-iso10646-1 font re-encoded for each of the
*-iso8859-* encoding). This isn't much since the matching re-encoded
fonts usually only contain up to 256 glyphs but it's still some space
used-up
4. Assuming we use LOFI compression one option may be to re-order the
listing of the font files in a way that the re-encoded fonts come
directly after the *-iso10646-1 master font. Since the glyphs in the
re-encoded fonts are repeated in the *-iso10646-1 master fonts the
compression will catch this and reduce the re-encoded fonts to dust.
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland dot mainz at nrubsig dot org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 3992797
(;O/ \/ \O;)
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Moinak Ghosh
moinakg@belenix.org
|
|
|
|
Re: Removing fonts in Indiana ? / was: Re: CD
Space analysis and recommendations
Posted:
Aug 11, 2008 6:39 AM
in response to: gisburn
|
|
On Mon, Aug 11, 2008 at 6:04 AM, Roland Mainz <roland dot mainz at nrubsig dot org> wrote:
> Dave Miner wrote:
> [snip]
>> Alan Coopersmith wrote:
>> > Dave Miner wrote:
> [snip]
>> An interesting set of options, I'm open to any of them and we can figure
>> out how to test some of them out. My main observation is that we appear
>> to be shipping a lot more fonts (not all of which come from
>> FSWxorg-fonts, I'm sure) than either of the Linux distros examined
>> (xlsfonts reports around 5200 for OpenSolaris, 2600-3000 for them,
>> corresponding file system area on Ubuntu is about 40% smaller). Can we
>> remove some with minimal impact on user experience? I'm not the expert
>> here, so you guys tell me what makes the most sense.
>
> I wouldn't recommend removing fonts. Indiana already has a big problem
> because it lacks many many of the commercial fonts shipped with Solaris
> making the "font experience" of users not very good (compared to what
> ships to a full install of Solaris 10) and some locales have real
> problems because glyphs are missing. IMO we _urgendly_ need more fonts
> installed by default and not less.
But are many of the fonts included going to be really be used ? I doubt
if some of the older fonts really are a substitute of the commercial fonts
in Solaris.
>
> For the space issue there may be several options:
> 1. Use better font compression (e.g. *.bz2 vs. *.gz) as discussed in
> this thread (or none if we use LOFI compression, see item [4] below)
> 2. Combine some of the bitmap (BDF/PCF) fonts into TrueType wrappers
> 3. Teach the Xserver font code to do bitmap font re-encoding itself
> (currently Xorg ships one *-iso10646-1 font re-encoded for each of the
> *-iso8859-* encoding). This isn't much since the matching re-encoded
> fonts usually only contain up to 256 glyphs but it's still some space
> used-up
> 4. Assuming we use LOFI compression one option may be to re-order the
> listing of the font files in a way that the re-encoded fonts come
> directly after the *-iso10646-1 master font. Since the glyphs in the
> re-encoded fonts are repeated in the *-iso10646-1 master fonts the
> compression will catch this and reduce the re-encoded fonts to dust.
This will not help. Every segment in lofi is compressed independently.
A single common dictionary is not used. It is one possible enhancement
that has been in my mind for a while but not yet gotten around to
actually implementing it.
Regards,
Moinak.
>
> ----
>
> Bye,
> Roland
>
> --
> __ . . __
> (o.\ \/ /.o) roland dot mainz at nrubsig dot org
> \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
> /O /==\ O\ TEL +49 641 3992797
> (;O/ \/ \O;)
> _______________________________________________
> indiana-discuss mailing list
> indiana-discuss at opensolaris dot org
> http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
>
--
================================
http://www.belenix.org/
http://moinakg.wordpress.com/
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
1,992
From:
US
Registered:
3/9/05
|
|
|
|
Re: Removing fonts in Indiana ? / was: Re:
CD Space analysis and recommendations
Posted:
Aug 11, 2008 12:29 PM
in response to: Moinak Ghosh
|
|
Moinak Ghosh wrote:
> On Mon, Aug 11, 2008 at 6:04 AM, Roland Mainz <roland dot mainz at nrubsig dot org> wrote:
>> Dave Miner wrote:
>> [snip]
>>> Alan Coopersmith wrote:
>>>> Dave Miner wrote:
>> [snip]
>>> An interesting set of options, I'm open to any of them and we can figure
>>> out how to test some of them out. My main observation is that we appear
>>> to be shipping a lot more fonts (not all of which come from
>>> FSWxorg-fonts, I'm sure) than either of the Linux distros examined
>>> (xlsfonts reports around 5200 for OpenSolaris, 2600-3000 for them,
>>> corresponding file system area on Ubuntu is about 40% smaller). Can we
>>> remove some with minimal impact on user experience? I'm not the expert
>>> here, so you guys tell me what makes the most sense.
>> I wouldn't recommend removing fonts. Indiana already has a big problem
>> because it lacks many many of the commercial fonts shipped with Solaris
>> making the "font experience" of users not very good (compared to what
>> ships to a full install of Solaris 10) and some locales have real
>> problems because glyphs are missing. IMO we _urgendly_ need more fonts
>> installed by default and not less.
>
> But are many of the fonts included going to be really be used ? I doubt
> if some of the older fonts really are a substitute of the commercial fonts
> in Solaris.
>
I don't think it's a matter of number of fonts, but picking the right
ones. All the fonts in the world won't help if they're all lousy ;-)
For what it's worth, SXCE build 95 appears to ship with about half as
many fonts in the miniroot as OpenSolaris, which puts it in the same
neighborhood as the numbers I found on Ubuntu and Fedora. That set
looks like it uses around 22 MB; if we get into that range, that goes a
long way toward solving the current problem.
>> For the space issue there may be several options:
>> 1. Use better font compression (e.g. *.bz2 vs. *.gz) as discussed in
>> this thread (or none if we use LOFI compression, see item [4] below)
>> 2. Combine some of the bitmap (BDF/PCF) fonts into TrueType wrappers
>> 3. Teach the Xserver font code to do bitmap font re-encoding itself
>> (currently Xorg ships one *-iso10646-1 font re-encoded for each of the
>> *-iso8859-* encoding). This isn't much since the matching re-encoded
>> fonts usually only contain up to 256 glyphs but it's still some space
>> used-up
>> 4. Assuming we use LOFI compression one option may be to re-order the
>> listing of the font files in a way that the re-encoded fonts come
>> directly after the *-iso10646-1 master font. Since the glyphs in the
>> re-encoded fonts are repeated in the *-iso10646-1 master fonts the
>> compression will catch this and reduce the re-encoded fonts to dust.
>
> This will not help. Every segment in lofi is compressed independently.
> A single common dictionary is not used. It is one possible enhancement
> that has been in my mind for a while but not yet gotten around to
> actually implementing it.
>
Yeah, that would be interesting to look into.
Dave
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
167
From:
CZ
Registered:
12/6/07
|
|
|
|
Re: Removing fonts in Indiana ? / was: Re: CD
Space analysis and recommendations
Posted:
Aug 27, 2008 3:43 AM
in response to: gisburn
|
|
Hi Roland,
Roland Mainz wrote:
> Dave Miner wrote:
> [snip]
>> Alan Coopersmith wrote:
>>> Dave Miner wrote:
> [snip]
>> An interesting set of options, I'm open to any of them and we can figure
>> out how to test some of them out. My main observation is that we appear
>> to be shipping a lot more fonts (not all of which come from
>> FSWxorg-fonts, I'm sure) than either of the Linux distros examined
>> (xlsfonts reports around 5200 for OpenSolaris, 2600-3000 for them,
>> corresponding file system area on Ubuntu is about 40% smaller). Can we
>> remove some with minimal impact on user experience? I'm not the expert
>> here, so you guys tell me what makes the most sense.
>
> I wouldn't recommend removing fonts. Indiana already has a big problem
> because it lacks many many of the commercial fonts shipped with Solaris
> making the "font experience" of users not very good (compared to what
> ships to a full install of Solaris 10) and some locales have real
> problems because glyphs are missing. IMO we _urgendly_ need more fonts
> installed by default and not less.
Could you please describe in more detail what areas (applications?) are
problematic, what locales have missing glyph issues etc.?
I think there are certainly font files that could be removed with little
or no impact. One thing I don't understand is why there are Vera* fonts
while the DejaVu project builds on these.
Is there any document describing the planned [font] cuts?
Regards,
hnhn
[snip]
> ----
>
> Bye,
> Roland
>
--
Jan Hnatek
jan dot hnatek at sun dot com
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
1,992
From:
US
Registered:
3/9/05
|
|
|
|
Re: Removing fonts in Indiana ? / was: Re: CD
Space analysis and recommendations
Posted:
Aug 27, 2008 8:27 AM
in response to: hnhn
|
|
Jan Hnatek wrote:
> Hi Roland,
>
> Roland Mainz wrote:
>> Dave Miner wrote:
>> [snip]
>>> Alan Coopersmith wrote:
>>>> Dave Miner wrote:
>> [snip]
>>> An interesting set of options, I'm open to any of them and we can figure
>>> out how to test some of them out. My main observation is that we appear
>>> to be shipping a lot more fonts (not all of which come from
>>> FSWxorg-fonts, I'm sure) than either of the Linux distros examined
>>> (xlsfonts reports around 5200 for OpenSolaris, 2600-3000 for them,
>>> corresponding file system area on Ubuntu is about 40% smaller). Can we
>>> remove some with minimal impact on user experience? I'm not the expert
>>> here, so you guys tell me what makes the most sense.
>>
>> I wouldn't recommend removing fonts. Indiana already has a big problem
>> because it lacks many many of the commercial fonts shipped with Solaris
>> making the "font experience" of users not very good (compared to what
>> ships to a full install of Solaris 10) and some locales have real
>> problems because glyphs are missing. IMO we _urgendly_ need more fonts
>> installed by default and not less.
>
> Could you please describe in more detail what areas (applications?) are
> problematic, what locales have missing glyph issues etc.?
>
> I think there are certainly font files that could be removed with little
> or no impact. One thing I don't understand is why there are Vera* fonts
> while the DejaVu project builds on these.
>
> Is there any document describing the planned [font] cuts?
>
I'm waiting for a proposal from Moinak.
Dave
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Moinak Ghosh
moinakg@belenix.org
|
|
|
|
Re: CD Space analysis and recommendations
Posted:
Aug 8, 2008 8:39 AM
in response to: alanc
|
|
On Fri, Aug 8, 2008 at 2:24 AM, Alan Coopersmith
<Alan dot Coopersmith at sun dot com> wrote:
> Dave Miner wrote:
>> As we all know, the live CD has grown quite a bit since the 2008.05
>> release. I've spent some time analyzing how we're using the space and
>> where the growth between build 86 and build 94 occurred, and worked up
>> some recommendations.
>>
>> The analysis data is now posted at:
>>
>> http://www.opensolaris.org/os/project/indiana/cd_space/
>>
>> The recommendations are posted at:
>>
>> http://www.opensolaris.org/os/project/indiana/cd_recommendations/
>>
>> I would especially appreciate feedback from the desktop, X, and l10n
>> teams on the recommendations. We'll work up an actual plan once we've
>> discussed a bit.
>
> >From the X perspective, dropping the screensaver hacks certainly makes sense
> - they won't even be active in the default configuration, and are pure eye candy.
>
> The fontconfig-docs are mostly developer documentation, so if we're not having
> a full developer environment on the LiveCD, it doesn't make much sense to have
> them either. (The only ones I'd think are really useful to the end-user
> are the fonts.conf and fc-* utility man pages.)
>
> For FSWxorg-fonts, all the PCF bitmap fonts are currently shipped as
> *.gz files - we can also ship uncompressed if the LiveCD compression
> is better than individually gzip'ed files, or as *.bz2 if minimal size
> on the CD is most important. (In Solaris, we ship them uncompressed,
> for best speed at runtime, and because the WOS media compresses the
> entire cpio archive of the package at once, which gets much better
> compression on our uncompressed files than gzip of each individual
> file can get - and for many C locale fonts, the difference between a
> 16kb uncompressed font and a 12kb gzipped font is not any real disk
> space - for Asian fonts the difference can be huge though).
> Unfortunately, the *bz2 support is currently not working in Xorg, but
> I'm working on fixing that.
The segment by segment compression in Lofi is inferior to stream compression
of whole files. Of course this changes a bit if we are using LZMA.
However even
in that case LZMA can further reduce *.gz files. So leaving the
*.gz PCF files as
is will be better.
Regards,
Moinak.
>
> --
> -Alan Coopersmith- alan dot coopersmith at sun dot com
> Sun Microsystems, Inc. - X Window System Engineering
>
> _______________________________________________
> indiana-discuss mailing list
> indiana-discuss at opensolaris dot org
> http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
>
--
================================
http://www.belenix.org/
http://moinakg.wordpress.com/
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
1,992
From:
US
Registered:
3/9/05
|
|
|
|
Re: CD Space analysis and recommendations
Posted:
Aug 8, 2008 12:43 PM
in response to: Moinak Ghosh
|
|
Moinak Ghosh wrote:
> On Fri, Aug 8, 2008 at 2:24 AM, Alan Coopersmith
> <Alan dot Coopersmith at sun dot com> wrote:
>> Dave Miner wrote:
>>> As we all know, the live CD has grown quite a bit since the 2008.05
>>> release. I've spent some time analyzing how we're using the space and
>>> where the growth between build 86 and build 94 occurred, and worked up
>>> some recommendations.
>>>
>>> The analysis data is now posted at:
>>>
>>> http://www.opensolaris.org/os/project/indiana/cd_space/
>>>
>>> The recommendations are posted at:
>>>
>>> http://www.opensolaris.org/os/project/indiana/cd_recommendations/
>>>
>>> I would especially appreciate feedback from the desktop, X, and l10n
>>> teams on the recommendations. We'll work up an actual plan once we've
>>> discussed a bit.
>> >From the X perspective, dropping the screensaver hacks certainly makes sense
>> - they won't even be active in the default configuration, and are pure eye candy.
>>
>> The fontconfig-docs are mostly developer documentation, so if we're not having
>> a full developer environment on the LiveCD, it doesn't make much sense to have
>> them either. (The only ones I'd think are really useful to the end-user
>> are the fonts.conf and fc-* utility man pages.)
>>
>> For FSWxorg-fonts, all the PCF bitmap fonts are currently shipped as
>> *.gz files - we can also ship uncompressed if the LiveCD compression
>> is better than individually gzip'ed files, or as *.bz2 if minimal size
>> on the CD is most important. (In Solaris, we ship them uncompressed,
>> for best speed at runtime, and because the WOS media compresses the
>> entire cpio archive of the package at once, which gets much better
>> compression on our uncompressed files than gzip of each individual
>> file can get - and for many C locale fonts, the difference between a
>> 16kb uncompressed font and a 12kb gzipped font is not any real disk
>> space - for Asian fonts the difference can be huge though).
>> Unfortunately, the *bz2 support is currently not working in Xorg, but
>> I'm working on fixing that.
>
> The segment by segment compression in Lofi is inferior to stream compression
> of whole files. Of course this changes a bit if we are using LZMA.
> However even
> in that case LZMA can further reduce *.gz files. So leaving the
> *.gz PCF files as
> is will be better.
>
Agreed, though using gzip-9 (if you're not already) or getting bz2
working would help some. Note that we've found that the 7z tool does a
better job of gzip compressing than gzip itself, so that might be
checked into.
Also, Moinak, thanks for volunteering to look at the package structure.
One thing I should have said in the original mail is that I'm
targeting having the plan defined by Sept. 1 in order to have time to
implement any changes needed, so getting some indication of the
possibilities here in the next couple of weeks would be helpful.
Dave
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Moinak Ghosh
moinakg@belenix.org
|
|
|
|
Re: CD Space analysis and recommendations
Posted:
Aug 11, 2008 11:06 AM
in response to: dminer
|
|
On Sat, Aug 9, 2008 at 1:13 AM, Dave Miner <Dave dot Miner at sun dot com> wrote:
> Moinak Ghosh wrote:
>>
>> On Fri, Aug 8, 2008 at 2:24 AM, Alan Coopersmith
>> <Alan dot Coopersmith at sun dot com> wrote:
>>>
>>> Dave Miner wrote:
>>>>
>>>> As we all know, the live CD has grown quite a bit since the 2008.05
>>>> release. I've spent some time analyzing how we're using the space and
>>>> where the growth between build 86 and build 94 occurred, and worked up
>>>> some recommendations.
>>>>
>>>> The analysis data is now posted at:
>>>>
>>>> http://www.opensolaris.org/os/project/indiana/cd_space/
>>>>
>>>> The recommendations are posted at:
>>>>
>>>> http://www.opensolaris.org/os/project/indiana/cd_recommendations/
>>>>
>>>> I would especially appreciate feedback from the desktop, X, and l10n
>>>> teams on the recommendations. We'll work up an actual plan once we've
>>>> discussed a bit.
>>>
>>> >From the X perspective, dropping the screensaver hacks certainly makes
>>> sense
>>> - they won't even be active in the default configuration, and are pure
>>> eye candy.
>>>
>>> The fontconfig-docs are mostly developer documentation, so if we're not
>>> having
>>> a full developer environment on the LiveCD, it doesn't make much sense to
>>> have
>>> them either. (The only ones I'd think are really useful to the end-user
>>> are the fonts.conf and fc-* utility man pages.)
>>>
>>> For FSWxorg-fonts, all the PCF bitmap fonts are currently shipped as
>>> *.gz files - we can also ship uncompressed if the LiveCD compression
>>> is better than individually gzip'ed files, or as *.bz2 if minimal size
>>> on the CD is most important. (In Solaris, we ship them uncompressed,
>>> for best speed at runtime, and because the WOS media compresses the
>>> entire cpio archive of the package at once, which gets much better
>>> compression on our uncompressed files than gzip of each individual
>>> file can get - and for many C locale fonts, the difference between a
>>> 16kb uncompressed font and a 12kb gzipped font is not any real disk
>>> space - for Asian fonts the difference can be huge though).
>>> Unfortunately, the *bz2 support is currently not working in Xorg, but
>>> I'm working on fixing that.
>>
>> The segment by segment compression in Lofi is inferior to stream
>> compression
>> of whole files. Of course this changes a bit if we are using LZMA.
>> However even
>> in that case LZMA can further reduce *.gz files. So leaving the
>> *.gz PCF files as
>> is will be better.
>>
>
> Agreed, though using gzip-9 (if you're not already) or getting bz2 working
> would help some. Note that we've found that the 7z tool does a better job
> of gzip compressing than gzip itself, so that might be checked into.
>
> Also, Moinak, thanks for volunteering to look at the package structure.
> One thing I should have said in the original mail is that I'm targeting
> having the plan defined by Sept. 1 in order to have time to implement any
> changes needed, so getting some indication of the possibilities here in the
> next couple of weeks would be helpful.
I will get you an estimate in the next 2 days. I will also post some
suggested font packages on xwin-discuss in a few days.
Regards,
Moinak.
>
> Dave
>
>
--
================================
http://www.belenix.org/
http://moinakg.wordpress.com/
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
104
From:
CN
Registered:
1/12/06
|
|
|
|
Re: CD Space analysis and recommendations
Posted:
Aug 7, 2008 8:14 PM
in response to: dminer
|
|
On Thu, 2008-08-07 at 14:53 -0400, Dave Miner wrote:
> As we all know, the live CD has grown quite a bit since the 2008.05
> release. I've spent some time analyzing how we're using the space and
> where the growth between build 86 and build 94 occurred, and worked up
> some recommendations.
>
> The analysis data is now posted at:
>
> http://www.opensolaris.org/os/project/indiana/cd_space/
>
> The recommendations are posted at:
>
> http://www.opensolaris.org/os/project/indiana/cd_recommendations/
>
I saw SUWNgnome-pilot and SUNWpilot-link are planed to be removed, but
they are run time dependency of SUNWevolution.
Harry
> I would especially appreciate feedback from the desktop, X, and l10n
> teams on the recommendations. We'll work up an actual plan once we've
> discussed a bit.
>
> Thanks go to Sanjay and Glynn for their assistance with this.
>
> Thanks,
> Dave
> _______________________________________________
> indiana-discuss mailing list
> indiana-discuss at opensolaris dot org
> http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
--
Harry dot Lu at Sun dot COM
Solaris Desktop Group, Sun Microsystems
Tel: +86-10-82618200 ext. 82870/ +86-10-62673870
Fax: +86-10-62780969
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
1,992
From:
US
Registered:
3/9/05
|
|
|
|
Re: CD Space analysis and recommendations
Posted:
Aug 8, 2008 12:34 PM
in response to: harrylu
|
|
Harry Lu wrote:
> On Thu, 2008-08-07 at 14:53 -0400, Dave Miner wrote:
>> As we all know, the live CD has grown quite a bit since the 2008.05
>> release. I've spent some time analyzing how we're using the space and
>> where the growth between build 86 and build 94 occurred, and worked up
>> some recommendations.
>>
>> The analysis data is now posted at:
>>
>> http://www.opensolaris.org/os/project/indiana/cd_space/
>>
>> The recommendations are posted at:
>>
>> http://www.opensolaris.org/os/project/indiana/cd_recommendations/
>>
>
> I saw SUWNgnome-pilot and SUNWpilot-link are planed to be removed, but
> they are run time dependency of SUNWevolution.
>
Sigh. At least they're small. Is there any reason they necessarily
have to be dependencies of Evolution? In other words, is this a design
dependency or merely the way we configure our build of Evolution?
Dave
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
104
From:
CN
Registered:
1/12/06
|
|
|
|
Re: CD Space analysis and recommendations
Posted:
Aug 8, 2008 6:58 PM
in response to: dminer
|
|
Dave Miner wrote:
> Harry Lu wrote:
>
>> On Thu, 2008-08-07 at 14:53 -0400, Dave Miner wrote:
>>
>>> As we all know, the live CD has grown quite a bit since the 2008.05
>>> release. I've spent some time analyzing how we're using the space and
>>> where the growth between build 86 and build 94 occurred, and worked up
>>> some recommendations.
>>>
>>> The analysis data is now posted at:
>>>
>>> http://www.opensolaris.org/os/project/indiana/cd_space/
>>>
>>> The recommendations are posted at:
>>>
>>> http://www.opensolaris.org/os/project/indiana/cd_recommendations/
>>>
>>>
>> I saw SUWNgnome-pilot and SUNWpilot-link are planed to be removed, but
>> they are run time dependency of SUNWevolution.
>>
>>
>
> Sigh. At least they're small. Is there any reason they necessarily
> have to be dependencies of Evolution? In other words, is this a design
> dependency or merely the way we configure our build of Evolution?
>
I would say it is a design dependency. Evolution depends on them to do
Addressbook/Calendar sync with Palm devices. If you really want to
remove sth. from Evolution packages, I would suggest you to remove
SUNWevolution-jescs and SUNWevolution-exchange. They are Evolution
connectors to our Sun Calendar server and MS exchange server.
This is just from my developer's view. Maybe marketing people won't agree.
Harry
> Dave
> _______________________________________________
> indiana-discuss mailing list
> indiana-discuss at opensolaris dot org
> http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
>
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
86
From:
Beijing
Registered:
1/4/07
|
|
|
|
Re: CD Space analysis and recommendations
Posted:
Aug 8, 2008 11:53 PM
in response to: harrylu
|
|
I myself am not technical enough to make any technical recommendations.
However, I wonder a lot by the fact that we have both thunderbird and
evolution on single CD.
("`-''-/").___..--''"`-._ Qingye Jiang (John)
`6_ 6 ) `-. ( ).`-.__.`) Senior Manager
(_Y_.)' ._ ) `._ `. ``-..- Sun Developer Network, China
_..`--'_..-_/ /--'_.' ,' Phone: +86-10-62673347
(il),-'' (li),' ((!.-' http://developers.sun.com.cn/
-----------------------------------------------------------------------
About ME: visit http://www.qyjohn.net/, http://calendar.qyjohn.net/.
About US: visit http://wiki.developers.sun.com.cn/index.php/SDN_China .
Harry Lu 写道:
> Dave Miner wrote:
>
>> Harry Lu wrote:
>>
>>
>>> On Thu, 2008-08-07 at 14:53 -0400, Dave Miner wrote:
>>>
>>>
>>>> As we all know, the live CD has grown quite a bit since the 2008.05
>>>> release. I've spent some time analyzing how we're using the space and
>>>> where the growth between build 86 and build 94 occurred, and worked up
>>>> some recommendations.
>>>>
>>>> The analysis data is now posted at:
>>>>
>>>> http://www.opensolaris.org/os/project/indiana/cd_space/
>>>>
>>>> The recommendations are posted at:
>>>>
>>>> http://www.opensolaris.org/os/project/indiana/cd_recommendations/
>>>>
>>>>
>>>>
>>> I saw SUWNgnome-pilot and SUNWpilot-link are planed to be removed, but
>>> they are run time dependency of SUNWevolution.
>>>
>>>
>>>
>> Sigh. At least they're small. Is there any reason they necessarily
>> have to be dependencies of Evolution? In other words, is this a design
>> dependency or merely the way we configure our build of Evolution?
>>
>>
> I would say it is a design dependency. Evolution depends on them to do
> Addressbook/Calendar sync with Palm devices. If you really want to
> remove sth. from Evolution packages, I would suggest you to remove
> SUNWevolution-jescs and SUNWevolution-exchange. They are Evolution
> connectors to our Sun Calendar server and MS exchange server.
>
> This is just from my developer's view. Maybe marketing people won't agree.
>
> Harry
>
>> Dave
>> _______________________________________________
>> indiana-discuss mailing list
>> indiana-discuss at opensolaris dot org
>> http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
>>
>>
>
> _______________________________________________
> indiana-discuss mailing list
> indiana-discuss at opensolaris dot org
> http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
>
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
1,992
From:
US
Registered:
3/9/05
|
|
|
|
Re: CD Space analysis and recommendations
Posted:
Aug 11, 2008 11:54 AM
in response to: qjiang
|
|
Qingye Jiang (John) wrote:
> I myself am not technical enough to make any technical recommendations.
> However, I wonder a lot by the fact that we have both thunderbird and
> evolution on single CD.
>
The primary reason is that, based on the data I have (what I see in my
folders, plus a survey last year of Linux users[1]), Thunderbird is at
least as popular as Evolution, with both having significantly large user
bases. I would be happy to receive pointers to more recent or
higher-quality data.
To answer a later query from another poster, the sizes are roughly:
Thunderbird: 19 MB
Evolution: 11 MB
Dave
[1] http://www.desktoplinux.com/news/NS8454912761.html
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Chris Ridd
chrisridd@mac.com
|
|
|
|
Re: CD Space analysis and recommendations
Posted:
Aug 9, 2008 10:57 AM
in response to: harrylu
|
|
On 9 Aug 2008, at 02:58, Harry Lu wrote:
> I would say it is a design dependency. Evolution depends on them to do
> Addressbook/Calendar sync with Palm devices. If you really want to
> remove sth. from Evolution packages, I would suggest you to remove
> SUNWevolution-jescs and SUNWevolution-exchange. They are Evolution
> connectors to our Sun Calendar server and MS exchange server.
Is there a good reason for including Evolution (and these dependent
packages) in the first place?
Thunderbird fills the role of a POP/IMAP/SMTP client, and has plugins
for talking to various calendar servers.
I don't think Thunderbird has native (ie non-IMAP) Exchange support,
but maybe Exchange users aren't really a target for OpenSolaris anyway.
Cheers,
Chris
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
1,032
From:
US
Registered:
3/24/06
|
|
|
|
Re: CD Space analysis and recommendations
Posted:
Aug 9, 2008 11:49 AM
in response to: Chris Ridd
|
|
It meshes better with GNOME, and it has exchange 2000/2003 connectors
with current versions, 2007 very soon. Theoretically it uses less
resources since it shares GNOME components, and I find it to be more
accessible from a business-minded workflow, as the contacts, calendar
and memos are better integrated. Google support (webcal) is another
perk. I argue the opposite, why Thunderbird? No major player Linux or
otherwise bundles Thunderbird or ticks it by default if the user is
using GNOME. Thunderbird isn't like Firefox where there's an immediate
dependence on rendering through gecko, or particular font needs, it's
e-mail, and e-mail doesn't depend on all the whiz bang things like a
browser does. I find Thunderbird to be redundant, and a waste of space
because it doubles the library requirements as most Mozilla programs are
self-contained for management reasons, while I can still argue there's
nothing wrong with a client sharing GNOME resources since I've never
seen any installation of Evolution fail outright because of upgrades and
the like.
The audience could still be those who have migrated their desktops to
Linux and are using Evolution, Zimbra and Exchange to migrate, but are
apt to try OpenSolaris as well granted it's capable. Thunderbird has no
commercial acceptance. I use Thunderbird on Windows, but as is with
most Mozilla technology, Windows support is a front-most thought in
their development process, while Evolution's bread and butter through
the years has been GTK+ on UNIX-like systems, and I find it to
compliment the environment just as some users on Windows are apt to
prefer Outlook over Thunderbird due to how the program operates. Same
can be said about those who prefer Cocoa over Carbon, Safari over
Firefox on Mac OS X. What fits best? What is less redundant? What is
more capable and fits a wide audience? What about licensing? What
about cost and business sustainability? Thunderbird ranks under in most
categories, though it is definitively acceptable for all home users, Sun
also has a big investment in business adoption.
James
On Sat, 2008-08-09 at 18:57 +0100, Chris Ridd wrote:
> On 9 Aug 2008, at 02:58, Harry Lu wrote:
>
> > I would say it is a design dependency. Evolution depends on them to do
> > Addressbook/Calendar sync with Palm devices. If you really want to
> > remove sth. from Evolution packages, I would suggest you to remove
> > SUNWevolution-jescs and SUNWevolution-exchange. They are Evolution
> > connectors to our Sun Calendar server and MS exchange server.
>
> Is there a good reason for including Evolution (and these dependent
> packages) in the first place?
>
> Thunderbird fills the role of a POP/IMAP/SMTP client, and has plugins
> for talking to various calendar servers.
>
> I don't think Thunderbird has native (ie non-IMAP) Exchange support,
> but maybe Exchange users aren't really a target for OpenSolaris anyway.
>
> Cheers,
>
> Chris
> _______________________________________________
> indiana-discuss mailing list
> indiana-discuss at opensolaris dot org
> http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Chris Ridd
chrisridd@mac.com
|
|
|
|
Re: CD Space analysis and recommendations
Posted:
Aug 10, 2008 1:56 AM
in response to: sparcdr
|
|
On 9 Aug 2008, at 19:49, James Cornell wrote:
> It meshes better with GNOME, and it has exchange 2000/2003 connectors
> with current versions, 2007 very soon. Theoretically it uses less
> resources since it shares GNOME components, and I find it to be more
> accessible from a business-minded workflow, as the contacts, calendar
> and memos are better integrated. Google support (webcal) is another
> perk. I argue the opposite, why Thunderbird? No major player Linux
> or
> otherwise bundles Thunderbird or ticks it by default if the user is
> using GNOME. Thunderbird isn't like Firefox where there's an
> immediate
> dependence on rendering through gecko, or particular font needs, it's
> e-mail, and e-mail doesn't depend on all the whiz bang things like a
> browser does. I find Thunderbird to be redundant, and a waste of
> space
> because it doubles the library requirements as most Mozilla programs
> are
> self-contained for management reasons, while I can still argue there's
> nothing wrong with a client sharing GNOME resources since I've never
> seen any installation of Evolution fail outright because of upgrades
> and
> the like.
That's a reasonable argument too. As long as you could still install
Thunderbird from pkg.opensolaris.org I'd be fine with dropping it from
the CD. How much space would it save?
Cheers,
Chris
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
1,032
From:
US
Registered:
3/24/06
|
|
|
|
Re: CD Space analysis and recommendations
Posted:
Aug 10, 2008 12:53 PM
in response to: Chris Ridd
|
|
Depends on the compression used for the package, but the contrib pkgadd file (bzip2) is 13MB for the GTK+2 variant of Thunderbird 2.0.0.16. Unpacked and installed, somewhere around double that, 26MB. On Windows Thunderbird uses about 24.3MB unpacked/installed as well.
The only reason I can see Thunderbird was included in addition to Firefox would be past issues with IMAP handling, which have been fixed post GNOME 2.20.1, while we are now founding on 2.22.x+ on Nevada. The other less likely reason is the hype behind Firefox weighing in to prospect users who want to ****** and grab any Mozilla product because it's Mozilla. Much like people don't care about redundant Google desktop apps, since hey, it's Google!
Evolution has a plugin architecture, and also supports LDAP, which is important to businesses. There aren't any real critical add-ons that would tie someone to Thunderbird, unlike the situation of Firefox and Firebug for example. Thunderbird too has support though limited in some areas with regards to LDAP since it's more self-contained, but for the audience this is not a real detriment as long as certain preparatory actions are made on the back-ends. Update size could be another reason to drop it, since they insist on upgrading all of Thunderbird as a bundle, as opposed to Evolution, where a particular dependency that's comparable to what's bundled in Thunderbird can simply be upgraded without costing many users bandwidth. It's unfortunate that the internet is expensive to run, and that most nations have to pay for every gigabyte, but for upgrading a few household computers a few times for our international users can be really annoying for something pitched as gratis and libre. There's a cost to redundancy you can't have the whole cake, and usually the whole cake just annoys users and makes them confused anyway.
Cheers, James On Aug 10, 2008, at 3:56 AM, Chris Ridd wrote: On 9 Aug 2008, at 19:49, James Cornell wrote: It meshes better with GNOME, and it has exchange 2000/2003 connectors
with current versions, 2007 very soon. Theoretically it uses less
resources since it shares GNOME components, and I find it to be more
accessible from a business-minded workflow, as the contacts, calendar
and memos are better integrated. Google support (webcal) is another
perk. I argue the opposite, why Thunderbird? No major player Linux
or
otherwise bundles Thunderbird or ticks it by default if the user is
using GNOME. Thunderbird isn't like Firefox where there's an
immediate
dependence on rendering through gecko, or particular font needs, it's
e-mail, and e-mail doesn't depend on all the whiz bang things like a
browser does. I find Thunderbird to be redundant, and a waste of
space
because it doubles the library requirements as most Mozilla programs
are
self-contained for management reasons, while I can still argue there's
nothing wrong with a client sharing GNOME resources since I've never
seen any installation of Evolution fail outright because of upgrades
and
the like.
That's a reasonable argument too. As long as you could still install Thunderbird from pkg.opensolaris.org I'd be fine with dropping it from the CD. How much space would it save? Cheers, Chris __________________________________________ _____ indiana-discuss mailing list indiana-discuss at opensolaris dot orghttp://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Laszlo (Laca) P...
Laszlo.Peter@Sun.COM
|
|
|
|
Re: CD Space analysis and recommendations
Posted:
Aug 10, 2008 6:49 PM
in response to: dminer
|
|
On Fri, 2008-08-08 at 15:34 -0400, Dave Miner wrote:
> >> The recommendations are posted at:
> >>
> >> http://www.opensolaris.org/os/project/indiana/cd_recommendations/
> >>
> > I saw SUWNgnome-pilot and SUNWpilot-link are planed to be removed, but
> > they are run time dependency of SUNWevolution.
> >
>
> Sigh. At least they're small. Is there any reason they necessarily
> have to be dependencies of Evolution? In other words, is this a design
> dependency or merely the way we configure our build of Evolution?
Similarly, SUNWgnome-camera is a dependency of SUNWgnome-img-organizer
(because gthumb can also import photos from your camera via gphoto2).
Removing gdesklets is fine, I think, they never worked for me anyway (;
Need to verify how gtk+ links to cups. It has a cups printing backend
but it will probably work fine without it. Cc'ing Ghee to confirm.
Laca
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
815
From:
IE
Registered:
6/15/05
|
|
|
|
Re: CD Space analysis and recommendations
Posted:
Aug 11, 2008 3:57 AM
in response to: Laszlo (Laca) P...
|
|
Laszlo (Laca) Peter wrote:
> On Fri, 2008-08-08 at 15:34 -0400, Dave Miner wrote:
>
>> >> The recommendations are posted at:
>>
>>>> http://www.opensolaris.org/os/project/indiana/cd_recommendations/
>>>>
>>>>
>>> I saw SUWNgnome-pilot and SUNWpilot-link are planed to be removed, but
>>> they are run time dependency of SUNWevolution.
>>>
>>>
>> Sigh. At least they're small. Is there any reason they necessarily
>> have to be dependencies of Evolution? In other words, is this a design
>> dependency or merely the way we configure our build of Evolution?
>>
>
> Similarly, SUNWgnome-camera is a dependency of SUNWgnome-img-organizer
> (because gthumb can also import photos from your camera via gphoto2).
>
> Removing gdesklets is fine, I think, they never worked for me anyway (;
>
> Need to verify how gtk+ links to cups. It has a cups printing backend
> but it will probably work fine without it. Cc'ing Ghee to confirm.
>
Unfortunately, removing libcups.so will cause the applications to
exit when the GTK+
print dialog is brought up regardless of print system used at the time.
So we can't remove
SUNWcups without further engineering work.
While we are on printing, we could remove potential not to put
SUNWgnome-print*
on the live CD which for most part contained the community obsoleted
libgnomeprint[ui] and
its header files, but that will break 2 applications,
ghex2 and gnome-dictionary(also the dictionary applet).
Due to the obsoletion trend, these two apps may eventually moved over
to GTK+ print dialog.
So, the question is that are 2 two applications important enough to be
on live CD? [1]
-Ghee
[1] I have an impression that gnome-dictionary is very visible by the
amount of l10N it has in the spec files.
> Laca
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> indiana-discuss mailing list
> indiana-discuss at opensolaris dot org
> http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
>
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
815
From:
IE
Registered:
6/15/05
|
|
|
|
Re: CD Space analysis and recommendations
Posted:
Aug 11, 2008 7:12 AM
in response to: gheet
|
|
Ghee Teo wrote:
>
> While we are on printing, we could remove potential not to put
> SUNWgnome-print*
> on the live CD which for most part contained the community obsoleted
> libgnomeprint[ui] and
> its header files, but that will break 2 applications,
>
> ghex2 and gnome-dictionary(also the dictionary applet).
>
> Due to the obsoletion trend, these two apps may eventually moved over
> to GTK+ print dialog.
> So, the question is that are 2 two applications important enough to be
> on live CD? [1]
I have confirmation from the GNOME maintainer that gnome-dictionary
will have the GTK+ print dialog in GNOME 2.24.
ghex2 is not part GNOME blessed app, so there is less likely that the
its dependency on libgnomeprint will be replaced any time so. However,
looking at the UI of ghex2, I suggest SUNWgnome-hex-editor* can be
removed from the liveCD even.
-Ghee
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
1,992
From:
US
Registered:
3/9/05
|
|
|
|
Re: CD Space analysis and recommendations
Posted:
Aug 11, 2008 1:32 PM
in response to: gheet
|
|
Ghee Teo wrote:
> Ghee Teo wrote:
>> While we are on printing, we could remove potential not to put
>> SUNWgnome-print*
>> on the live CD which for most part contained the community obsoleted
>> libgnomeprint[ui] and
>> its header files, but that will break 2 applications,
>>
>> ghex2 and gnome-dictionary(also the dictionary applet).
>>
>> Due to the obsoletion trend, these two apps may eventually moved over
>> to GTK+ print dialog.
>> So, the question is that are 2 two applications important enough to be
>> on live CD? [1]
> I have confirmation from the GNOME maintainer that gnome-dictionary
> will have the GTK+ print dialog in GNOME 2.24.
> ghex2 is not part GNOME blessed app, so there is less likely that the
> its dependency on libgnomeprint will be replaced any time so. However,
> looking at the UI of ghex2, I suggest SUNWgnome-hex-editor* can be
> removed from the liveCD even.
>
SUNWgnome-hex-editor is not on the CD, so that'll be simple ;-)
So, if I understand correctly, SUNWgnome-print (1 MB in size) looks like
it's removable?
Dave
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
815
From:
IE
Registered:
6/15/05
|
|
|
|
Re: CD Space analysis and recommendations
Posted:
Aug 12, 2008 4:40 AM
in response to: dminer
|
|
Dave Miner wrote:
> Ghee Teo wrote:
>
>> Ghee Teo wrote:
>>
>>> While we are on printing, we could remove potential not to put
>>> SUNWgnome-print*
>>> on the live CD which for most part contained the community obsoleted
>>> libgnomeprint[ui] and
>>> its header files, but that will break 2 applications,
>>>
>>> ghex2 and gnome-dictionary(also the dictionary applet).
>>>
>>> Due to the obsoletion trend, these two apps may eventually moved over
>>> to GTK+ print dialog.
>>> So, the question is that are 2 two applications important enough to be
>>> on live CD? [1]
>>>
>> I have confirmation from the GNOME maintainer that gnome-dictionary
>> will have the GTK+ print dialog in GNOME 2.24.
>> ghex2 is not part GNOME blessed app, so there is less likely that the
>> its dependency on libgnomeprint will be replaced any time so. However,
>> looking at the UI of ghex2, I suggest SUNWgnome-hex-editor* can be
>> removed from the liveCD even.
>>
>>
>
> SUNWgnome-hex-editor is not on the CD, so that'll be simple ;-)
>
Excellent :)
> So, if I understand correctly, SUNWgnome-print (1 MB in size) looks like
> it's removable?
>
Yes. That is correct. We should be be libgnomeprint[ui] free on the
GNOME stack with 2.24 release.
-Ghee
> Dave
> _______________________________________________
> indiana-discuss mailing list
> indiana-discuss at opensolaris dot org
> http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
>
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
815
From:
IE
Registered:
6/15/05
|
|
|
|
Re: [indiana-discuss] CD Space analysis and recommendations
Posted:
Nov 3, 2008 8:10 AM
in response to: dminer
|
|
Hey Dave,
I dug out this old thread. SUNWgnome-print can be removed from Live CD,
but it seems to be on Live CD as of OS 100a on nana.
This should give your some space for other thing. May be there is room
for http://defect.opensolaris.org/bz/show_bug.cgi?id=2656
onky only my own biased view :)
-Ghee
>>
>
> SUNWgnome-hex-editor is not on the CD, so that'll be simple ;-)
>
> So, if I understand correctly, SUNWgnome-print (1 MB in size) looks like
> it's removable?
>
> Dave
> _______________________________________________
> indiana-discuss mailing list
> indiana-discuss at opensolaris dot org
> http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
>
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
1,992
From:
US
Registered:
3/9/05
|
|
|
|
Re: CD Space analysis and recommendations
Posted:
Aug 11, 2008 1:34 PM
in response to: gheet
|
|
Ghee Teo wrote:
> Laszlo (Laca) Peter wrote:
>> On Fri, 2008-08-08 at 15:34 -0400, Dave Miner wrote:
>>
>>> >> The recommendations are posted at:
>>>
>>>>> http://www.opensolaris.org/os/project/indiana/cd_recommendations/
>>>>>
>>>>>
>>>> I saw SUWNgnome-pilot and SUNWpilot-link are planed to be removed, but
>>>> they are run time dependency of SUNWevolution.
>>>>
>>>>
>>> Sigh. At least they're small. Is there any reason they necessarily
>>> have to be dependencies of Evolution? In other words, is this a design
>>> dependency or merely the way we configure our build of Evolution?
>>>
>> Similarly, SUNWgnome-camera is a dependency of SUNWgnome-img-organizer
>> (because gthumb can also import photos from your camera via gphoto2).
>>
>> Removing gdesklets is fine, I think, they never worked for me anyway (;
>>
>> Need to verify how gtk+ links to cups. It has a cups printing backend
>> but it will probably work fine without it. Cc'ing Ghee to confirm.
>>
> Unfortunately, removing libcups.so will cause the applications to
> exit when the GTK+
> print dialog is brought up regardless of print system used at the time.
> So we can't remove
> SUNWcups without further engineering work.
>
Can you estimate what portions of SUNWcups would need to be retained to
keep the print dialog functional?
Dave
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
815
From:
IE
Registered:
6/15/05
|
|
|
|
Re: CD Space analysis and recommendations
Posted:
Aug 12, 2008 4:42 AM
in response to: dminer
|
|
Dave Miner wrote:
> Ghee Teo wrote:
>
>> Laszlo (Laca) Peter wrote:
>>
>>> On Fri, 2008-08-08 at 15:34 -0400, Dave Miner wrote:
>>>
>>>
>>>> >> The recommendations are posted at:
>>>>
>>>>
>>>>>> http://www.opensolaris.org/os/project/indiana/cd_recommendations/
>>>>>>
>>>>>>
>>>>>>
>>>>> I saw SUWNgnome-pilot and SUNWpilot-link are planed to be removed, but
>>>>> they are run time dependency of SUNWevolution.
>>>>>
>>>>>
>>>>>
>>>> Sigh. At least they're small. Is there any reason they necessarily
>>>> have to be dependencies of Evolution? In other words, is this a design
>>>> dependency or merely the way we configure our build of Evolution?
>>>>
>>>>
>>> Similarly, SUNWgnome-camera is a dependency of SUNWgnome-img-organizer
>>> (because gthumb can also import photos from your camera via gphoto2).
>>>
>>> Removing gdesklets is fine, I think, they never worked for me anyway (;
>>>
>>> Need to verify how gtk+ links to cups. It has a cups printing backend
>>> but it will probably work fine without it. Cc'ing Ghee to confirm.
>>>
>>>
>> Unfortunately, removing libcups.so will cause the applications to
>> exit when the GTK+
>> print dialog is brought up regardless of print system used at the time.
>> So we can't remove
>> SUNWcups without further engineering work.
>>
>>
>
> Can you estimate what portions of SUNWcups would need to be retained to
> keep the print dialog functional?
>
My initial testing out showing that it needs libcups.so.* which is in
SUNWcupsu to
run Print Dialog in lp. Printing group owns this package and Norm is CCed.
-Ghee
> Dave
>
> _______________________________________________
> indiana-discuss mailing list
> indiana-discuss at opensolaris dot org
> http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
>
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
1,992
From:
US
Registered:
3/9/05
|
|
|
|
Re: CD Space analysis and recommendations
Posted:
Aug 11, 2008 3:18 PM
in response to: Laszlo (Laca) P...
|
|
Laszlo (Laca) Peter wrote:
> On Fri, 2008-08-08 at 15:34 -0400, Dave Miner wrote:
>> >> The recommendations are posted at:
>>>> http://www.opensolaris.org/os/project/indiana/cd_recommendations/
>>>>
>>> I saw SUWNgnome-pilot and SUNWpilot-link are planed to be removed, but
>>> they are run time dependency of SUNWevolution.
>>>
>> Sigh. At least they're small. Is there any reason they necessarily
>> have to be dependencies of Evolution? In other words, is this a design
>> dependency or merely the way we configure our build of Evolution?
>
> Similarly, SUNWgnome-camera is a dependency of SUNWgnome-img-organizer
> (because gthumb can also import photos from your camera via gphoto2).
>
I noticed it could do that, I was hoping the dependency wasn't that way.
In the same vein, I note that rhythmbox seems to be capable of
everything that sound-juicer does; any reason we couldn't dump sound-juicer?
Dave
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Laszlo (Laca) P...
Laszlo.Peter@Sun.COM
|
|
|
|
Re: CD Space analysis and recommendations
Posted:
Aug 11, 2008 6:38 PM
in response to: dminer
|
|
On Mon, 2008-08-11 at 18:18 -0400, Dave Miner wrote:
> In the same vein, I note that rhythmbox seems to be capable of
> everything that sound-juicer does; any reason we couldn't dump
> sound-juicer?
Except for ripping CDs, which is probably not something you want
to do when using a live CD, so I agree, sound juicer could be
dropped. That's SUNWgnome-cd.
Laca
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
1,992
From:
US
Registered:
3/9/05
|
|
|
|
Re: CD Space analysis and recommendations
Posted:
Aug 12, 2008 6:55 AM
in response to: Laszlo (Laca) P...
|
|
Laszlo (Laca) Peter wrote:
> On Mon, 2008-08-11 at 18:18 -0400, Dave Miner wrote:
>> In the same vein, I note that rhythmbox seems to be capable of
>> everything that sound-juicer does; any reason we couldn't dump
>> sound-juicer?
>
> Except for ripping CDs, which is probably not something you want
> to do when using a live CD, so I agree, sound juicer could be
> dropped. That's SUNWgnome-cd.
>
Actually, rhythmbox does a fine job of ripping an entire CD (it calls it
copy to library or something like that), though with less track-level
control than sound juicer.
Dave
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
1,992
From:
US
Registered:
3/9/05
|
|
|
|
Re: CD Space analysis and recommendations
Posted:
Aug 12, 2008 12:34 PM
in response to: Laszlo (Laca) P...
|
|
Laca,
There were two other GNOME packages that I was interested in
understanding if we can reduce:
SUNWgnome-themes 18.4 MB
SUNWgnome-xml 1.7 MB
Thoughts?
Dave
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Laszlo (Laca) P...
Laszlo.Peter@Sun.COM
|
|
|
|
Re: CD Space analysis and recommendations
Posted:
Aug 12, 2008 4:28 PM
in response to: dminer
|
|
On Tue, 2008-08-12 at 15:34 -0400, Dave Miner wrote:
> Laca,
>
> There were two other GNOME packages that I was interested in
> understanding if we can reduce:
>
> SUNWgnome-themes 18.4 MB
Most of the disk space in gnome-themes is used by the icons:
$ du -sk * | sort -n
5 LargePrint
23 hicolor
32 HighContrast
32 HighContrastInverse
273 HighContrastLargePrint
278 HighContrastLargePrintInverse
481 Crux
708 Neutral_Plus_Inv
928 Mist
1128 HighContrast-SVG
7956 Tango
9896 nimbus
12529 gnome
Not sure what Mist is, that's potentially something we can omit?
Maybe Crux too. We can move them into separate packages.
Tango is large and not required, but it's very popular on
Linux so it would be a shame not to have it in the default install.
> SUNWgnome-xml 1.7 MB
This package includes the docbook (and other) stylesheets and dtds.
I thought it was needed for online help work, but I've just tried
and it's not. Anyone knows any reason why we need this on the live
cd or in the default install?
Laca
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
1,901
From:
NZ
Registered:
6/16/05
|
|
|
|
Re: CD Space analysis and recommendations
Posted:
Aug 12, 2008 4:39 PM
in response to: Laszlo (Laca) P...
|
|
Hey,
On 13/08/2008, at 11:28 AM, Laszlo (Laca) Peter wrote:
> Most of the disk space in gnome-themes is used by the icons:
>
> $ du -sk * | sort -n
> 5 LargePrint
> 23 hicolor
> 32 HighContrast
> 32 HighContrastInverse
> 273 HighContrastLargePrint
> 278 HighContrastLargePrintInverse
> 481 Crux
> 708 Neutral_Plus_Inv
> 928 Mist
> 1128 HighContrast-SVG
> 7956 Tango
> 9896 nimbus
> 12529 gnome
>
> Not sure what Mist is, that's potentially something we can omit?
> Maybe Crux too. We can move them into separate packages.
> Tango is large and not required, but it's very popular on
> Linux so it would be a shame not to have it in the default install.
One thing that we may consider is getting rid of the higher scaled
images.
For example, within Nimbus we have the following icon sizes -
12x12 16x16 192x192 20x20 24x24 32x32 36x36 48x48 72x72 96x96
On a typical screen, which are the sizes we're most likely to use? I
suspect we *could* take everything http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Bob Friesenhahn
bfriesen@simple.dall...
|
|
|
|
Re: [desktop-discuss] CD Space analysis and
recommendations
Posted:
Aug 13, 2008 8:07 AM
in response to: gman
|
|
On Wed, 13 Aug 2008, Glynn Foster wrote:
>
> One thing that we may consider is getting rid of the higher scaled
> images.
It seems that many of the images are in PNG format. Given this, it is
worth investigating to see if these PNG files may be optimized for
smaller size using 'pngcrush' or a similar tool. I picked a file at
random from the themes provided with Solaris 10 and found that
'pngcrush' was able to optimize it to a smaller size, indicating that
these images are not yet optimized for size.
PNG is a very flexible format offering many ways to store the same
image.
Wasted space by the filesystem when storing tiny files may hinder
optimization efforts.
Bob
======================================
Bob Friesenhahn
bfriesen at simple dot dallas dot tx dot us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Laszlo (Laca) P...
Laszlo.Peter@Sun.COM
|
|
|
|
Re: [desktop-discuss] CD Space analysis
and recommendations
Posted:
Aug 14, 2008 4:46 AM
in response to: Bob Friesenhahn
|
|
On Wed, 2008-08-13 at 10:07 -0500, Bob Friesenhahn wrote:
> It seems that many of the images are in PNG format. Given this, it is
> worth investigating to see if these PNG files may be optimized for
> smaller size using 'pngcrush' or a similar tool. I picked a file at
> random from the themes provided with Solaris 10 and found that
> 'pngcrush' was able to optimize it to a smaller size, indicating that
> these images are not yet optimized for size.
>
> PNG is a very flexible format offering many ways to store the same
> image.
>
> Wasted space by the filesystem when storing tiny files may hinder
> optimization efforts.
I've tried this. Built pngcrush (now available in SFE) and
recompressed all pngs with the -brute option. The total
saving for /usr/share/icons was
852k (49884 -> 49032).
There's more space to be saved with the larger pixmaps like
background images (/usr/share/gnome/pixmaps/backgrounds/*)
312k (5372 -> 5060)
and the rest of the theme images (/usr/share/themes/*)
32k (3488 -> 3456)
So that's 1196k saved on SUNWgnome-themes.
Not sure how of this saving is left after the compression
during the CD image build, though.
Thanks for the suggestion!
Laca
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
1,992
From:
US
Registered:
3/9/05
|
|
|
|
Re: [desktop-discuss] CD Space analysis
and recommendations
Posted:
Aug 14, 2008 7:32 AM
in response to: Laszlo (Laca) P...
|
|
Laszlo (Laca) Peter wrote:
> On Wed, 2008-08-13 at 10:07 -0500, Bob Friesenhahn wrote:
>> It seems that many of the images are in PNG format. Given this, it is
>> worth investigating to see if these PNG files may be optimized for
>> smaller size using 'pngcrush' or a similar tool. I picked a file at
>> random from the themes provided with Solaris 10 and found that
>> 'pngcrush' was able to optimize it to a smaller size, indicating that
>> these images are not yet optimized for size.
>>
>> PNG is a very flexible format offering many ways to store the same
>> image.
>>
>> Wasted space by the filesystem when storing tiny files may hinder
>> optimization efforts.
>
> I've tried this. Built pngcrush (now available in SFE) and
> recompressed all pngs with the -brute option. The total
> saving for /usr/share/icons was
> 852k (49884 -> 49032).
> There's more space to be saved with the larger pixmaps like
> background images (/usr/share/gnome/pixmaps/backgrounds/*)
> 312k (5372 -> 5060)
> and the rest of the theme images (/usr/share/themes/*)
> 32k (3488 -> 3456)
> So that's 1196k saved on SUNWgnome-themes.
>
> Not sure how of this saving is left after the compression
> during the CD image build, though.
>
A reasonable estimate is obtained by just gzip'ing your results and
compare them to the gzip sizes I posted for the packages.
Dave
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
20
From:
US
Registered:
2/19/08
|
|
|
|
Re: CD Space analysis and recommendations
Posted:
Aug 12, 2008 5:09 PM
in response to: Laszlo (Laca) P...
|
|
Laca,
Are we using the HighContrast-SVG icons (are Cairo and SVG icon
generation working these days)? That seems to me like a good candidate
for being moved to a package that users download after they have
installed their system.
Regards,
Peter Korn
Accessibility Architect & Principal Engineer,
Sun Microsystems, Inc.
<pre wrap="">On Tue, 2008-08-12 at 15:34 -0400, Dave Miner wrote:
</pre>
<pre wrap="">Laca,
There were two other GNOME packages that I was interested in
understanding if we can reduce:
SUNWgnome-themes 18.4 MB
</pre>
<pre wrap=""><!---->
Most of the disk space in gnome-themes is used by the icons:
$ du -sk * | sort -n
5 LargePrint
23 hicolor
32 HighContrast
32 HighContrastInverse
273 HighContrastLargePrint
278 HighContrastLargePrintInverse
481 Crux
708 Neutral_Plus_Inv
928 Mist
1128 HighContrast-SVG
7956 Tango
9896 nimbus
12529 gnome
Not sure what Mist is, that's potentially something we can omit?
Maybe Crux too. We can move them into separate packages.
Tango is large and not required, but it's very popular on
Linux so it would be a shame not to have it in the default install.
</pre>
<blockquote type="cite">
<pre wrap="">SUNWgnome-xml 1.7 MB
</pre>
</blockquote>
<pre wrap=""><!---->
This package includes the docbook (and other) stylesheets and dtds.
I thought it was needed for online help work, but I've just tried
and it's not. Anyone knows any reason why we need this on the live
cd or in the default install?
Laca
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
</pre>
|
|
|
|
|
Posts:
1,992
From:
US
Registered:
3/9/05
|
|
|
|
Re: CD Space analysis and recommendations
Posted:
Aug 12, 2008 5:11 PM
in response to: Laszlo (Laca) P...
|
|
Laszlo (Laca) Peter wrote:
> On Tue, 2008-08-12 at 15:34 -0400, Dave Miner wrote:
>> Laca,
>>
>> There were two other GNOME packages that I was interested in
>> understanding if we can reduce:
>>
>> SUNWgnome-themes 18.4 MB
>
> Most of the disk space in gnome-themes is used by the icons:
>
> $ du -sk * | sort -n
> 5 LargePrint
> 23 hicolor
> 32 HighContrast
> 32 HighContrastInverse
> 273 HighContrastLargePrint
> 278 HighContrastLargePrintInverse
> 481 Crux
> 708 Neutral_Plus_Inv
> 928 Mist
> 1128 HighContrast-SVG
> 7956 Tango
> 9896 nimbus
> 12529 gnome
>
> Not sure what Mist is, that's potentially something we can omit?
> Maybe Crux too. We can move them into separate packages.
> Tango is large and not required, but it's very popular on
> Linux so it would be a shame not to have it in the default install.
>
My thought is that we're branding the distro using Nimbus, so anything
else is something you can add after installation, though we may want
some of the high contrast stuff for accessibility.
>> SUNWgnome-xml 1.7 MB
>
> This package includes the docbook (and other) stylesheets and dtds.
> I thought it was needed for online help work, but I've just tried
> and it's not. Anyone knows any reason why we need this on the live
> cd or in the default install?
>
Yeah, looking at it I couldn't figure out what it would be used for.
Dave
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
124
From:
FR
Registered:
10/4/06
|
|
|
|
Re: [desktop-discuss] CD Space analysis
and recommendations
Posted:
Aug 13, 2008 1:49 AM
in response to: dminer
|
|
Dave Miner wrote:
> Laszlo (Laca) Peter wrote:
>
>> On Tue, 2008-08-12 at 15:34 -0400, Dave Miner wrote:
>>
>>> Laca,
>>>
>>> There were two other GNOME packages that I was interested in
>>> understanding if we can reduce:
>>>
>>> SUNWgnome-themes 18.4 MB
>>>
>> Most of the disk space in gnome-themes is used by the icons:
>>
>> $ du -sk * | sort -n
>> 5 LargePrint
>> 23 hicolor
>> 32 HighContrast
>> 32 HighContrastInverse
>> 273 HighContrastLargePrint
>> 278 HighContrastLargePrintInverse
>> 481 Crux
>> 708 Neutral_Plus_Inv
>> 928 Mist
>> 1128 HighContrast-SVG
>> 7956 Tango
>> 9896 nimbus
>> 12529 gnome
>>
>> Not sure what Mist is, that's potentially something we can omit?
>> Maybe Crux too. We can move them into separate packages.
>> Tango is large and not required, but it's very popular on
>> Linux so it would be a shame not to have it in the default install.
>>
>>
>
> My thought is that we're branding the distro using Nimbus, so anything
> else is something you can add after installation, though we may want
> some of the high contrast stuff for accessibility.
>
The Nimbus icon set falls back to Tango icon set if the required icons
are not present. In turn the Tango icon set
falls back to gnome icon set.
So we need to keep at least the nimbus, tango and gnome icon set.
Erwann
>
>>> SUNWgnome-xml 1.7 MB
>>>
>> This package includes the docbook (and other) stylesheets and dtds.
>> I thought it was needed for online help work, but I've just tried
>> and it's not. Anyone knows any reason why we need this on the live
>> cd or in the default install?
>>
>>
>
> Yeah, looking at it I couldn't figure out what it would be used for.
>
> Dave
>
>
> _______________________________________________
> desktop-discuss mailing list
> desktop-discuss at opensolaris dot org
>
--
Erwann Chénedé,
Desktop Group, Sun Microsystems, Grenoble
Phone : +33 476 188 358 ext: 38358
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
986
From:
IE
Registered:
7/14/05
|
|
|
|
Re: CD Space analysis and recommendations
Posted:
Aug 13, 2008 6:15 AM
in response to: Laszlo (Laca) P...
|
|
On 13 Aug 2008, at 00:28, Laszlo (Laca) Peter wrote:
> On Tue, 2008-08-12 at 15:34 -0400, Dave Miner wrote:
>> Laca,
>>
>> There were two other GNOME packages that I was interested in
>> understanding if we can reduce:
>>
>> SUNWgnome-themes 18.4 MB
>
> Most of the disk space in gnome-themes is used by the icons:
>
> $ du -sk * | sort -n
> 5 LargePrint
> 23 hicolor
> 32 HighContrast
> 32 HighContrastInverse
> 273 HighContrastLargePrint
> 278 HighContrastLargePrintInverse
> 481 Crux
> 708 Neutral_Plus_Inv
> 928 Mist
> 1128 HighContrast-SVG
> 7956 Tango
> 9896 nimbus
> 12529 gnome
>
> Not sure what Mist is, that's potentially something we can omit?
> Maybe Crux too. We can move them into separate packages.
> Tango is large and not required, but it's very popular on
> Linux so it would be a shame not to have it in the default install.
Nimbus (our default theme) also has a loose dependency on Tango--if an
icon doesn't exist in Nimbus, the first fallback theme it tries is
Tango. This was a deliberate choice--the usual fallback for other
themes is gnome first, then hicolor.
I'd say we can drop the HighContrast-SVG icon theme for now, though--
it's still experimental, and as such it's not (yet) the icon theme
that's actually used by the HighContrast desktop theme. That will
change at some point, but then we should be able to drop the
HighContrastLargePrint icon theme instead.
Cheeri,
Calum.
--
CALUM BENSON, Usability Engineer Sun Microsystems Ireland
mailto:calum dot benson at sun dot com GNOME Desktop Team
http://blogs.sun.com/calum +353 1 819 9771
Any opinions are personal and not necessarily those of Sun Microsystems
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Mark Phalan
mbp@opensolaris.org
|
|
|
|
Re: CD Space analysis and recommendations
Posted:
Aug 13, 2008 1:34 PM
in response to: calumb
|
|
On Wed, 2008-08-13 at 14:15 +0100, Calum Benson wrote:
> On 13 Aug 2008, at 00:28, Laszlo (Laca) Peter wrote:
>
> > On Tue, 2008-08-12 at 15:34 -0400, Dave Miner wrote:
> >> Laca,
> >>
> >> There were two other GNOME packages that I was interested in
> >> understanding if we can reduce:
> >>
> >> SUNWgnome-themes 18.4 MB
> >
> > Most of the disk space in gnome-themes is used by the icons:
> >
> > $ du -sk * | sort -n
> > 5 LargePrint
> > 23 hicolor
> > 32 HighContrast
> > 32 HighContrastInverse
> > 273 HighContrastLargePrint
> > 278 HighContrastLargePrintInverse
> > 481 Crux
> > 708 Neutral_Plus_Inv
> > 928 Mist
> > 1128 HighContrast-SVG
> > 7956 Tango
> > 9896 nimbus
> > 12529 gnome
> >
> > Not sure what Mist is, that's potentially something we can omit?
> > Maybe Crux too. We can move them into separate packages.
> > Tango is large and not required, but it's very popular on
> > Linux so it would be a shame not to have it in the default install.
>
> Nimbus (our default theme) also has a loose dependency on Tango--if an
> icon doesn't exist in Nimbus, the first fallback theme it tries is
> Tango. This was a deliberate choice--the usual fallback for other
> themes is gnome first, then hicolor.
Can't a single "full" theme be delivered minus all the redundancy? If
Nimbus doesn't have some icons then beef it up with icons from the
others and drop the rest.
-M
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
986
From:
IE
Registered:
7/14/05
|
|
|
|
Re: [desktop-discuss] CD Space analysis and
recommendations
Posted:
Aug 13, 2008 5:34 PM
in response to: Mark Phalan
|
|
On 13 Aug 2008, at 21:34, Mark Phalan wrote:
> Can't a single "full" theme be delivered minus all the redundancy? If
> Nimbus doesn't have some icons then beef it up with icons from the
> others and drop the rest.
Technically possible I would think, yes-- would need to check that all
the themes we were borrowing from had a licence that allowed us to mix-
and-match their icons with Nimbus, though.
The main drawback would probably be the effort in creating such a
theme in the first place, and then maintaining it, especially when
either:
* the themes we were borrowing from were updated (which wouldn't be a
strictly necessary activity, I suppose, but then our mega-Nimbus would
potentially look less polished than the current Nimbus)
* we decide one day that it would be visually more appealing to fill
in the gaps from some other theme(s) than the ones we originally picked.
Speaking as a maintainer of a couple of the current GNOME icon themes,
I know how much of a chore it is to make even relatively simple
changes to them; making sweeping changes is a bit like sticking
needles in your eyes. So I suspect this isn't a change we'd consider
doing lightly... but I'm not the Nimbus maintainer, so it's not for me
to say :)
Cheeri,
Calum.
--
CALUM BENSON, Usability Engineer Sun Microsystems Ireland
mailto:calum dot benson at sun dot com GNOME Desktop Team
http://blogs.sun.com/calum +353 1 819 9771
Any opinions are personal and not necessarily those of Sun Microsystems
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
1,992
From:
US
Registered:
3/9/05
|
|
|
|
Re: [desktop-discuss] CD Space analysis and
recommendations
Posted:
Aug 14, 2008 8:34 AM
in response to: calumb
|
|
Calum Benson wrote:
> On 13 Aug 2008, at 21:34, Mark Phalan wrote:
>
>> Can't a single "full" theme be delivered minus all the redundancy? If
>> Nimbus doesn't have some icons then beef it up with icons from the
>> others and drop the rest.
>
> Technically possible I would think, yes-- would need to check that all
> the themes we were borrowing from had a licence that allowed us to mix-
> and-match their icons with Nimbus, though.
>
> The main drawback would probably be the effort in creating such a
> theme in the first place, and then maintaining it, especially when
> either:
>
> * the themes we were borrowing from were updated (which wouldn't be a
> strictly necessary activity, I suppose, but then our mega-Nimbus would
> potentially look less polished than the current Nimbus)
>
> * we decide one day that it would be visually more appealing to fill
> in the gaps from some other theme(s) than the ones we originally picked.
>
> Speaking as a maintainer of a couple of the current GNOME icon themes,
> I know how much of a chore it is to make even relatively simple
> changes to them; making sweeping changes is a bit like sticking
> needles in your eyes. So I suspect this isn't a change we'd consider
> doing lightly... but I'm not the Nimbus maintainer, so it's not for me
> to say :)
>
I tend to agree with this reasoning, and am not inclined to push for
copy-paste engineering in themes anymore than I would anywhere else. I
would ask, though, that space considerations be a part of the
calculation in constructing the themes and dependency chains. Also, any
thoughts about Glynn's suggestion of not shipping so many icon variants?
For example, the 192x192 nimbus icons are 4+ MB all by themselves...
Dave
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
986
From:
IE
Registered:
7/14/05
|
|
|
|
Re: [desktop-discuss] CD Space analysis and
recommendations
Posted:
Aug 14, 2008 4:44 PM
in response to: dminer
|
|
On 14 Aug 2008, at 16:34, Dave Miner wrote:
>>
>
> I tend to agree with this reasoning, and am not inclined to push for
> copy-paste engineering in themes anymore than I would anywhere
> else. I
> would ask, though, that space considerations be a part of the
> calculation in constructing the themes and dependency chains. Also,
> any
> thoughts about Glynn's suggestion of not shipping so many icon
> variants?
> For example, the 192x192 nimbus icons are 4+ MB all by themselves...
Yep, I'd certainly have no issues with splitting out the 96x96 sizes
and upwards. Icons bigger than 48x48 are rarely needed on most
desktops, but we might want to keep the next size up (72x72) just in
case-- they might be called into play on big hi-res displays.
(Even the large print themes don't ship anything bigger than 48x48,
although their design means they do scale up a little better, when
called upon to do so.)
Cheeri,
Calum.
--
CALUM BENSON, Usability Engineer Sun Microsystems Ireland
mailto:calum dot benson at sun dot com GNOME Desktop Team
http://blogs.sun.com/calum +353 1 819 9771
Any opinions are personal and not necessarily those of Sun Microsystems
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
1,992
From:
US
Registered:
3/9/05
|
|
|
|
Re: [desktop-discuss] CD Space analysis and
recommendations
Posted:
Aug 15, 2008 7:15 AM
in response to: calumb
|
|
Calum Benson wrote:
>
> On 14 Aug 2008, at 16:34, Dave Miner wrote:
>>>
>>
>> I tend to agree with this reasoning, and am not inclined to push for
>> copy-paste engineering in themes anymore than I would anywhere else. I
>> would ask, though, that space considerations be a part of the
>> calculation in constructing the themes and dependency chains. Also, any
>> thoughts about Glynn's suggestion of not shipping so many icon variants?
>> For example, the 192x192 nimbus icons are 4+ MB all by themselves...
>
> Yep, I'd certainly have no issues with splitting out the 96x96 sizes and
> upwards. Icons bigger than 48x48 are rarely needed on most desktops,
> but we might want to keep the next size up (72x72) just in case-- they
> might be called into play on big hi-res displays.
>
How big/hi-res are we talking about to need 72x72? It's a meg, after all.
Dave
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
986
From:
IE
Registered:
7/14/05
|
|
|
|
Re: [desktop-discuss] CD Space analysis and
recommendations
Posted:
Aug 15, 2008 7:39 AM
in response to: dminer
|
|
On 15 Aug 2008, at 15:15, Dave Miner wrote:
> How big/hi-res are we talking about to need 72x72? It's a meg,
> after all.
Well, on my 24", 1920x1200, 96dpi display here, the 72x72 icons are
(not surprisingly) 3/4" wide and high[1]. That's bigger than our
default icon size, but they don't look huge on a 24" display by any
means. I can certainly imagine some people using that size for
desktop or file manager icons, on a 24" or 30" display.
Of course, if we don't ship the 72x72 size, the 48x48s will just be
scaled up as required. So I agree it's not necessary to ship them, if
it helps-- I'd maybe have pushed a bit harder to include the 64x64s if
we had any of those, but we don't :)
Cheeri,
Calum.
[1] That's 15mm, to us European types...
--
CALUM BENSON, Usability Engineer Sun Microsystems Ireland
mailto:calum dot benson at sun dot com GNOME Desktop Team
http://blogs.sun.com/calum +353 1 819 9771
Any opinions are personal and not necessarily those of Sun Microsystems
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
986
From:
IE
Registered:
7/14/05
|
|
|
|
Re: [desktop-discuss] CD Space analysis and
recommendations
Posted:
Aug 15, 2008 7:41 AM
in response to: calumb
|
|
On 15 Aug 2008, at 15:39, Calum Benson wrote:
> [1] That's 15mm, to us European types...
(Well okay, nearer 19mm I guess...)
--
CALUM BENSON, Usability Engineer Sun Microsystems Ireland
mailto:calum dot benson at sun dot com GNOME Desktop Team
http://blogs.sun.com/calum +353 1 819 9771
Any opinions are personal and not necessarily those of Sun Microsystems
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
1,992
From:
US
Registered:
3/9/05
|
|
|
|
Re: [desktop-discuss] CD Space analysis and
recommendations
Posted:
Aug 15, 2008 8:01 AM
in response to: calumb
|
|
Calum Benson wrote:
>
> On 15 Aug 2008, at 15:15, Dave Miner wrote:
>
>> How big/hi-res are we talking about to need 72x72? It's a meg, after
>> all.
>
>
> Well, on my 24", 1920x1200, 96dpi display here, the 72x72 icons are (not
> surprisingly) 3/4" wide and high[1]. That's bigger than our default
> icon size, but they don't look huge on a 24" display by any means. I
> can certainly imagine some people using that size for desktop or file
> manager icons, on a 24" or 30" display.
>
> Of course, if we don't ship the 72x72 size, the 48x48s will just be
> scaled up as required. So I agree it's not necessary to ship them, if
> it helps-- I'd maybe have pushed a bit harder to include the 64x64s if
> we had any of those, but we don't :)
>
I took a look at Ubuntu. For Human, they ship up to 48x48 but also have
an svg set.
Dave
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
986
From:
IE
Registered:
7/14/05
|
|
|
|
Re: [desktop-discuss] CD Space analysis and
recommendations
Posted:
Aug 18, 2008 3:23 PM
in response to: dminer
|
|
On 15 Aug 2008, at 16:01, Dave Miner wrote:
> I took a look at Ubuntu. For Human, they ship up to 48x48 but also
> have an svg set.
Yeah, maybe we'll do that one day. The trouble with SVG icons is they
can look a bit stylised and "plasticky" at large sizes, and at small
sizes they can mush up so much that you're better off with hand-
generated PNG versions anyway. So they're certainly not a panacea.
Cheeri,
Calum.
--
CALUM BENSON, Usability Engineer Sun Microsystems Ireland
mailto:calum dot benson at sun dot com GNOME Desktop Team
http://blogs.sun.com/calum +353 1 819 9771
Any opinions are personal and not necessarily those of Sun Microsystems
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
1,992
From:
US
Registered:
3/9/05
|
|
|
|
Re: [desktop-discuss] CD Space analysis and
recommendations
Posted:
Aug 19, 2008 10:31 AM
in response to: calumb
|
|
Calum Benson wrote:
> On 15 Aug 2008, at 16:01, Dave Miner wrote:
>
>> I took a look at Ubuntu. For Human, they ship up to 48x48 but also
>> have an svg set.
>
> Yeah, maybe we'll do that one day. The trouble with SVG icons is they
> can look a bit stylised and "plasticky" at large sizes, and at small
> sizes they can mush up so much that you're better off with hand-
> generated PNG versions anyway. So they're certainly not a panacea.
>
Sure, but we might need to make that tradeoff at some point for the CD.
Dave
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
986
From:
IE
Registered:
7/14/05
|
|
|
|
Re: [desktop-discuss] CD Space analysis and
recommendations
Posted:
Aug 20, 2008 10:16 AM
in response to: dminer
|
|
On 19 Aug 2008, at 18:31, Dave Miner wrote:
> Calum Benson wrote:
>> On 15 Aug 2008, at 16:01, Dave Miner wrote:
>>> I took a look at Ubuntu. For Human, they ship up to 48x48 but
>>> also have an svg set.
>> Yeah, maybe we'll do that one day. The trouble with SVG icons is
>> they can look a bit stylised and "plasticky" at large sizes, and
>> at small sizes they can mush up so much that you're better off
>> with hand- generated PNG versions anyway. So they're certainly not
>> a panacea.
>
> Sure, but we might need to make that tradeoff at some point for the
> CD.
Yep. (Another issue is that the Nimbus icons probably don't currently
exist in SVG format anywhere... I suspect they're designed in Adobe
Illustrator. Fortunately I think that still has SVG export
capabilities...)
Cheeri,
Calum.
--
CALUM BENSON, Usability Engineer Sun Microsystems Ireland
mailto:calum dot benson at sun dot com GNOME Desktop Team
http://blogs.sun.com/calum +353 1 819 9771
Any opinions are personal and not necessarily those of Sun Microsystems
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Laszlo (Laca) P...
Laszlo.Peter@Sun.COM
|
|
|
|
Re: [desktop-discuss] CD Space analysis
and recommendations
Posted:
Aug 18, 2008 4:26 PM
in response to: calumb
|
|
On Fri, 2008-08-15 at 00:44 +0100, Calum Benson wrote:
> > For example, the 192x192 nimbus icons are 4+ MB all by themselves...
>
> Yep, I'd certainly have no issues with splitting out the 96x96 sizes
> and upwards. Icons bigger than 48x48 are rarely needed on most
> desktops, but we might want to keep the next size up (72x72) just in
> case-- they might be called into play on big hi-res displays.
>
> (Even the large print themes don't ship anything bigger than 48x48,
> although their design means they do scale up a little better, when
> called upon to do so.)
Okay, so I have some good news and some bad news. I split
the icons 96x96 and larger from SUNWgnome-themes into
SUNWgnome-themes-hires. That saved 6452k (uncompressed).
This is the good news. The bad news is that in GNOME 2.23.x
SUNWgnome-themes is larger than what's in Dave's cd space
analysis so the new compressed SUNWgnome-themes is
20890914 (compared to 19893669 in Dave's doc). After
optimizing it with pngcrush, the compressed size is still
19312549, so that's 570k saved but not the megs we were
hoping to get. Also, I won't be able to optimize the
package until pngcrush is pushed through the process
(ARC, legal, etc...)
Laca
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
1,992
From:
US
Registered:
3/9/05
|
|
|
|
Re: [desktop-discuss] CD Space analysis
and recommendations
Posted:
Aug 19, 2008 10:32 AM
in response to: Laszlo (Laca) P...
|
|
Laszlo (Laca) Peter wrote:
> On Fri, 2008-08-15 at 00:44 +0100, Calum Benson wrote:
>>> For example, the 192x192 nimbus icons are 4+ MB all by themselves...
>> Yep, I'd certainly have no issues with splitting out the 96x96 sizes
>> and upwards. Icons bigger than 48x48 are rarely needed on most
>> desktops, but we might want to keep the next size up (72x72) just in
>> case-- they might be called into play on big hi-res displays.
>>
>> (Even the large print themes don't ship anything bigger than 48x48,
>> although their design means they do scale up a little better, when
>> called upon to do so.)
>
> Okay, so I have some good news and some bad news. I split
> the icons 96x96 and larger from SUNWgnome-themes into
> SUNWgnome-themes-hires. That saved 6452k (uncompressed).
> This is the good news. The bad news is that in GNOME 2.23.x
> SUNWgnome-themes is larger than what's in Dave's cd space
> analysis so the new compressed SUNWgnome-themes is
> 20890914 (compared to 19893669 in Dave's doc). After
> optimizing it with pngcrush, the compressed size is still
> 19312549, so that's 570k saved but not the megs we were
> hoping to get. Also, I won't be able to optimize the
> package until pngcrush is pushed through the process
> (ARC, legal, etc...)
>
That's depressing. What's the reason for all the growth?
Dave
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Laszlo (Laca) P...
Laszlo.Peter@Sun.COM
|
|
|
|
Re: [desktop-discuss] CD Space analysis
and recommendations
Posted:
Aug 19, 2008 9:26 PM
in response to: dminer
|
|
|
|
On Tue, 2008-08-19 at 13:32 -0400, Dave Miner wrote:
> > Okay, so I have some good news and some bad news. I split
> > the icons 96x96 and larger from SUNWgnome-themes into
> > SUNWgnome-themes-hires. That saved 6452k (uncompressed).
> > This is the good news. The bad news is that in GNOME 2.23.x
> > SUNWgnome-themes is larger than what's in Dave's cd space
> > analysis so the new compressed SUNWgnome-themes is
> > 20890914 (compared to 19893669 in Dave's doc). After
> > optimizing it with pngcrush, the compressed size is still
> > 19312549, so that's 570k saved but not the megs we were
> > hoping to get.
>
> That's depressing. What's the reason for all the growth?
Okay, so I drilled down (details attached). Basically, it
comes down:
- new GNOME backgrounds
- 2 new cursor themes (DMZ-Black, DMZ-White)
Before you ask, yes, we could split the GNOME backgrounds out,
the cursor themes too. Unless they all get merged back together
when importing into IPS :p
So speaking about that, when the GNOME packages are imported
into IPS, all the devel packages are merged with the end-user
packages. This includes 76M worth of API docs (/usr/share/gtk-doc,
9M compressed) among other things. We could save significant
amount of space on the CD by tagging and filtering out the devel
bits. If IPS filters were working (are they?) users could change
the filters to install the development bits. Just a thought...
Laca
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
1,901
From:
NZ
Registered:
6/16/05
|
|
|
|
Re: [desktop-discuss] CD Space analysis and
recommendations
Posted:
Aug 19, 2008 11:07 PM
in response to: Laszlo (Laca) P...
|
|
On 20/08/2008, at 4:26 PM, Laszlo (Laca) Peter wrote:
> On Tue, 2008-08-19 at 13:32 -0400, Dave Miner wrote:
>>> Okay, so I have some good news and some bad news. I split
>>> the icons 96x96 and larger from SUNWgnome-themes into
>>> SUNWgnome-themes-hires. That saved 6452k (uncompressed).
>>> This is the good news. The bad news is that in GNOME 2.23.x
>>> SUNWgnome-themes is larger than what's in Dave's cd space
>>> analysis so the new compressed SUNWgnome-themes is
>>> 20890914 (compared to 19893669 in Dave's doc). After
>>> optimizing it with pngcrush, the compressed size is still
>>> 19312549, so that's 570k saved but not the megs we were
>>> hoping to get.
>>
>> That's depressing. What's the reason for all the growth?
>
> Okay, so I drilled down (details attached). Basically, it
> comes down:
> - new GNOME backgrounds
> - 2 new cursor themes (DMZ-Black, DMZ-White)
>
> Before you ask, yes, we could split the GNOME backgrounds out,
> the cursor themes too. Unless they all get merged back together
> when importing into IPS :p
>
> So speaking about that, when the GNOME packages are imported
> into IPS, all the devel packages are merged with the end-user
> packages. This includes 76M worth of API docs (/usr/share/gtk-doc,
> 9M compressed) among other things. We could save significant
> amount of space on the CD by tagging and filtering out the devel
> bits. If IPS filters were working (are they?) users could change
> the filters to install the development bits. Just a thought...
This is really nice analysis - thanks Laca! Would be nice to do this
for each package if there's a script involved? I agree that most of
the extra content could be shifted into different packages.
Glynn
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Shawn Walker
swalker@opensolaris....
|
|
|
|
Re: [desktop-discuss] CD Space
analysis and recommendations
Posted:
Aug 20, 2008 6:15 AM
in response to: Laszlo (Laca) P...
|
|
Laszlo (Laca) Peter wrote:
> So speaking about that, when the GNOME packages are imported
> into IPS, all the devel packages are merged with the end-user
> packages. This includes 76M worth of API docs (/usr/share/gtk-doc,
> 9M compressed) among other things. We could save significant
> amount of space on the CD by tagging and filtering out the devel
> bits. If IPS filters were working (are they?) users could change
> the filters to install the development bits. Just a thought...
Filters are not yet implemented.
--
Shawn Walker
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
1,992
From:
US
Registered:
3/9/05
|
|
|
|
Re: [desktop-discuss] CD
Space analysis and recommendations
Posted:
Aug 20, 2008 12:10 PM
in response to: Shawn Walker
|
|
Shawn Walker wrote:
> Laszlo (Laca) Peter wrote:
>> So speaking about that, when the GNOME packages are imported
>> into IPS, all the devel packages are merged with the end-user
>> packages. This includes 76M worth of API docs (/usr/share/gtk-doc,
>> 9M compressed) among other things. We could save significant
>> amount of space on the CD by tagging and filtering out the devel
>> bits. If IPS filters were working (are they?) users could change
>> the filters to install the development bits. Just a thought...
>
> Filters are not yet implemented.
>
One possible outcome here is that we ask IPS to kick up the priority of
implementing filters to help solve the problem.
Anyway, thanks for digging in, Laca. We can certainly ensure that stuff
that's split out into separate packages stays out. For the moment, no
need to do anything, I'm waiting on some data about l10n and other
things before putting together revised recommendations. Are there any
other significant changes in the 2.23.x packages that we need to account
for?
Dave
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Laszlo (Laca) P...
Laszlo.Peter@Sun.COM
|
|
|
|
Re: [desktop-discuss]
CD Space analysis and recommendations
Posted:
Aug 20, 2008 11:12 PM
in response to: dminer
|
|
On Wed, 2008-08-20 at 15:10 -0400, Dave Miner wrote:
> Anyway, thanks for digging in, Laca. We can certainly ensure that stuff
> that's split out into separate packages stays out. For the moment, no
> need to do anything, I'm waiting on some data about l10n and other
> things before putting together revised recommendations.
Since I've already done all the work, I split the high
resolution icons from SUNWgnome-themes into a new package
called SUNWgnome-themes-hires in 2.23.
> Are there any
> other significant changes in the 2.23.x packages that we need to account
> for?
I'll ask someone from the desktop team to check if there are
any new packages that are required for the live CD and how the
sizes of the packages changed since 2.22.
Laca
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Laszlo (Laca) P...
Laszlo.Peter@Sun.COM
|
|
|
|
Re: [indiana-discuss] CD Space analysis and recommendations
Posted:
Sep 15, 2008 12:17 AM
in response to: dminer
|
|
|
|
Dave,
This is gonna be depressing, but the size of the GNOME packages
with the 2.24 update is expected to increase by about 11MB
(compressed!) Attached is a StarOffice spreadsheed (and a pdf
export for easier reading).
It looks likes like firefox3 accounts for almost 1/3 of the
size increase.
There is 1 new required package, SUNWlibtasn1 but we should
also consider SUNWespeak and SUNWgnome-a11y-speech-espeak for
better accessibility support.
Laca
On Wed, 2008-08-20 at 15:10 -0400, Dave Miner wrote:
> > Filters are not yet implemented.
> >
>
> One possible outcome here is that we ask IPS to kick up the priority of
> implementing filters to help solve the problem.
>
> Anyway, thanks for digging in, Laca. We can certainly ensure that stuff
> that's split out into separate packages stays out. For the moment, no
> need to do anything, I'm waiting on some data about l10n and other
> things before putting together revised recommendations. Are there any
> other significant changes in the 2.23.x packages that we need to account
> for?
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
104
From:
CN
Registered:
1/12/06
|
|
|
|
Re: [indiana-discuss] CD Space analysis and recommendations
Posted:
Sep 15, 2008 1:29 AM
in response to: Laszlo (Laca) P...
|
|
Laca and Dave,
It looks you don't include SUNWdesktop-search (Meta Tracker) and
its dependencies (SUNWlibgsf and SUNWw3m) in the LiveCD. However,
according to the Indiana UI spec,
http://opensolaris.org/os/community/desktop/uispecs/indiana-uispec/, we
need to include them. There is a search applet in the panel to call
tracker-search-tool.
It will add more increases :(
BTW, SUNWgnome-config-editor (gconf-editor) is not shown in the
menu by default. Do we want to remove it from the liveCD?
Harry
Laszlo (Laca) Peter wrote:
<pre wrap="">Dave,
This is gonna be depressing, but the size of the GNOME packages
with the 2.24 update is expected to increase by about 11MB
(compressed!) Attached is a StarOffice spreadsheed (and a pdf
export for easier reading).
It looks likes like firefox3 accounts for almost 1/3 of the
size increase.
There is 1 new required package, SUNWlibtasn1 but we should
also consider SUNWespeak and SUNWgnome-a11y-speech-espeak for
better accessibility support.
Laca
On Wed, 2008-08-20 at 15:10 -0400, Dave Miner wrote:
</pre>
<pre wrap="">Filters are not yet implemented.
</pre>
<pre wrap="">One possible outcome here is that we ask IPS to kick up the priority of
implementing filters to help solve the problem.
Anyway, thanks for digging in, Laca. We can certainly ensure that stuff
that's split out into separate packages stays out. For the moment, no
need to do anything, I'm waiting on some data about l10n and other
things before putting together revised recommendations. Are there any
other significant changes in the 2.23.x packages that we need to account
for?
</pre>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss</pre>
|
|
|
|
|
Posts:
5,504
From:
US
Registered:
3/9/05
|
|
|
|
Re: [indiana-discuss] CD Space analysis and recommendations
Posted:
Sep 15, 2008 7:30 AM
in response to: harrylu
|
|
Harry Lu wrote:
> Laca and Dave,
>
> It looks you don't include SUNWdesktop-search (Meta Tracker) and its
> dependencies (SUNWlibgsf and SUNWw3m) in the LiveCD. However, according
> to the Indiana UI spec,
> http://opensolaris.org/os/community/desktop/uispecs/indiana-uispec/, we
> need to include them. There is a search applet in the panel to call
> tracker-search-tool.
Will there be any built indexes to search on the LiveCD? Is there any
point including tracker on the LiveCD if there are not?
--
-Alan Coopersmith- alan dot coopersmith at sun dot com
Sun Microsystems, Inc. - X Window System Engineering
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
104
From:
CN
Registered:
1/12/06
|
|
|
|
Re: [indiana-discuss] CD Space analysis and recommendations
Posted:
Sep 15, 2008 8:22 AM
in response to: alanc
|
|
Alan Coopersmith wrote:
<pre wrap="">Harry Lu wrote:
</pre>
<pre wrap="">Laca and Dave,
It looks you don't include SUNWdesktop-search (Meta Tracker) and its
dependencies (SUNWlibgsf and SUNWw3m) in the LiveCD. However, according
to the Indiana UI spec,
http://opensolaris.org/os/community/desktop/uispecs/indiana-uispec/, we
need to include them. There is a search applet in the panel to call
tracker-search-tool.
</pre>
<pre wrap=""><!---->
Will there be any built indexes to search on the LiveCD? </pre>
As I know, No.
<pre wrap="">Is there any
point including tracker on the LiveCD if there are not?
</pre>
The indexes are stored in each user's home directory. And it is mainly
used to search user's docs, pictures, songs. So I would say it is not
very useful for the LiveCD, but might be useful for the default
installation so that user could use it after they store some files
under their home directory.
If it is not in the LiveCD, will it be available for the default
install? If No, I guess Calum need to update the UI spec to remove it
if we decided not to include it by default.
Harry
|
|
|
|
|
Posts:
986
From:
IE
Registered:
7/14/05
|
|
|
|
Re: [indiana-discuss] [desktop-discuss] CD Space analysis and
recommendations
Posted:
Sep 15, 2008 10:23 AM
in response to: alanc
|
|
On 15 Sep 2008, at 15:30, Alan Coopersmith wrote:
> Harry Lu wrote:
>> Laca and Dave,
>>
>> It looks you don't include SUNWdesktop-search (Meta Tracker) and
>> its
>> dependencies (SUNWlibgsf and SUNWw3m) in the LiveCD. However,
>> according
>> to the Indiana UI spec,
>> http://opensolaris.org/os/community/desktop/uispecs/indiana-
>> uispec/, we
>> need to include them. There is a search applet in the panel to call
>> tracker-search-tool.
>
> Will there be any built indexes to search on the LiveCD? Is there
> any
> point including tracker on the LiveCD if there are not?
Only that we'd like it to be there by default after installation
(which is really what the UI spec is for), and right now that
unfortunately means it has to go on the LiveCD as well...
Cheeri,
Calum.
--
CALUM BENSON, Usability Engineer Sun Microsystems Ireland
mailto:calum dot benson at sun dot com GNOME Desktop Team
http://blogs.sun.com/calum +353 1 819 9771
Any opinions are personal and not necessarily those of Sun Microsystems
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
124
From:
FR
Registered:
10/4/06
|
|
|
|
Re: [indiana-discuss] CD Space analysis and recommendations
Posted:
Sep 15, 2008 7:08 AM
in response to: Laszlo (Laca) P...
|
|
Hi All,
Laca thanks for the list.
Based on this I looked at what could be dropped from the liveCD. I
came up with
a preliminary list that could free up around 31 MB on the CD.
See the details of each package with "justification" for dropping
the package in the attached txt file.
Let me know what you think,
Cheers,
Erwann
Laszlo (Laca) Peter wrote:
> Dave,
>
> This is gonna be depressing, but the size of the GNOME packages
> with the 2.24 update is expected to increase by about 11MB
> (compressed!) Attached is a StarOffice spreadsheed (and a pdf
> export for easier reading).
>
> It looks likes like firefox3 accounts for almost 1/3 of the
> size increase.
>
> There is 1 new required package, SUNWlibtasn1 but we should
> also consider SUNWespeak and SUNWgnome-a11y-speech-espeak for
> better accessibility support.
>
> Laca
>
> On Wed, 2008-08-20 at 15:10 -0400, Dave Miner wrote:
>
>>> Filters are not yet implemented.
>>>
>>>
>> One possible outcome here is that we ask IPS to kick up the priority of
>> implementing filters to help solve the problem.
>>
>> Anyway, thanks for digging in, Laca. We can certainly ensure that stuff
>> that's split out into separate packages stays out. For the moment, no
>> need to do anything, I'm waiting on some data about l10n and other
>> things before putting together revised recommendations. Are there any
>> other significant changes in the 2.23.x packages that we need to account
>> for?
>>
--
Erwann Chénedé,
Desktop Group, Sun Microsystems, Grenoble
SUNWccsm compiz "advanced" configuration tool isn't needed on the LiveCD 0.57 MB
SUNWgnome-mm-applets applets are for desktop customization which imho occur after install 0.05 MB
SUNWgnome-internet-applets applets are for desktop customization which imho occur after install 0.18 MB
SUNWgnome-intranet-applets applets are for desktop customization which imho occur after install 0.42 MB
SUNWgnome-utility-applets applets are for desktop customization which imho occur after install 1.12 MB
SUNWgnome-desklets-extra compiz isn't needed on liveCD 0.69 MB
SUNWgnome-desklets desklets are not needed (occurs after install) 2.94 MB
SUNWgnome-menu-editor customization of menu not needed on liveCD 0.08 MB
SUNWgnome-cd-burner LiveCD isn't used to burn CD 0.16 MB
SUNWgnome-screenshot screenshot occur often after install 0.05 MB
SUNWgnome-disk-analyzer disk analyzer isn't used on LiveCD 0.24 MB
SUNWgnome-pilot nobody sync it's palm on a LiveCD 0.25 MB
SUNWgnome-remote-desktop vnc on a liveCD ? Not needed 0.28 MB
SUNWgnome-camera camera sync isn't needed 1.05 MB
SUNWgnome-meeting Meeting software need network conf, usually occurs after install 10.71 MB
SUNWgnome-img-organizer image management isn't needed 1.3 MB
SUNWgnome-img-editor do you retouch images on liveCD ? 8.04 MB
Not sure about these :
SUNWgnome-doc-utils Is it needed ? 0.26 MB
SUNWgnome-power-manager is power management UI needed ?? 1.96 MB
Total 31.49 MB
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
815
From:
IE
Registered:
6/15/05
|
|
|
|
Re: [indiana-discuss] [desktop-discuss] CD Space analysis and
recommendations
Posted:
Sep 15, 2008 7:08 AM
in response to: erwannc
|
|
What's is the process to get those dropped packages onto the machine if
they are not on the live CD?
That is what does the user needs to do to get these dropped packages.
-Ghee
Erwann Chenede wrote:
> Hi All,
>
> Laca thanks for the list.
>
> Based on this I looked at what could be dropped from the liveCD. I
> came up with
> a preliminary list that could free up around 31 MB on the CD.
>
> See the details of each package with "justification" for dropping
> the package in the attached txt file.
>
> Let me know what you think,
>
> Cheers,
>
> Erwann
>
>
> Laszlo (Laca) Peter wrote:
>> Dave,
>>
>> This is gonna be depressing, but the size of the GNOME packages
>> with the 2.24 update is expected to increase by about 11MB
>> (compressed!) Attached is a StarOffice spreadsheed (and a pdf
>> export for easier reading).
>>
>> It looks likes like firefox3 accounts for almost 1/3 of the
>> size increase.
>>
>> There is 1 new required package, SUNWlibtasn1 but we should
>> also consider SUNWespeak and SUNWgnome-a11y-speech-espeak for
>> better accessibility support.
>>
>> Laca
>>
>> On Wed, 2008-08-20 at 15:10 -0400, Dave Miner wrote:
>>
>>>> Filters are not yet implemented.
>>>>
>>>>
>>> One possible outcome here is that we ask IPS to kick up the priority
>>> of implementing filters to help solve the problem.
>>>
>>> Anyway, thanks for digging in, Laca. We can certainly ensure that
>>> stuff that's split out into separate packages stays out. For the
>>> moment, no need to do anything, I'm waiting on some data about l10n
>>> and other things before putting together revised recommendations.
>>> Are there any other significant changes in the 2.23.x packages that
>>> we need to account for?
>>>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> desktop-discuss mailing list
> desktop-discuss at opensolaris dot org
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Shawn Walker
swalker@opensolaris....
|
|
|
|
Re: [indiana-discuss] [desktop-discuss] CD Space analysis and
recommendations
Posted:
Sep 15, 2008 7:53 AM
in response to: gheet
|
|
Ghee Teo wrote:
> What's is the process to get those dropped packages onto the machine if
> they are not on the live CD?
> That is what does the user needs to do to get these dropped packages.
Assuming they have an active network connection?
pkg install foo
--
Shawn Walker
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
815
From:
IE
Registered:
6/15/05
|
|
|
|
Re: [indiana-discuss] [desktop-discuss] CD Space analysis and
recommendations
Posted:
Sep 15, 2008 7:53 AM
in response to: Shawn Walker
|
|
Shawn Walker wrote:
> Ghee Teo wrote:
>> What's is the process to get those dropped packages onto the machine
>> if they are not on the live CD?
>> That is what does the user needs to do to get these dropped packages.
>
> Assuming they have an active network connection?
Okay.
>
> pkg install foo
That's on the assumption that the user knows what is the name of the
packages to install,
some of the names from the list of packages that Erwann listed weren't
easy to remember
is even more difficult is to know what to install to make which part of
the system to work.
So the *default installed system* from the Live CD should be reasoanbly
complete
After all, when the user has invested the disk and time to install a
system, he expects more
than the liveCD. Like for example, I would expect burning CD
functionality to work
after installing the live CD, or camera or image organizer without
having to work out
what other packages I need to down load.
-Ghee
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Shawn Walker
swalker@opensolaris....
|
|
|
|
Re: [indiana-discuss] [desktop-discuss] CD Space analysis and
recommendations
Posted:
Sep 15, 2008 8:16 AM
in response to: gheet
|
|
Ghee Teo wrote:
> Shawn Walker wrote:
>> Ghee Teo wrote:
>>> What's is the process to get those dropped packages onto the machine
>>> if they are not on the live CD?
>>> That is what does the user needs to do to get these dropped packages.
>>
>> Assuming they have an active network connection?
> Okay.
>>
>> pkg install foo
> That's on the assumption that the user knows what is the name of the
> packages to install,
> some of the names from the list of packages that Erwann listed weren't
> easy to remember
> is even more difficult is to know what to install to make which part of
> the system to work.
...which is why the gui and cli for pkg(5) provide search functionality
that should make it easy to find the package(s) to install.
> So the *default installed system* from the Live CD should be reasoanbly
> complete
> After all, when the user has invested the disk and time to install a
> system, he expects more
> than the liveCD. Like for example, I would expect burning CD
> functionality to work
> after installing the live CD, or camera or image organizer without
> having to work out
> what other packages I need to down load.
I agree it should be reasonably complete, however, as others pointed out
-- that has to be balanced against space constraints.
--
Shawn Walker
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Shawn Walker
swalker@opensolaris....
|
|
|
|
Re: [indiana-discuss] [desktop-discuss] CD Space analysis and
recommendations
Posted:
Sep 15, 2008 8:20 AM
in response to: Shawn Walker
|
|
Shawn Walker wrote:
> Ghee Teo wrote:
>> Shawn Walker wrote:
>>> Ghee Teo wrote:
>>>> What's is the process to get those dropped packages onto the machine
>>>> if they are not on the live CD?
>>>> That is what does the user needs to do to get these dropped packages.
>>> Assuming they have an active network connection?
>> Okay.
>>> pkg install foo
>> That's on the assumption that the user knows what is the name of the
>> packages to install,
>> some of the names from the list of packages that Erwann listed weren't
>> easy to remember
>> is even more difficult is to know what to install to make which part of
>> the system to work.
>
> ...which is why the gui and cli for pkg(5) provide search functionality
> that should make it easy to find the package(s) to install.
>
>> So the *default installed system* from the Live CD should be reasoanbly
>> complete
>> After all, when the user has invested the disk and time to install a
>> system, he expects more
>> than the liveCD. Like for example, I would expect burning CD
>> functionality to work
>> after installing the live CD, or camera or image organizer without
>> having to work out
>> what other packages I need to down load.
>
> I agree it should be reasonably complete, however, as others pointed out
> -- that has to be balanced against space constraints.
I'd just thought I'd add that I can certainly understand (looking at the
list) why you'd be concerned about the packages in question being removed.
compiz and others are all great things to show off on a LiveCD and don't
look like good candidates to cut. Some applets are important on the
Livce CD (such as power monitoring) and the gnome power is definitely
needed for laptop usage.
If this path were really going to be pursued, there would need to be a
special group-package setup in the ips repository with a name like
"gnome-essentials" that would make it easy install all of this on the
new system.
I'd be hesitant to cut most of these packages...
--
Shawn Walker
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
|
|
|
|
|
Posts:
962
From:
US
Registered:
3/9/05
|
|
|
|
Re: [indiana-discuss] [desktop-discuss] CD Space analysis and
recommendations
Posted:
Sep 15, 2008 9:25 AM
in response to: gheet
|
|
> So the *default installed system* from the Live CD should be reasoanbly
> complete
> After all, when the user has invested the disk and time to install a
> system, he expects more
> than the liveCD. Like for example, I would expect burning CD
> functionality to work
> after installing the live CD, or camera or image organizer without
> having to work out
> what other packages I need to down load.
One of the limitations in the current system is that the contents of
the LiveCD == the contents of the initially installed system; namely,
there isn't a way of either minimizing the latter or expanding it to
include other packages automatically post-installation. This is being
worked on but isn't present at the moment.
dsc
_______________________________________________
indiana-discuss mailing list
indiana-discuss at opensolaris | | | |
