Re: LiveCD optimisations
At 2010-05-21 04:41 GMT, Martin Owens wrote: > Hey Louis, Hey Martin, thanks for the reply! > Sounds great and looks like a pretty good script, I have some comments: > > You may be able to make it a little faster by using the find results in > one like like this: > > find / -type f -name "*.svg" -print0 | xargs -0 -I FILE sh -c > '/tmp/scour/scour.py --enable-id-stripping --indent=none -i FILE -o > FILE-opt && test -s FILE-opt && mv FILE-opt FILE || rm FILE-opt' I had considered using sh -c to execute the Scouring and renaming, yes, but didn't know how to go about detecting empty files except with another 'find'. Thanks for telling me about test -s :) > Although if you can get all that into a script file, so much the better > so it's not all on one line. But at least it's not doing a find 3 times > for the same files. True. This is a case of optimising the optimiser, which I consider a micro-optimisation because the later invocations of 'find' are highly likely to have the needed disk blocks in RAM - but every little bit helps, just like with these image files. (Speaking of which, Scour.py imports the Psyco JIT if it's available, but it doesn't help that much. It makes the Python code itself run faster, yes, but at the cost of greater startup time for each Scour.py instance, and most files are optimised in 0.06 second anyway.) > Do you need to chroot into the file system to perform these steps? > considering that your downloading code to do it (with bzr which isn't > installed ont he cd). Would it not be good to perform these steps > outside of the squashfs and iso file system? > > For instance I got resolve issues when it tried to do the apt update. I probably don't. That was part of a script that allowed me to customise more things, such as updating packages (which I needed to chroot for), removing the desktop background, updating Linux and all that; I just trimmed it down for this email. I'll move the chroot processing to the host. > Are there no more things that could be optimised? For instance does > using xmllint with --noblanks on the 12496 xml files save any space? Will test this shortly. I hadn't thought of that yet, and I'm flabbergasted by the number of XML files! Seeing as SVG files are also XML files, and Scour.py seems to pretty-print XML even with --indent=none, that might save even more, actually. > Finally... should some of these optimisations work their way upstream so > all packages have optimised files, smaller downloads, smarter mirror > storage etc? Of course! :) Working with upstreams would avoid keeping debdiffs around for the optimised files in Ubuntu repositories, and will help other distributions too. I'll attach a modified script to my next email with more testing results regarding XML. Regards, - Louis -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: LiveCD optimisations
Hey Louis, Sounds great and looks like a pretty good script, I have some comments: You may be able to make it a little faster by using the find results in one like like this: find / -type f -name "*.svg" -print0 | xargs -0 -I FILE sh -c '/tmp/scour/scour.py --enable-id-stripping --indent=none -i FILE -o FILE-opt && test -s FILE-opt && mv FILE-opt FILE || rm FILE-opt' Although if you can get all that into a script file, so much the better so it's not all on one line. But at least it's not doing a find 3 times for the same files. Do you need to chroot into the file system to perform these steps? considering that your downloading code to do it (with bzr which isn't installed ont he cd). Would it not be good to perform these steps outside of the squashfs and iso file system? For instance I got resolve issues when it tried to do the apt update. Consider doing a check to see if the iso exists before reserving scratch, errors are likely if you don't. Are there no more things that could be optimised? For instance does using xmllint with --noblanks on the 12496 xml files save any space? Finally... should some of these optimisations work their way upstream so all packages have optimised files, smaller downloads, smarter mirror storage etc? Martin, On Thu, 2010-05-20 at 20:35 -0400, Louis Simard wrote: > Greetings ubuntu-devel-discuss :) > > I have a proposal for you, and I'll present it simply with the 5 W's. > > -- WHAT? -- > > Optimise the PNG images and SVG files on the Ubuntu LiveCD. > Optimise the Ubuntu LiveCD by putting start-up files and programs near > the end of the CD. > > -- WHY? -- > > Optimising the PNG images saves 5.5 MB on the filesystem.squashfs. > Optimising the SVG files saves an additional 7 MB. This is a total of > 12.5 MB which could be used to pack more software or another language > pack or two onto the LiveCD. > Optimising the CD to put files at the end allows it to boot marginally > faster (about 10 seconds on my benchmarks), start applications faster, > and allows the CD drive on a user's computer to run quieter while > using his/her applications, as reading near the end (edge of the disc) > requires slower spinning. > These changes will give prospective users a better view of Ubuntu > right from the LiveCD. There might also be additional benefits to > having smaller PNG and SVG images, such as saving space on a user's > hard disk when installed. The uncompressed (pre-squashfs) savings for > the SVG images is 18 MB. > > -- WHEN? -- > > Now! :) Just kidding. As soon as possible would be nice. Maybe even > for the next Ubuntu version, codename Maverick Meerkat! > > -- WHO? -- > > Ubuntu developers. But don't go thinking that you'll do all the grunt > work of testing these optimisations for yourself! (See HOW? below) > > -- HOW? -- > > Attached to this email is a bash script I've made to perform all of > these optimisations on any Canonical-supported Ubuntu 10.04 > LiveCD image, almost automatically. (After optimisations are done, you > can check the state of the LiveCD in a bash shell from within it. The > rest is fully automatic.) > > The real savings would come from optimising the PNG and SVG images > right in the packages themselves, not just the LiveCD. Given a > directory containing PNG and SVG images, the part of my script dealing > with OptiPNG and Scour.py can automatically optimise these files. The > best candidate for such a Scouring would be ubuntu-docs, as it has > tons of PNG images. Most application packages have an SVG icon or two > as well. > > Thanks for your time! > - Louis -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
LiveCD optimisations
Greetings ubuntu-devel-discuss :) I have a proposal for you, and I'll present it simply with the 5 W's. -- WHAT? -- Optimise the PNG images and SVG files on the Ubuntu LiveCD. Optimise the Ubuntu LiveCD by putting start-up files and programs near the end of the CD. -- WHY? -- Optimising the PNG images saves 5.5 MB on the filesystem.squashfs. Optimising the SVG files saves an additional 7 MB. This is a total of 12.5 MB which could be used to pack more software or another language pack or two onto the LiveCD. Optimising the CD to put files at the end allows it to boot marginally faster (about 10 seconds on my benchmarks), start applications faster, and allows the CD drive on a user's computer to run quieter while using his/her applications, as reading near the end (edge of the disc) requires slower spinning. These changes will give prospective users a better view of Ubuntu right from the LiveCD. There might also be additional benefits to having smaller PNG and SVG images, such as saving space on a user's hard disk when installed. The uncompressed (pre-squashfs) savings for the SVG images is 18 MB. -- WHEN? -- Now! :) Just kidding. As soon as possible would be nice. Maybe even for the next Ubuntu version, codename Maverick Meerkat! -- WHO? -- Ubuntu developers. But don't go thinking that you'll do all the grunt work of testing these optimisations for yourself! (See HOW? below) -- HOW? -- Attached to this email is a bash script I've made to perform all of these optimisations on any Canonical-supported Ubuntu 10.04 LiveCD image, almost automatically. (After optimisations are done, you can check the state of the LiveCD in a bash shell from within it. The rest is fully automatic.) The real savings would come from optimising the PNG and SVG images right in the packages themselves, not just the LiveCD. Given a directory containing PNG and SVG images, the part of my script dealing with OptiPNG and Scour.py can automatically optimise these files. The best candidate for such a Scouring would be ubuntu-docs, as it has tons of PNG images. Most application packages have an SVG icon or two as well. Thanks for your time! - Louis ubuntu-optimisations.sh Description: Bourne shell script -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Replace Shotwell (was F-Spot) with Solang?
As far as I know, Solang was even removed from Debian due to it being highly unstable. On Thu, May 20, 2010 at 08:58, Danny Piccirillo wrote: > I'm forwarding this to the ubuntu-desktop list to see if they can > point out why Shotwell was chosen over Solang, and whether it is too > late to change this decision or postpone the change until Maverick+1 > > On Sat, May 15, 2010 at 17:28, Laco Gubík > wrote: > > Hi, > > > > I would like to see this discussion by myself, but I cannot find. > > Maybe it will appear here [1] in following days. > > In terms off holding it until Maverick+1, I think that Canonical > > considers non-LTS releases more like development releases, where they > > do not mind if something is suboptimal. So they prefer to do changes > > striaght after LTS release, so there is time to polish it until next > > LTS. (On the other hand we have seen changes with significant impact > > also in LTS, so one never know.). > > > > Regards > > > > Laco > > > On Sat, May 15, 2010 at 13:28, Danny Piccirillo > wrote: > > 2010/5/15 Marco Laverdière : > >> > >>> Also, there were specific reasons as to why Shotwell isn't ready, but > >>> for Solang it was just, yeah this isn't ready either. What > >>> specifically would you like to see in Solang for it to be considered > >>> ready? > >> > >> > >> For me, wheher it is Solang (hypothetically) or Shotwell (as > announced), a > >> decent replacement for F-Spot should provide the following: > >> > >> - continuity for the regular Ubuntu/F-Spot user, i.e. ability to import > >> F-Spot tags easily, whether from F-Spot database or from pictures XMP > >> embedded metadata (ideally, F-Spot tag hierarchy should also be > preserved, > >> i.e. for people, place, event. etc.); > > > > This would be ideal, but i don't see this happning in time for > > Maverick. If people see this as a requirement it might be better to > > hold off until Maverick +1 > > > >> -beign able to embed tags in file, preferably in XMP or otherwise, in > IPTC; > > > > I believe this is possible, but someone should verify > > > >> - same (or almost) set of basic editing functions than F-Spot; > > > > F-Spot needed editing capabilities added if i remember correctly, > > while this has been part of the solang vision from the beginning. > > > >> - same level of integration with other graphics/imaging Ubuntu/Gnome > apps, > >> like with Gimp and Eye of GNOME (F-Spot allows the user to switch nicely > to > >> Gimp for advanced editing; EOG allows the user to open the viewed > picture > >> with F-Spot, etc.). > > > > For starters, Solang uses Tracker. From amano on > > > https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-maverick-desktop-application-selection > > > > "Solang is a C++ photo editor that does't use a complicated Database > > for importing and exporting and should be more intuitive for new > > users. I might try to create a discspace vs. RAM usage vs. feature vs. > > usability overview by the weekend. I hate the tendency of F-Spot to > > duplicate pictures on your harddisk (original location, ~/Photo folder > > and inside the database as well). If there are thousands of pictures > > to be imported, you might easily run out of disk space. And database > > corruptions/confusions are not impossible as well. > > > > For now I can offer this video review of the Vala based Shotwell: > > > http://linuxfilesystem.com/uncategorized/shotwell-photo-manager-for-gnome-linux-mint-8 > . > > It is database driven and doesn't recognize if you added new files to > > one of your photo folders (same for F-Spot). Thus new photos have to > > imported manually which can be tiresome. The C++ based Solang uses > > Tracker 0.8 to check the photo folders and SPARQL is used to gain > > access to the meta information about the photos. This approach looks > > perfectly sane but with its current version 0.4.1 it lacks the option > > to crop and resize files > > (http://git.gnome.org/browse/solang/tree/TODO?id=SOLANG_0_4_1) which > > is rather a "must have" since the removal of the GIMP (given that the > > simple-image-management blueprint doesn't bring to life a 'simple > > scan' for image editing). On the other hand it is developed at a rapid > > pace and those options might be included by the maverick feature > > freeze. To get a sensible decision in favor of Solang the authors > > should be contaced first. Shotwell on the other hand is not too > > different from F-Spot but is developed faster and performs better than > > the current default." > > > >> In other words, let's avoid a regression here... > > > > Agreed. I say we should hold off the change until Maverick +1 and plan > > on working to make Solang a good fit. > > > > -- > > .danny > > > > ☮♥Ⓐ - http://www.google.com/profiles/danny.piccirillo > > Every (in)decision matters. > > > > > > -- > .danny > > ☮♥Ⓐ - http://www.google.com/profiles/danny.piccirillo > Every (in)decision matters. > > -- > Ubuntu-devel-discuss mailing list > Ubuntu-devel-discus
Re: Replace F-Spot with Solang?
On Sat, May 15, 2010 at 11:12 AM, Danny Piccirillo wrote: > Why was Shotwell chosen over Solang? It seems the only motivation for > shotwell is to try Vala. Solang seems to already be in line with what > we need and want. Is there a link to where this decision was made so > we can see the discussion rather than just an announcement? Some > people think that neither solang or shotwell will be ready in time for > maverick, and as much as i'd love to see F-spot replaced sooner, i > wouldn't want to upset users like what happened with empathy (although > i'm sure it wouldn't be close to that bad). Perhaps this should be > held off until Maverick +1? > > Also, there were specific reasons as to why Shotwell isn't ready, but > for Solang it was just, yeah this isn't ready either. What > specifically would you like to see in Solang for it to be considered > ready? > > On Sat, May 15, 2010 at 09:42, Laco Gubík wrote: >> Hi, >> >> According this article [1], Shotwell is replacing F-spot in Maverick. >> Article says that this was agreed at UDS. Personally I don't understand what Shotwell gives us over F-spot besides a better memory footprint. What Shotwell does lack, however, is a fairly well rounded Edit functionality. While F-spot's editing could use some improvements, it offers a lot of easy-to-use adjustments such as soft focus, sepia tone, desaturate, etc. All Shotwell offers for simple photo editing is an unfriendly group of sliders to adjust temperature, exposure, tint, etc. Until Shotwell or some other organizer gets a more robust and usable editing interface, I don't see how we can throw out F-spot. Jonathan -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
