Re: Solang or Shotwell vs. F-Spot for Lucid
Le lundi 07 décembre 2009 à 21:24 -0500, Danny Piccirillo a écrit : Before too much effort is invested into making F-Spot good enough to meet all of the needs outlined at the UDS Default App Selection session, i thought i should bring up Solang and Shotwell to see if it might be worth including instead of F-Spot in Lucid, or if it's too late, in Lucid +1. Hi, Thank you for raising the topic. What effort are you speaking about exactly there though? The only change we needed was the edit options to be available in view mode basically and upstream already fixed that one. GTumb has been discussed, but it doesn't seem to deliver the goods. Why not? Somebody pointed recently a post about gthumb, the code has been refactored recently apparently and the new version looks quite good Solang is new, yet it's developed quickly and is showing a lot of promise. Shotwell might also be a contender worth discussing, but i am unfamiliar with it. Hopefully someone else has some insights as to how Shotwell compares to Solang and F-Spot. We have something not perfect right now but working ok for common use, it seems risky to want to change to some new codebase in a lts cycle especially when we don't know how reliable upstream is and when those softwares have not been exposed to real user testing and feedback yet. * A major issue with F-Spot that Solang doesn't have is that you have to move images to import them into the library. Do you? The import dialog has a checkbox about copy that you can uncheck * F-Spot is much more resource intensive than Solang Do you have numbers on that? Solang, Shotwell, and F-Spot are all fine image managers/organizers, but the current plan is to work on F-Spot to get it to meet the following needs: * Quickly viewing images by folder [currently handled by EOG] * Solang and F-Spot both have view-modes but still require importing the image. Shotwell might not. No, the f-spot --view mode doesn't require to import anything... * Editing images without importing (Shotwell does this) * Rotating [currently handled by EOG] * Red-eye removal [currently handled by GIMP] * Cropping [currently handled by GIMP] those are done by f-spot as well Although the interface has been cleaned up, it just feels heavy. The comment there is about the user interface or the opening speed, reactivity to actions, ...? It's worth reconsidering how much work should be put in to F-Spot when other projects seem to be progressing faster. If this much work is going to be invested as it is, we should consider whether it might be better to focus on Solang instead. Shotwell might already meet many of these needs, and need significantly less work. We don't put too many efforts in f-spot, the work is done mostly by upstream and the packaging is done mostly by Debian, we just try to issues reported on launchpad and work with upstream on the ones we consider worth trying to fix for the next version. Where did you get that the other projects are moving faster too? They might have extra work to put to catch up with what f-spot does now. The timeline view is rather nice to use and f-spot has quite some other options. Did anybody looked at how those other software handle exporting to flick, picasa or other web services? Please look into both Solang and Shotwell and post your thoughts. Thanks! I will let other people comment on those, but changing a known codebase for new project in a lts cycle doesn't seem a good move from there Sebastien Bacher -- 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: karmic trashed in Tomshardware.com
Well over here carried out 2 upgrades and 2 fresh installs so far. Couple of minor issues but nothing bug worthy. We use nVidia cards and dual monitors - had the 'cannot parse xorg.conf' documented issue when configuring twinview (simple enough to sort out). Also had an issue with filesystem performance on ext3 and ext4 with ordered journaling and grails (groovy on rails) which caused ~50% I/Owait on running tests and consequently very slow performance. Tests running took 4x as long as on jaunty Mounting with a writeback journal and noatimes brought performance back in line. Given these were desktops the possible loss in FS reliability on crash is an acceptable tradeoff for the reduced testing time or else productivity takes a big hit. 2009/12/8 Paul Smith p...@mad-scientist.us On Tue, 2009-12-08 at 11:07 +0800, Tim Hawkins wrote: I dont know if it is relevant, but looking at the specs of the two unstable machines listed in the article, both had nVidia chipsets The one machine (netbook) that they said worked perfectly had an Intel Graphics chipset. Given the amount of discussion relating to problems with the nVidia drivers in Karmic, could this be a factor in this review.? One never knows, of course, but FYI I have one system at home with an Intel graphics chipset, and two systems at work both with Nvidia cards using the proprietary drivers (both have dual monitors attached). All three work just fine in Karmic, and have from the beginning (no upgrade issues to speak of). We've upgraded probably about 15 systems at work and only two problems: one was that the screensaver enabled during the upgrade and, since that person was mounting their home directory over NFS and it tried to restart NFS, badness happened so that we couldn't get rid of the screensaver by hand, and it was putting up a dialog asking about overwriting some file. I had to C-A-F1, login there, and kill it; the upgrade finished just fine from there. The other I'm not sure what happened: they did it while I wasn't around :-) I did see a problem on my system at home (Intel graphics) when I had the screensaver set to Random: my kernel panicked twice in one day while I was away from my desk. I switched back to Blank which is what I always use anyway, and haven't seen a single glitch since. I'm assuming there're one or more bugs still in the Intel driver WRT GL graphics or similar. -- 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 -- 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: karmic trashed in Tomshardware.com
Am 08.12.2009 um 11:03 schrieb James Hogarth: Given these were desktops the possible loss in FS reliability on crash is an acceptable tradeoff Neither crashes nor less than 100% file system reliabilty are acceptable. Never ever. An operating system isn't a children's playground. Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/ -- 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: Solang or Shotwell vs. F-Spot for Lucid
On Tue, Dec 8, 2009 at 10:57 AM, Sebastien Bacher seb...@ubuntu.com wrote: Did anybody looked at how those other software handle exporting to flick, picasa or other web services? For Shotwell uploading to Flickr and Facebook is planned for 0.4 which is to be released in December. Picasa is planned for a later version. Btw. an important feature missing from all available programs is uploading to online print services. A list of all planned features is here: http://trac.yorba.org/report/16 An (incomplete) comparison of photo managers is on their wiki: http://trac.yorba.org/wiki/ShotwellFeatureComparison Solang also has exporting to webservices on the todo list, but they also have more extensive plans: acting as a front-end to them, as a photo manager for both your photos on the desktop and in the cloud. Cheers, Wouter -- 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: Supporting a GNU Hurd port?
On Tue, 2009-12-08 at 01:38 -0500, Danny Piccirillo wrote: A GNU Hurd port may not be for most users, but i was wondering if we had the resources to support such a port as Debian does, and if it would be worth the effort. I think it would be cool, but are there any reasons against this? Speaking as the guy who maintains the boot and plumbing layer, I am completely and utterly uninterested in such a port. All of the improvements made in this layer, leading to things like fast boot, fast suspend resume, reliable hotplug, etc. have been fundamentally done by forgetting about portability and writing software designed *only* for Linux. If you wanted to do a Hurd port (or BSD port), you'd basically have to redo all of this work from scratch again. I don't think there's ever a reason to say we won't switch kernels one day, one day Linux might not be the best kernel. If we ever do that, it would be a complete flag day switch. I am firmly against trying to support two kernels with one userland. Scott -- Scott James Remnant sc...@ubuntu.com signature.asc Description: This is a digitally signed message part -- 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
is anyone ever going to fix this major bug?
This bug more or less makes apt-get unusable on 64 bit systems and has been in for a long time now: https://bugs.launchpad.net/ubuntu/+bug/402833 On a side note, I have no idea how to bring bugs to the attention of developers, or if it is even possible, as this bug has sat in the bugtracker without being even triaged for months. If no one actually uses the bug tracker, maybe take it down so people don't waste their time reporting bugs... -- 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
gfortran and g77
It seems that as of gcc-4 (or on the Ubuntu timeline, Intrepid), g77 has been superseded by gfortran. Unfortunately, it seems that the gfortran packaging was not updated to account for this fact: gfortran does not provide an alternative for f77. I believe this should not be the case, as according to reliable sources[1], gfortran should now be a drop-in alternative to g77 in most cases. I've opened a launchpad bug (LP #494209 [2]) for this issue. Hope things are going well, - Ben [1] http://en.wikipedia.org/wiki/Gfortran [2] https://bugs.launchpad.net/ubuntu/+source/gcc-defaults/+bug/494209 -- 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: is anyone ever going to fix this major bug?
This is an organizational problem. Waving hands and saying the community should do it is nice if it works, but it obviously hasn't happened. I personally would feel much more happy if you email also included a patch... Well than why is there a public bug tracker if you guys just want patches on the mailing list? I took the time out to gather information from the forums, come up with a bug report, and document workarounds. So did someone else as well (my bug got marked as a dupe, so I pasted the link to the other guys bug, which had some more info). The bug was never read over a span of months, so I'm pointing out that there's clearly an organizational problem whereby the bug database has turned into a black hole of user frustration. The same could be said of all the problems that get worked around a different way in every release on the forums, but never get fixed in Ubuntu proper. Clearly, no on is trawling through for bugs there. I'm doing my little part by letting you guys know how broken everything is, whether in the product or in the process. If that's not enough, I won't bother in the future. -- 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: is anyone ever going to fix this major bug?
On Tue, 8 Dec 2009 16:59:34 -0800 Brendan Miller catph...@catphive.net wrote: This is an organizational problem. Waving hands and saying the community should do it is nice if it works, but it obviously hasn't happened. It's a resource problem. Most developers keep an eye on bugs in specific packages they tend to focus on. We cannot keep track of all bugs in 20,000 packages with (last I checked) fewer than 200 developers. What we need is more people finding bugs that have fixes (like I gather this one is) and bringing them to the attention of developers. The best way to do this is through the sponsorship process (bug management via mailing list doesn't scale). If the ubuntu-universe-sponsors team were subscribed to the bug, then a developer would review it. In short, yes we do look at bugs, but we also need help. Scott K -- 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: karmic trashed in Tomshardware.com
I like how they blamed the software center UI for repo slowness. Clearly a well thought out article. Dan --- Life, Liberty, and the pursuit of Open Standards! Sent from Gainesville, FL, United States On Mon, Dec 7, 2009 at 6:13 PM, Patrick Goetz pgo...@mail.utexas.eduwrote: I've been out of the loop for a couple of months, so pardon me if this has already been discussed, but Karmic got thoroughly trashed in a TomsHardware.com review: http://www.tomshardware.com/reviews/ubuntu-karmic-koala,2484.html Some of these issues (system freezes when copying large files on ext4) I've never heard of before. My personal gripes with karmic were finding out that fakeraid now doesn't work at all, a regression caused by grub2 (https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/392136) and that the network applet, nm-applet still doesn't work in a multi-user context: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/284596 Either of these is a deal killer for some significant fraction of users (e.g. dual booters or household shared PC users, respectively). -- 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 -- 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: Solang or Shotwell vs. F-Spot for Lucid
The bizarrely obnoxious bit about F-Spot import is that it copies everything to your photos folder BEFORE you actually accept the import. Then, if you don't accept it, it deletes them... which is just Bad Behavior. On Tue, Dec 8, 2009 at 4:57 AM, Sebastien Bacher seb...@ubuntu.com wrote: Le lundi 07 décembre 2009 à 21:24 -0500, Danny Piccirillo a écrit : Before too much effort is invested into making F-Spot good enough to meet all of the needs outlined at the UDS Default App Selection session, i thought i should bring up Solang and Shotwell to see if it might be worth including instead of F-Spot in Lucid, or if it's too late, in Lucid +1. Hi, Thank you for raising the topic. What effort are you speaking about exactly there though? The only change we needed was the edit options to be available in view mode basically and upstream already fixed that one. GTumb has been discussed, but it doesn't seem to deliver the goods. Why not? Somebody pointed recently a post about gthumb, the code has been refactored recently apparently and the new version looks quite good Solang is new, yet it's developed quickly and is showing a lot of promise. Shotwell might also be a contender worth discussing, but i am unfamiliar with it. Hopefully someone else has some insights as to how Shotwell compares to Solang and F-Spot. We have something not perfect right now but working ok for common use, it seems risky to want to change to some new codebase in a lts cycle especially when we don't know how reliable upstream is and when those softwares have not been exposed to real user testing and feedback yet. * A major issue with F-Spot that Solang doesn't have is that you have to move images to import them into the library. Do you? The import dialog has a checkbox about copy that you can uncheck * F-Spot is much more resource intensive than Solang Do you have numbers on that? Solang, Shotwell, and F-Spot are all fine image managers/organizers, but the current plan is to work on F-Spot to get it to meet the following needs: * Quickly viewing images by folder [currently handled by EOG] * Solang and F-Spot both have view-modes but still require importing the image. Shotwell might not. No, the f-spot --view mode doesn't require to import anything... * Editing images without importing (Shotwell does this) * Rotating [currently handled by EOG] * Red-eye removal [currently handled by GIMP] * Cropping [currently handled by GIMP] those are done by f-spot as well Although the interface has been cleaned up, it just feels heavy. The comment there is about the user interface or the opening speed, reactivity to actions, ...? It's worth reconsidering how much work should be put in to F-Spot when other projects seem to be progressing faster. If this much work is going to be invested as it is, we should consider whether it might be better to focus on Solang instead. Shotwell might already meet many of these needs, and need significantly less work. We don't put too many efforts in f-spot, the work is done mostly by upstream and the packaging is done mostly by Debian, we just try to issues reported on launchpad and work with upstream on the ones we consider worth trying to fix for the next version. Where did you get that the other projects are moving faster too? They might have extra work to put to catch up with what f-spot does now. The timeline view is rather nice to use and f-spot has quite some other options. Did anybody looked at how those other software handle exporting to flick, picasa or other web services? Please look into both Solang and Shotwell and post your thoughts. Thanks! I will let other people comment on those, but changing a known codebase for new project in a lts cycle doesn't seem a good move from there Sebastien Bacher -- 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 -- 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: Solang or Shotwell vs. F-Spot for Lucid
Actually, it seems to start importing as soon as you select a folder... then the dialog remains locked until it reads all the files in it. 2009/12/8 caleb.marcus+u-d-d caleb.marcus+u-...@gmail.comcaleb.marcus%2bu-...@gmail.com The bizarrely obnoxious bit about F-Spot import is that it copies everything to your photos folder BEFORE you actually accept the import. Then, if you don't accept it, it deletes them... which is just Bad Behavior. On Tue, Dec 8, 2009 at 4:57 AM, Sebastien Bacher seb...@ubuntu.comwrote: Le lundi 07 décembre 2009 à 21:24 -0500, Danny Piccirillo a écrit : Before too much effort is invested into making F-Spot good enough to meet all of the needs outlined at the UDS Default App Selection session, i thought i should bring up Solang and Shotwell to see if it might be worth including instead of F-Spot in Lucid, or if it's too late, in Lucid +1. Hi, Thank you for raising the topic. What effort are you speaking about exactly there though? The only change we needed was the edit options to be available in view mode basically and upstream already fixed that one. GTumb has been discussed, but it doesn't seem to deliver the goods. Why not? Somebody pointed recently a post about gthumb, the code has been refactored recently apparently and the new version looks quite good Solang is new, yet it's developed quickly and is showing a lot of promise. Shotwell might also be a contender worth discussing, but i am unfamiliar with it. Hopefully someone else has some insights as to how Shotwell compares to Solang and F-Spot. We have something not perfect right now but working ok for common use, it seems risky to want to change to some new codebase in a lts cycle especially when we don't know how reliable upstream is and when those softwares have not been exposed to real user testing and feedback yet. * A major issue with F-Spot that Solang doesn't have is that you have to move images to import them into the library. Do you? The import dialog has a checkbox about copy that you can uncheck * F-Spot is much more resource intensive than Solang Do you have numbers on that? Solang, Shotwell, and F-Spot are all fine image managers/organizers, but the current plan is to work on F-Spot to get it to meet the following needs: * Quickly viewing images by folder [currently handled by EOG] * Solang and F-Spot both have view-modes but still require importing the image. Shotwell might not. No, the f-spot --view mode doesn't require to import anything... * Editing images without importing (Shotwell does this) * Rotating [currently handled by EOG] * Red-eye removal [currently handled by GIMP] * Cropping [currently handled by GIMP] those are done by f-spot as well Although the interface has been cleaned up, it just feels heavy. The comment there is about the user interface or the opening speed, reactivity to actions, ...? It's worth reconsidering how much work should be put in to F-Spot when other projects seem to be progressing faster. If this much work is going to be invested as it is, we should consider whether it might be better to focus on Solang instead. Shotwell might already meet many of these needs, and need significantly less work. We don't put too many efforts in f-spot, the work is done mostly by upstream and the packaging is done mostly by Debian, we just try to issues reported on launchpad and work with upstream on the ones we consider worth trying to fix for the next version. Where did you get that the other projects are moving faster too? They might have extra work to put to catch up with what f-spot does now. The timeline view is rather nice to use and f-spot has quite some other options. Did anybody looked at how those other software handle exporting to flick, picasa or other web services? Please look into both Solang and Shotwell and post your thoughts. Thanks! I will let other people comment on those, but changing a known codebase for new project in a lts cycle doesn't seem a good move from there Sebastien Bacher -- 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 -- 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: karmic trashed in Tomshardware.com
On Mon, 2009-12-07 at 17:13 -0600, Patrick Goetz wrote: I've been out of the loop for a couple of months, so pardon me if this has already been discussed, but Karmic got thoroughly trashed in a TomsHardware.com review: http://www.tomshardware.com/reviews/ubuntu-karmic-koala,2484.html Some of these issues (system freezes when copying large files on ext4) I've never heard of before. If its anything like what I see on ext3, I have been plagued by that for many years. I have heard rumors 2.6.32 in Lucid traded off some performance to hopefully finally fix this issue, I sure hope so anyway. My personal gripes with karmic were finding out that fakeraid now doesn't work at all, a regression caused by grub2 (https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/392136) and that the network applet, nm-applet still doesn't work in a multi-user context: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/284596 Either of these is a deal killer for some significant fraction of users (e.g. dual booters or household shared PC users, respectively). -- 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: karmic trashed in Tomshardware.com
On Tue, 2009-12-08 at 22:53 -0600, Chris Cheney wrote: On Mon, 2009-12-07 at 17:13 -0600, Patrick Goetz wrote: I've been out of the loop for a couple of months, so pardon me if this has already been discussed, but Karmic got thoroughly trashed in a TomsHardware.com review: http://www.tomshardware.com/reviews/ubuntu-karmic-koala,2484.html Some of these issues (system freezes when copying large files on ext4) I've never heard of before. If its anything like what I see on ext3, I have been plagued by that for many years. I have heard rumors 2.6.32 in Lucid traded off some performance to hopefully finally fix this issue, I sure hope so anyway. After reading close 'freezes' above seems to refer to complete hang of the system, not just not being able to do anything else on the system while the system is doing a copy. That is what I see on my systems and was referring to having been fixed in 2.6.32. Chris -- 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
