Re: Wiki lost forms (was Foundations team meeting minutes, 2008-09-10)
Olá Colin e a todos. On Thursday 11 September 2008 14:23:36 Colin Watson wrote: > * lose two hours of work to the wiki deciding not to accept my new page, my > browser not saving my form contents, and me not thinking to save the content > somewhere else before hitting 'Save Changes' This might help: Firefox addon textarea http://hemiolapei.free.fr/extensions/index.php/textarea-cache -- BUGabundo :o) (``-_-´´) http://LinuxNoDEI.BUGabundo.net Linux user #443786GPG key 1024D/A1784EBB My new micro-blog @ http://BUGabundo.net ps. My emails tend to sound authority and aggressive. I'm sorry in advance. I'll try to be more assertive as time goes by... 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
Re: Boot-time improvements
2008/9/11 Mackenzie Morgan <[EMAIL PROTECTED]>: > On Thu, 2008-09-11 at 12:57 +0200, Krzysztof Lichota wrote: >> That's what have been done by Microsoft for XP - they had the goal to >> bring boot time to 30s and managed to do it. Apparently they forgot to >> do the same for Vista ;) > > But as mentioned before, they did it by shoving off a bunch of the stuff > til after the desktop shows so that it's unusable for a few minutes > after login while the hard drive churns away. Yes. But users see the desktop after 30 seconds and they think Linux is slow to boot. It is psychological thing. > And 30s is considered bringing it down? Wow, how long was it before? > Is there a goal we have for boot time? 30s seems about average for boot > time right now. At least, all of my laptops boot in 25-35 seconds. You have 25-35 seconds from GRUB till desktop appearing (using autologin)? -- Krzysztof Lichota -- 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: Boot-time improvements
2008/9/11 Krzysztof Lichota <[EMAIL PROTECTED]>: > As an author of Prefetch, I cannot agree that it would not fix seeks ;) > Part of my implementation, not enabled by default as it is highly > experimental, is ext3 defragmenter which puts all files for prefetch > in one place on disk, so the requests to read them can be merged into > big streaming reads. I stand happily corrected :) Hopefully you will get some help in testing the defragmenter and getting that part stable in time, too. The hard part in the whole prefetch is probably it being kernel-based, but the diff [1] seemed quite non-invasive, ie. only a few calls in the existing kernel code and then some new calls. [1] http://code.google.com/p/prefetch/source/browse/#svn/trunk/kernel-patches/2.6.22 -Timo -- 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: Boot-time improvements
2008/9/12 Chris Jones <[EMAIL PROTECTED]>: > I'm not quite sure what all the ranting is all about regarding Ubuntu > boot times. I never really even thought of it until it was mentioned on > the mailing list here. So, as a test, I timed my own system how long it > takes to boot. From GRUB boot to login screen, it was 36.72 secs. And > that is on a Celeron D with 512MB DDR RAM and booting from an old IDE > hard drive. I'd imagine that a more recent dual core setup with more ram > and a more recent sata hard drive would have better results. But my mere > 36 secs is certainly nothing to rant about. Most of the seeks (small file reads) happen when loading desktop environment and it takes substantial part of boot time. Enable autologin and then measure boot time until the desktop appears. Faster CPUs, more memory and even faster disks do not help much to fight time wasted on disk seeks. -- Krzysztof Lichota -- 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: Boot-time improvements
2008/9/12 Chris Jones <[EMAIL PROTECTED]>: > the mailing list here. So, as a test, I timed my own system how long it > takes to boot. From GRUB boot to login screen, it was 36.72 secs. And > that is on a Celeron D with 512MB DDR RAM and booting from an old IDE > hard drive. I'd imagine that a more recent dual core setup with more ram > and a more recent sata hard drive would have better results. But my mere > 36 secs is certainly nothing to rant about. One problem is that the dual core setups do not help that much because the bottle-neck is in hard drives which haven't gotten speedier at all in the last 15 years regarding seek times, and even transfer speeds are relatively slowly increasing compared to other aspects. Especially dual-core laptops are largely as slow to boot as desktop computers from 2-5 years ago, because of the slower hard disks. The other problem is that logging into GNOME often takes the same time it takes from GRUB to GDM. The aim would be IMHO something like 15-20s from GRUB to GNOME desktop on a modern _laptop_ computer, with smooth transitions. -Timo -- 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: Boot-time improvements
2008/9/12 Timo Jyrinki <[EMAIL PROTECTED]>: > 2008/9/11 Krzysztof Lichota <[EMAIL PROTECTED]>: >> As an author of Prefetch, I cannot agree that it would not fix seeks ;) >> Part of my implementation, not enabled by default as it is highly >> experimental, is ext3 defragmenter which puts all files for prefetch >> in one place on disk, so the requests to read them can be merged into >> big streaming reads. > > I stand happily corrected :) Hopefully you will get some help in > testing the defragmenter and getting that part stable in time, too. > The hard part in the whole prefetch is probably it being kernel-based, > but the diff [1] seemed quite non-invasive, ie. only a few calls in > the existing kernel code and then some new calls. Thanks. There are some rough edges in patches themselves which should be straightened out. And the feedback on using prefetch was pretty much non-existing. -- Krzysztof Lichota -- 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: The Case For Re-Evaluating Our Release Approach To FFMPEG
2008/9/10 Reinhard Tartler <[EMAIL PROTECTED]>: > "Null Ack" <[EMAIL PROTECTED]> writes: > >> Summary : I think we need to have regular snapshots of svn ffmpeg, >> libavcodec and so forth released in both the current development build >> and as backports to production builds. User's expect to have video >> experiences atleast as good as Windows and Mac, and this is necessary >> for actually delivering that. > > The main problem is lack of manpower. Every time ffmpeg is updated, we > can more or less expect applications and libraries that use them to > break. > > FWIW, the next upstream snapshot that I'm preparing for > debian/experimental right now is going to drop nearly all > patches. Packaging new snapshots should become pretty easy then. > Thanks for the responses guys. Reinhard I'm excited to hear about the progress with dropping many patches and streamlining the process for synching from SVN. I'm also thankful for your interest in bug 263153 which I think is likely fixed in the latest gstreamer ffmpeg plugin release. I understand about person power and I will comit to helping you with testing new ffmpeg releases and related applications. I have a test library that involves many different containers and compression types and other features. I'm somewhat new to gstreamer but I've got a pretty solid understanding of digital media technologies and practices. -- 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: Backtracing, Invalidated Bugs and Quality
Thanks for all the discussion on this folks. :) Just now I had a crash in totem with apport leading me to 9 previously reported bugs that are either invalid or incomplete because the bug reporter did not do a backtrace to help fix the problem. Now I have the same issue, when it was originally reported in the first bug report all the way back in May 2007 with no concrete progress since. On top of this, people have said that its a recurring discussion that comes up every six months or so, so lets fix this eh. To recap, I've suggested that all Alpha builds could be debug by default builds. Others, such as Markus have what I frankly think is a better idea where apport tells the user the situation and downloads a debug version of the package and waits for it to occur again. Then it sends the backtrace to the right bug for analysis. Krzysztof seemed to have a promising idea similar to apparently what MS do "The information about debugging symbols is only needed on server, client only sends (in simplest version) MD5 sum of library and address offset, which is transformed into the symbol by symbol serve" Can we focus on a debate about what the best approach is? This in turn can lead to the details with implementation. Thanks Nullack -- 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: Boot-time improvements
2008/9/12 Oliver Grawert <[EMAIL PROTECTED]>: >> You have 25-35 seconds from GRUB till desktop appearing (using autologin)? > > i have managed 22 already with a not to drastic set of modifications (19 > after grub [1] plus the three second grub timeout) with the ten seconds > my BIOS takes that even stays below 35 for the complete boot process > from hitting power button to see gdm. That's not "till desktop appearing (using autologin)". People often speak about different things when saying "boot", but regardless of the term used the interest here is "when the desktop is usable" after powering up the computer. It can be measured by temporarily activating auto-login in gdm setup to bypass gdm. It can even double that figure, and it's the figure which we are interested in. One cannot do much work with gdm. Like I said, I'd say the aim should be around 15-20s ultimately on modern (but non-SSD) laptops for GRUB-to-desktop, since we cannot affect BIOS-to-GRUB at the moment. Though that cannot be reached without fully using prefetch or having GNOME login optimized otherwise very heavily. > i think we still have to do our homework first and get the existing stuff > into a > reasonable shape I agree that every optimization counts, even if it's small (but a lot of small fixes make for a bigger change). -Timo -- 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: Boot-time improvements
hi, On Do, 2008-09-11 at 22:44 +0300, Marius Gedminas wrote: > Here's my 1:28 bootchart: http://mg.pov.lt/hardy-20080822-1.png > > There are at most 4 seconds of idle waiting. > > Hey, I see zope2.9 taking quite a bit of the time (20 seconds). I no > longer need that. sudo apt-get remove to the rescue! > > And here's my 1:09 bootchart: http://mg.pov.lt/hardy-20080822-3.png. > It also has zope2.9, but I don't see offhand why it is 20 seconds > shorter than the first one. What is that 'exe' process near the start? thats usually the execution bit of the bar above ... in your first bootchart modprobe seems to do some horrible things ... also, do you actually have any hardware that uses restricted drivers ? dropping lrm should gain you some extra time as well if you dont ... the second udevd seems to produce some zombies in both bootcharts ... it would be intresing to see the same boot without mysql, postifix, zope and autofs though ... ciao oli 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
Re: Boot-time improvements
hi, On Fr, 2008-09-12 at 09:23 +0200, Krzysztof Lichota wrote: > You have 25-35 seconds from GRUB till desktop appearing (using autologin)? i have managed 22 already with a not to drastic set of modifications (19 after grub [1] plus the three second grub timeout) with the ten seconds my BIOS takes that even stays below 35 for the complete boot process from hitting power button to see gdm. (the mem=256M you see in the kernel options is there from a different test, it doesnt influence bootspeed) note that this was after using the profile bootoption for readahed though. for jaunty i would like to propose to install bootchart by default during the development cycle with an optional upload function to a central database (with a first login question "do you want to participate in the boot profiling project and upload your logged boot data to a central db" or some such). that should enable us to identify the slowdowns ... while preload and friends are surely nicely speeding up i think we still have to do our homework first and get the existing stuff into a reasonable shape, you can get to a default of 25-35sec for a generic boot. ciao oli [1] http://people.ubuntu.com/~ogra/hardy-20080523-1.png 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
Re: Boot-time improvements
On Fri, 2008-09-12 at 09:23 +0200, Krzysztof Lichota wrote: > 2008/9/11 Mackenzie Morgan <[EMAIL PROTECTED]>: > > And 30s is considered bringing it down? Wow, how long was it before? > > Is there a goal we have for boot time? 30s seems about average for boot > > time right now. At least, all of my laptops boot in 25-35 seconds. > > You have 25-35 seconds from GRUB till desktop appearing (using autologin)? No, til login prompt. I've never used autologin. I'm just reading my bootcharts, and those stop at GDM. I wasn't counting GNOME's slow login as part of boot, since by the time you can login, it's booted. -- Mackenzie Morgan http://ubuntulinuxtipstricks.blogspot.com apt-get moo 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
Re: Boot-time improvements
On Fri, 2008-09-12 at 11:47 +0200, Oliver Grawert wrote: > hi, > On Do, 2008-09-11 at 22:44 +0300, Marius Gedminas wrote: > > Here's my 1:28 bootchart: http://mg.pov.lt/hardy-20080822-1.png > > > > There are at most 4 seconds of idle waiting. > > > > Hey, I see zope2.9 taking quite a bit of the time (20 seconds). I no > > longer need that. sudo apt-get remove to the rescue! > > > > And here's my 1:09 bootchart: http://mg.pov.lt/hardy-20080822-3.png. > > It also has zope2.9, but I don't see offhand why it is 20 seconds > > shorter than the first one. What is that 'exe' process near the start? > thats usually the execution bit of the bar above ... in your first > bootchart modprobe seems to do some horrible things ... also, do you > actually have any hardware that uses restricted drivers ? > dropping lrm should gain you some extra time as well if you dont ... Now you mention it, removing l-r-m is one of the first things I do. Second is disable bluetooth. I don't think the bluetooth service should be enabled unless bluetooth hardware is detected. Perhaps these need to be made smarter. If the hardware's not there, don't bother adding it. -- Mackenzie Morgan http://ubuntulinuxtipstricks.blogspot.com apt-get moo 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
Re: Boot-time improvements
On Fri, 2008-09-12 at 09:35 +0200, Krzysztof Lichota wrote: > Thanks. There are some rough edges in patches themselves which should > be straightened out. And the feedback on using prefetch was pretty > much non-existing. What is the recommended way of enabling prefetch to test? And can it be tested by people still using Hardy? There are 5 Ubuntu laptops in the room right now... -- Mackenzie Morgan http://ubuntulinuxtipstricks.blogspot.com apt-get moo 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
Re: Boot-time improvements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Jones wrote on 11/09/08 23:05: > > I'm not quite sure what all the ranting is all about regarding Ubuntu > boot times. I never really even thought of it until it was mentioned on > the mailing list here. So, as a test, I timed my own system how long it > takes to boot. From GRUB boot to login screen, it was 36.72 secs. And > that is on a Celeron D with 512MB DDR RAM and booting from an old IDE > hard drive. I'd imagine that a more recent dual core setup with more > ram and a more recent sata hard drive would have better results. But my > mere 36 secs is certainly nothing to rant about. > > I dunno what you are all complaining about really. >... That's the power of low expectations. Before the 1970s, people were used to radios taking half a minute to start up. Before the 1990s, people were used to televisions taking half a minute to start up. As long as computers take more than a couple of seconds to start up, there's work left to do. Cheers - -- Matthew Paul Thomas http://mpt.net.nz/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIyngL6PUxNfU6ecoRAon7AJ92bdJF0Lx+FSYP8EonowrgPerS9QCggUvc BHetXsyRTRXx08i4vKrBH5A= =4djb -END PGP SIGNATURE- -- 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: Boot-time improvements
On Fri, 2008-09-12 at 08:05 +1000, Chris Jones wrote: > takes to boot. From GRUB boot to login screen, it was 36.72 secs. And > that is on a Celeron D with 512MB DDR RAM and booting from an old IDE > hard drive. I'd imagine that a more recent dual core setup with more ram > and a more recent sata hard drive would have better results. But my mere In my case, no. My boot time is 38 seconds (Intrepid) and then another 26 seconds after logging in from GDM. My system is a LOT faster than yours, P4 Core 2 Duo 2,2GHz, 2GB RAM and a 3 month old 750GB harddrive. In sessions I have disabled bluetooth, check for new hardware, evo alarm notifier, tracker but added parcellite. That's something to rant about IMO.. Rgds -- Thomas Novin <[EMAIL PROTECTED]> GPG key: http://xyz.pp.se/~thnov/gpg.asc -- 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: Boot-time improvements
On Fri, Sep 12, 2008 at 03:09:15PM +0100, Matthew Paul Thomas wrote: > That's the power of low expectations. Before the 1970s, people were used > to radios taking half a minute to start up. Before the 1990s, people > were used to televisions taking half a minute to start up. > > As long as computers take more than a couple of seconds to start up, > there's work left to do. Hear, hear! Marius Gedminas -- BASIC: A programming language. Related to certain social diseases in that those who have it will not admit it in polite company. signature.asc Description: Digital signature -- 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: Wiki lost forms (was Foundations team meeting minutes, 2008-09-10)
On Fri, Sep 12, 2008 at 12:00:39AM +0100, (``-_-) -- Fernando wrote: > Ol?? Colin e a todos. > > On Thursday 11 September 2008 14:23:36 Colin Watson wrote: > > * lose two hours of work to the wiki deciding not to accept my new page, > > my browser not saving my form contents, and me not thinking to save the > > content somewhere else before hitting 'Save Changes' > Sympathies; that happened to me once. Then I switched to using gedit for composing the minutes and pasting into the wiki after. Bryce -- 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
Configuration Validation
Dear Ubuntu and APT Developers, I would like to introduce an idea and see if any of you would like to review it and see how helpful it would be to solving a problem. These ideas may have already have been expressed so I'd like to see if they are under development elsewhere. In Debian based distros like Ubuntu we have pretty tight control over lots of files. The guidelines for getting something appropriately packaged for the repositories are set up as best practice guidelines for the kinds of support in our projects that make them easier to install, use and modify. One of the concerns I have is with configurations, specifically those in /etc and those in ~/.* . The files in /etc are known to the apt system and it's been built to warn the user if config files are to be overwritten. The config files in ~/.* are not recorded anywhere and they are at the mercy of the competency of the developers in format and version control. I'm not aware of any guidelines for these files. To solve some of the problems with this set-up I had a ponder. A solution that came to mind was to have a validation system which involves two steps (below). This system would be employed to check the integrity of the system at any time, and the integrity of certain package configurations during upgrade time. In essence, just as we recommend each executable come with a man page, we should recommend each configuration file come with a definition and validation xsd. Checking the entire system would be a matter of going through each definition, checking the existence of the config file followed by step one, which would be a translation of the config file from what ever text format it is in to an xml structure using standard transformation methods for various formats, these can be made as plugins for which the definitions would identify in order for translation backwards and forwards to take place. Step two is to use an xsd appropriate for each config file to check the validity of the config against the version of the application installed it is applicable to. An optional step three on upgrade time is to use xslt translation to upgrade configurations assuming no validity or conflict errors. This would allow for much safer upgrading. Now once employed this system would not only be applicable to config files in /etc but also to configurations employed per user in ~/ these checks can be carried out at any time and especially if there is problems with logging in (as I have seen with gnome). I imagine the locations for each xsd, xslt and config definition file would be set locations much like the man pages and could be if successful in future revisions integrated into the way apt/deb works. I propose python as a language of choice to build such a system. I assume much of these ideas to have been discussed at length before, but my searches aren't picking up useful results. Best Regards, Martin Owens -- 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: Configuration Validation
Could you spell out some specific issues that this would solve? For example, are you looking to avoid two packages overwriting each other's files in ~/? If so, can you give an example of that happening? - Andrew -- 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: Configuration Validation
2008/9/12 Andrew Sayers <[EMAIL PROTECTED]>: > Could you spell out some specific issues that this would solve? For > example, are you looking to avoid two packages overwriting each other's > files in ~/? If so, can you give an example of that happening? > Examples: 1) I manually edit a config file in /etc which is read during startup to do something interesting. There is no standard way of checking to see if the config I've written in valid in format other than seeing if my computer will still boot or see if there is a specific validation utility to check for me. 2) I upgrade gnome, the .gnome2/backgrounds.xml file changes in format between the two versions. the xslt and validators are able to upgrade the config files without removing settings and my backgrounds. 3) I install an application which uses the same settings file, but their xsd validation files don't match, enabling packages to be marked as conflicting protecting corruption. 4) I would be able to use a utility which employs the translation software to edit any xml or oddly formatted config file in vi/emacs/nano/gedit in a manner that suits my tastes without causing errors or problems, say I hate editing ini files but like editing xml files. Regards, Martin -- 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
Configuration masquerading Data
Dear Ubuntu and Evolution Developers, I'm sending this email to the gnome evolution hackers list to see what their thoughts are. I have noticed a really odd disconnect in gnu/linux with user data which has me a little worried. Some user data is hidden from users in configuration directories. Technically configuration directories denoted by being hidden (suffexed with a '.') are there to hold collections of configuration files for the applications which they serve. But there are plenty of programs using these directories to store the data results as well as configuration. For consideration I present Cheese, a very nice tool for using web-cams to take photos with weird disfiguring effects. The problem as I see it is that Cheese stores each of the photos in it's ~/.cheese directory which makes them hidden from the user. Instead I propose that Cheese use a standard directory (possibly configurable) such as ~/Photographs/Cheese or ~/Documents/Cheese which is accessible to user browsing. Cheese is an excellent example of making user data more accessible to casual file browsing which is not just limited to jpeg images but could just as easily apply to the way Evolution stores emails, addresses, contacts and so on. In these instances the data is always bound up in evolution specific formats inaccessible to casual browsing as well as casual integration (without delving into the EDS API) I'd like data to be available to send in an email, or browse in nautilus (or on a command line) I'd like to be able to open the same jpeg in image viewer and gimp, not just in what ever created or generated them. I'd like to be able to open addresses and copy an event file to my thumb drive. Wouldn't it be good to backup all your files without configs and be sure your not missing emails or bookmarks? In fact the methods we use to store data seems to be along the same lines that certain Windows and Mac programs use to obfuscate and hide data in order to lock users into their products. Do we really need to do this on our gnu/linux systems? Should we instead intend user data to be converted with plugins and export features in every application because of their hidden default outputs? This issue may be interesting to the FDO (freedesktop.org) crowd. It is a very heavy topic that will probably get me a little flaming because it goes against what is currently best practice. Best Regards, Martin Owens -- 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: Configuration Validation
I think we've all had that idea at one time or another, but sadly it's based on a misunderstanding of how the community works. Steve Jobs stood atop the mountain and commanded that Mac developers jump to plists, and everyone jumped because that's how Apple development works. If Mark Shuttleworth stood atop the mountain and commanded Linux devs do the same, people would listen politely then carry on as before. Linux developers are very individualistic in that way, which has benefits and drawbacks. You've identified some of the drawbacks, and I should imagine others will reply stating some benefits soon enough :) Projects like GConf tackle this issue in a more Linuxy way: write a tool, then convince people that they'll get more value for less effort by using it. If you're really motivated to work on this problem, I suggest you talk to them about what you can do to help out. - Andrew -- 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: Configuration Validation
> I think we've all had that idea at one time or another, but sadly it's > based on a misunderstanding of how the community works. Oh no, I understand that people will be people. I don't expect them to agree. But building systems to validate system integrity doesn't require projects approval directly. Some of this is a distribution/packaging problem and some of it is a system integrity problem. Having a community which then realises the usefulness of new mechanisms to their projects just aims to decrees the burden of work from the packagers and shift it to the projects where it is most efficient. > Projects like GConf tackle this issue in a more Linuxy way: write a > tool, then convince people that they'll get more value for less effort > by using it. If you're really motivated to work on this problem, I > suggest you talk to them about what you can do to help out. Ah the gconf approach, this project suffers from not being able to include existing config files, it excludes people from directly editing text files which has always been a big complaint. And it's a copy of a bad idea from windows (even with a gtk-regedit) with a few of the ideas fixed with regards to user data. Although at least they do have validation, if not the packaging integration. It's not hard to Imagen a sort of fuse-fs solution to bridge the gap and ties into deb/apt although it may not work with what their currently doing. As for your 'go away and come back with the goods' suggestion, I'll take it under advisement while I try and pick holes in the idea first. I'm only interested in building something once I understand everyone's objectives and points of view on the subject. Design the blueprints first then go build the building. I'll be talking more about this at UDS in December if you want to join the session. Best Regards, Martin Owens -- 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: Configuration Validation
On Fri, 2008-09-12 at 23:18 -0400, Martin Owens wrote: > One of the concerns I have is with configurations, specifically those > in /etc and those in ~/.* . The files in /etc are known to the apt > system and it's been built to warn the user if config files are to be > overwritten. The config files in ~/.* are not recorded anywhere and > they are at the mercy of the competency of the developers in format > and version control. I'm not aware of any guidelines for these files. Daniel Chen says to look at extending ucf for checking config file changes during installs. He also says look at the validators for sudoers(5) and ssh_config(5)/sshd_config(5). -- Mackenzie Morgan http://ubuntulinuxtipstricks.blogspot.com apt-get moo 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
Re: Configuration Validation
I like the idea of a FUSE interface to GConf, and I could see extending the idea to some sort of configFS - I seem to remember the ReiserFS guys talking about a similar idea years ago, before recent events overtook them. I think an interface that involves opening ~/.configfs/myproject/version1/number_of_frobnitzem would be very attractive to developers of small projects, eager to avoid the pain of maintaining a parser. It also has the advantage of degrading gracefully - if configFS isn't installed, it just creates a directory hierarchy to store a program's data. A FUSE-based solution for small projects strikes me as the most effective use of time in the short-term, because you can get some actual evidence about the problem domain as you build the program. Volunteering to convert sendmail.cf to XML isn't something you want to do right away :) - Andrew -- 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
