[opensuse-factory] appdata-icons.tar.gz
As an avid user of Factory/Tumbleweed, I am trying to update
even while traveling when, often, Internet connectivity is
slow and/or unreliable.
What I noticed is that trying to refresh appdata-icons.tar.gz
(and appdata-failed.html) takes a disproportional amount of
time. So I looked into
http://download.opensuse.org/factory/repo/oss/suse/setup/descr/
and found that, indeed, this is the largest piece that zypper
has to download.
Is this really necessary for a simple zypper up or zypper dup?
Or can we save bandwidth and win speed for us and our users?
Gerald
--
Dr. Gerald Pfeifer
Gerald, On Fri, 2015-06-05 at 13:35 +0200, Gerald Pfeifer wrote:
As an avid user of Factory/Tumbleweed, I am trying to update even while traveling when, often, Internet connectivity is slow and/or unreliable.
What I noticed is that trying to refresh appdata-icons.tar.gz (and appdata-failed.html) takes a disproportional amount of time. So I looked into
appdata-failed.html would be no problem to get rid of... it's mainly
for 'reference purpose' and is not 'required' for operations (but
looking at the size, I don't think those 350KB will really make a huge
impact)
the icons tarball is a bit trickier. Removing this will mean to break
the integration of software centers (currently only GNOME Software, KDE
is planning an own one, even yast might go that way at one point).
What CAN probably easily be done would be to eliminate the HiDPI
(128x128) icons from the tarball.. of course, at the cost of users
having a HiDPI screen. This would cut the size of appdata-icons.tar.gz
down to 2.6MB from 7.5MB (I tried changing it to .xz or .bz2; it's not worth the
efforts)
So, the question basically boils down to: do we want to have proper
support for HiDPI in our setup or do we not care for those users.
Dominique
--
Dimstar / Dominique Leuenberger
El Lunes, 8 de junio de 2015 11:29:56 Dimstar / Dominique Leuenberger escribió:
Gerald,
On Fri, 2015-06-05 at 13:35 +0200, Gerald Pfeifer wrote:
As an avid user of Factory/Tumbleweed, I am trying to update even while traveling when, often, Internet connectivity is slow and/or unreliable.
What I noticed is that trying to refresh appdata-icons.tar.gz (and appdata-failed.html) takes a disproportional amount of time. So I looked into
appdata-failed.html would be no problem to get rid of... it's mainly for 'reference purpose' and is not 'required' for operations (but looking at the size, I don't think those 350KB will really make a huge impact)
the icons tarball is a bit trickier. Removing this will mean to break the integration of software centers (currently only GNOME Software, KDE is planning an own one, even yast might go that way at one point).
What CAN probably easily be done would be to eliminate the HiDPI (128x128) icons from the tarball.. of course, at the cost of users having a HiDPI screen. This would cut the size of appdata-icons.tar.gz down to 2.6MB from 7.5MB (I tried changing it to .xz or .bz2; it's not worth the efforts)
So, the question basically boils down to: do we want to have proper support for HiDPI in our setup or do we not care for those users.
Dominique
Hi. Could we just use svg icons? They usually have a small size and being text files they compress quite well. I clients expect png, a script could create them from the svg ones. Greetings. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, 2015-06-08 at 11:36 +0200, jcsl wrote:
Hi.
Could we just use svg icons? They usually have a small size and being text files they compress quite well. I clients expect png, a script could create them from the svg ones.
Greetings.
We get icons from packages, most do not even ship svg icons - so we'd
need to 'produce' svg out of pngs (I don't want to even see those icons
on my screen after) and on the machine reconvert them back to PNGs?
Sounds like a terrible plan.
Other than that, converting svgs to PNG would mean a lot of CPU on all
machines to produce the right input files again... a task, that would
be kicked of at each repo refresh for every icon in the distribution
(at the moment there are 570 icons in format 64x64 in the tarball)
Also does not sound THAT tempting
--
Dimstar / Dominique Leuenberger
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-06-08 11:41, Dimstar / Dominique Leuenberger wrote:
On Mon, 2015-06-08 at 11:36 +0200, jcsl wrote:
Could we just use svg icons? They usually have a small size and being text files they compress quite well. I clients expect png, a script could create them from the svg ones.
We get icons from packages, most do not even ship svg icons - so we'd need to 'produce' svg out of pngs (I don't want to even see those icons on my screen after) and on the machine reconvert them back to PNGs? Sounds like a terrible plan.
vector graphics like svg are small only if the graphics are designed to be vectorial from the start. If converted from bitmaps, they can be huge or produce bad results. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlV2EBcACgkQja8UbcUWM1yI/AD9FxWBe/CIoONtijQX/9MB9/Ae sDGoboJznFVsPXiG8L4A/3EYRYfEycAmgdbhhJDaCn/NyjH6Y7rOUYE5AjMTNGDp =+s2I -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
ma., 08.06.2015 kl. 11.29 +0200, skrev Dimstar / Dominique Leuenberger:
snip
What CAN probably easily be done would be to eliminate the HiDPI (128x128) icons from the tarball.. of course, at the cost of users having a HiDPI screen. This would cut the size of appdata -icons.tar.gz down to 2.6MB from 7.5MB (I tried changing it to .xz or .bz2; it's not worth the efforts)
So, the question basically boils down to: do we want to have proper support for HiDPI in our setup or do we not care for those users.
Dominique
As a HiDPI user I say yes we do (and lets face it, there will be more and more HiDPI users soon). A possible solution could be to make the appdata-icons.tar.gz into a "delta" - How hard / how much work that would be I have no clue, so sorry for making a "someone else has to do x" suggestion. //Bjørn -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Jun 08, 2015 at 11:49:45AM +0200, Bjørn Lie wrote:
ma., 08.06.2015 kl. 11.29 +0200, skrev Dimstar / Dominique Leuenberger:
snip
What CAN probably easily be done would be to eliminate the HiDPI (128x128) icons from the tarball.. of course, at the cost of users having a HiDPI screen. This would cut the size of appdata -icons.tar.gz down to 2.6MB from 7.5MB (I tried changing it to .xz or .bz2; it's not worth the efforts)
So, the question basically boils down to: do we want to have proper support for HiDPI in our setup or do we not care for those users.
Dominique
As a HiDPI user I say yes we do (and lets face it, there will be more and more HiDPI users soon).
A possible solution could be to make the appdata-icons.tar.gz into a "delta" - How hard / how much work that would be I have no clue, so sorry for making a "someone else has to do x" suggestion.
Good point. Our software stack already supports delta downloads for repo metadata, we should also enable this for the appdata icons. I'll tweak the scripts on the download redirector. Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Monday, June 08, 2015 12:38:29 Michael Schroeder wrote:
On Mon, Jun 08, 2015 at 11:49:45AM +0200, Bjørn Lie wrote:
ma., 08.06.2015 kl. 11.29 +0200, skrev Dimstar / Dominique Leuenberger:
snip
What CAN probably easily be done would be to eliminate the HiDPI (128x128) icons from the tarball.. of course, at the cost of users having a HiDPI screen. This would cut the size of appdata -icons.tar.gz down to 2.6MB from 7.5MB (I tried changing it to .xz or .bz2; it's not worth the efforts)
So, the question basically boils down to: do we want to have proper support for HiDPI in our setup or do we not care for those users.
Dominique
As a HiDPI user I say yes we do (and lets face it, there will be more and more HiDPI users soon).
A possible solution could be to make the appdata-icons.tar.gz into a "delta" - How hard / how much work that would be I have no clue, so sorry for making a "someone else has to do x" suggestion.
Good point. Our software stack already supports delta downloads for repo metadata, we should also enable this for the appdata icons.
I'll tweak the scripts on the download redirector.
Cheers, Michael.
I have just compared the appdata-icons.tar.gz from the last two snapshots. These just differ by 3 bytes, which are the 3 lower bytes of the timestamp (seconds since epoch). stb@sbruens-linux:~> hexdump -C -n 10 appdata-icons.tar.gz 00000000 1f 8b 08 00 01 e3 75 55 00 03 |......uU..| 0000000a stb@sbruens-linux:~> hexdump -C -n 10 appdata-icons_2015-06-07.tar.gz 00000000 1f 8b 08 00 8a 6b 74 55 00 03 |.....ktU..| 0000000a cmp -l -i 7 appdata-icons_2015-06-07.tar.gz appdata-icons.tar.gz && echo equal equal cmp -l -i 0 appdata-icons_2015-06-07.tar.gz appdata-icons.tar.gz && echo equal 5 212 1 6 153 343 7 164 165 file appdata-icons_2015-06-07.tar.gz appdata-icons_2015-06-07.tar.gz: gzip compressed data, last modified: Sun Jun 7 18:04:26 2015, from Unix file appdata-icons.tar.gz appdata-icons.tar.gz: gzip compressed data, last modified: Mon Jun 8 20:46:25 2015, from Unix xdelta3 is able to create a 91 byte diff file for these, but best would be to skip the update. Kind regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019 work: +49 2405 49936-424-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Dimstar / Dominique Leuenberger
Gerald,
On Fri, 2015-06-05 at 13:35 +0200, Gerald Pfeifer wrote:
As an avid user of Factory/Tumbleweed, I am trying to update even while traveling when, often, Internet connectivity is slow and/or unreliable.
What I noticed is that trying to refresh appdata-icons.tar.gz (and appdata-failed.html) takes a disproportional amount of time. So I looked into
appdata-failed.html would be no problem to get rid of... it's mainly for 'reference purpose' and is not 'required' for operations (but looking at the size, I don't think those 350KB will really make a huge impact)
the icons tarball is a bit trickier. Removing this will mean to break the integration of software centers (currently only GNOME Software, KDE is planning an own one, even yast might go that way at one point).
What CAN probably easily be done would be to eliminate the HiDPI (128x128) icons from the tarball.. of course, at the cost of users having a HiDPI screen. This would cut the size of appdata-icons.tar.gz down to 2.6MB from 7.5MB (I tried changing it to .xz or .bz2; it's not worth the efforts)
So, the question basically boils down to: do we want to have proper support for HiDPI in our setup or do we not care for those users.
Why should this be downloaded by zypper at all? This is a pretty niche use-case on openSUSE, why can't GNOME Software download this by itself on-demand? -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Dominique, Am 08.06.2015 um 11:29 schrieb Dimstar / Dominique Leuenberger:
Gerald,
On Fri, 2015-06-05 at 13:35 +0200, Gerald Pfeifer wrote:
As an avid user of Factory/Tumbleweed, I am trying to update even while traveling when, often, Internet connectivity is slow and/or unreliable.
What I noticed is that trying to refresh appdata-icons.tar.gz (and appdata-failed.html) takes a disproportional amount of time. So I looked into
appdata-failed.html would be no problem to get rid of... it's mainly for 'reference purpose' and is not 'required' for operations (but looking at the size, I don't think those 350KB will really make a huge impact)
the icons tarball is a bit trickier. Removing this will mean to break the integration of software centers (currently only GNOME Software, KDE is planning an own one, even yast might go that way at one point).
I have asked this before, but it got lost apparently: Why does zypper have to download this appdata stuff that it does not use at all (it tells me stuff about "the following applications will be removed: Konqueror" when I'm only updating packages and it cannot do anything useful with "Applications"). The "software centers" could download this huge piece of metadata once they needs it, but downloading this for simple "zypper ref" all the time really seems wasteful.
What CAN probably easily be done would be to eliminate the HiDPI (128x128) icons from the tarball.. of course, at the cost of users having a HiDPI screen. This would cut the size of appdata-icons.tar.gz down to 2.6MB from 7.5MB (I tried changing it to .xz or .bz2; it's not worth the efforts)
So, the question basically boils down to: do we want to have proper support for HiDPI in our setup or do we not care for those users.
If an "software center" runs on a HiDPI screen, it can downloas as many "appdata-icons-hidpi.tar.gz" as it wants, but for me, only running zypper in a terminal, I'd really like to not have to download any appdata at all. Best regards, Stefan -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, 2015-06-08 at 21:00 +0200, Stefan Seyfried wrote:
Hi Dominique,
Am 08.06.2015 um 11:29 schrieb Dimstar / Dominique Leuenberger:
Gerald,
On Fri, 2015-06-05 at 13:35 +0200, Gerald Pfeifer wrote:
As an avid user of Factory/Tumbleweed, I am trying to update even while traveling when, often, Internet connectivity is slow and/or unreliable.
What I noticed is that trying to refresh appdata-icons.tar.gz (and appdata-failed.html) takes a disproportional amount of time. So I looked into
appdata-failed.html would be no problem to get rid of... it's mainly for 'reference purpose' and is not 'required' for operations (but looking at the size, I don't think those 350KB will really make a huge impact)
the icons tarball is a bit trickier. Removing this will mean to break the integration of software centers (currently only GNOME Software, KDE is planning an own one, even yast might go that way at one point).
I have asked this before, but it got lost apparently:
Why does zypper have to download this appdata stuff that it does not use at all (it tells me stuff about "the following applications will be removed: Konqueror" when I'm only updating packages and it cannot do anything useful with "Applications"). The "software centers" could download this huge piece of metadata once they needs it, but downloading this for simple "zypper ref" all the time really seems wasteful.
What CAN probably easily be done would be to eliminate the HiDPI (128x128) icons from the tarball.. of course, at the cost of users having a HiDPI screen. This would cut the size of appdata -icons.tar.gz down to 2.6MB from 7.5MB (I tried changing it to .xz or .bz2; it's not worth the efforts)
So, the question basically boils down to: do we want to have proper support for HiDPI in our setup or do we not care for those users.
If an "software center" runs on a HiDPI screen, it can downloas as many "appdata-icons-hidpi.tar.gz" as it wants, but for me, only running zypper in a terminal, I'd really like to not have to download any appdata at all.
You miss the full picture: the icons are used even outside the software center: in gnome-shell for example, if you type the name of an uninstalled app, the 'available app search provider' lists the application including the icon already. Having to launch a SC for this feature to work is not feasible. And: GNOME Software is so far only the first one to have proper support for the freedesktop AppStream metadata. There are discussions to teach this to Yast (IIRC, there was a GSoC proposal), KDE is surely coming with they SC, and I am sure others will too. I am all ears of slimming it down, but stripping it is just the wrong approach - UNLESS zypp can learn to download additional metadata based on plugins (there is already a plugin that tells it what to do out of the metadata - and that plugin is a dependency to GNOME-Software (and the gnome-shell search provider). So IF zypp can be thought to know about 'extensions' to the metadata, based on a plugin, I would be willing to extend this further - then it would become a proper optional thing. All other proposals (other than the meta downloads, which is apparently being looked at already) at just half baked solutions - taking away functionality. Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 08.06.2015 um 22:57 schrieb Dominique Leuenberger / DimStar:
On Mon, 2015-06-08 at 21:00 +0200, Stefan Seyfried wrote:
Hi Dominique,
So, the question basically boils down to: do we want to have proper support for HiDPI in our setup or do we not care for those users.
If an "software center" runs on a HiDPI screen, it can downloas as
s/software-center/desktop environment who wants appdata/
many "appdata-icons-hidpi.tar.gz" as it wants, but for me, only running zypper in a terminal, I'd really like to not have to download any appdata at all.
You miss the full picture: the icons are used even outside the software center: in gnome-shell for example, if you type the name of an uninstalled app, the 'available app search provider' lists the application including the icon already.
That's a real problem. For GNOME. Not for me :-) Those icons do not change that often. We could publish them once per year as a package or Gnome-shell could look up missing ones via a web service.
Having to launch a SC for this feature to work is not feasible.
Well, the SC certainly is integrated into the Desktop Environment, so the DE can tell the SC at login to update the appdata if necessary.
And: GNOME Software is so far only the first one to have proper support for the freedesktop AppStream metadata. There are discussions to teach this to Yast (IIRC, there was a GSoC proposal), KDE is surely coming with they SC, and I am sure others will too.
So it still is 100% useless for zypper commandline users. But still everyone has to download it all the time.
I am all ears of slimming it down, but stripping it is just the wrong approach - UNLESS zypp can learn to download additional metadata based on plugins (there is already a plugin that tells it what to do out of the metadata - and that plugin is a dependency to GNOME-Software (and the gnome-shell search provider). So IF zypp can be thought to know about 'extensions' to the metadata, based on a plugin, I would be willing to extend this further - then it would become a proper optional thing.
This should have been optional from the very beginning.
All other proposals (other than the meta downloads, which is apparently being looked at already) at just half baked solutions - taking away functionality.
Not for me. You are desktop centric, which is fine, but burdening everyone with many megabytes of (usually damn slow, apparently they are often hitting the main servers) metadata downloads, which are absolutely useless for many users is not an economic solution. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 2015-06-09 at 08:31 +0200, Stefan Seyfried wrote:
Am 08.06.2015 um 22:57 schrieb Dominique Leuenberger / DimStar:
On Mon, 2015-06-08 at 21:00 +0200, Stefan Seyfried wrote:
Hi Dominique,
So, the question basically boils down to: do we want to have proper support for HiDPI in our setup or do we not care for those users.
If an "software center" runs on a HiDPI screen, it can downloas as
s/software-center/desktop environment who wants appdata/
many "appdata-icons-hidpi.tar.gz" as it wants, but for me, only running zypper in a terminal, I'd really like to not have to download any appdata at all.
You miss the full picture: the icons are used even outside the software center: in gnome-shell for example, if you type the name of an uninstalled app, the 'available app search provider' lists the application including the icon already.
That's a real problem. For GNOME. Not for me :-) Those icons do not change that often. We could publish them once per year as a package or Gnome-shell could look up missing ones via a web service.
Having to launch a SC for this feature to work is not feasible.
Well, the SC certainly is integrated into the Desktop Environment, so the DE can tell the SC at login to update the appdata if necessary.
And: GNOME Software is so far only the first one to have proper support for the freedesktop AppStream metadata. There are discussions to teach this to Yast (IIRC, there was a GSoC proposal), KDE is surely coming with they SC, and I am sure others will too.
So it still is 100% useless for zypper commandline users. But still everyone has to download it all the time.
I am all ears of slimming it down, but stripping it is just the wrong approach - UNLESS zypp can learn to download additional metadata based on plugins (there is already a plugin that tells it what to do out of the metadata - and that plugin is a dependency to GNOME-Software (and the gnome-shell search provider). So IF zypp can be thought to know about 'extensions' to the metadata, based on a plugin, I would be willing to extend this further - then it would become a proper optional thing.
This should have been optional from the very beginning.
All other proposals (other than the meta downloads, which is apparently being looked at already) at just half baked solutions - taking away functionality.
Not for me. You are desktop centric, which is fine, but burdening everyone with many megabytes of (usually damn slow, apparently they are often hitting the main servers) metadata downloads, which are absolutely useless for many users is not an economic solution.
http://gs-stats.leuenberger.net/trend.html is not agreeing with your
statement that the metadata is static.
--
Dimstar / Dominique Leuenberger
participants (10)
-
Bjørn Lie -
Brüns, Stefan -
Carlos E. R. -
Dimstar / Dominique Leuenberger -
Dominique Leuenberger / DimStar
-
Gerald Pfeifer -
Guido Berhoerster -
jcsl -
Michael Schroeder -
Stefan Seyfried