Re: RFC: Btrfs snapshots feature for F13
Hi David, Shouldn't it say next time volume is mounted instead of next boot? We can always special case rootfs to say next boot of course (since rootfs can't be unmounted until next boot). Good point. That's fine. Also, what is the mechanism to configure this? Just a simple command from btrfs-progs (best)? Or does it require surgery to /etc/fstab and/or the initramfs (bad)? Josef's been thinking about exactly that -- the current situation requires you to add subvol=snapshot-name to the mount args, which indeed would require you to change fstab (for non-rootfs) or to add a rootflags= argument to the grub menu (for rootfs). He's considering changing the btrfs disk format to add a default subvolume for this fs field that would lead us to a simple btrfsctl command for setting that field instead. I agree that his solution's what we'd like. OK. We need to decide how all this is going to work - maybe some of it will go into GIO and be part of an abstraction that also works for other filesystems, maybe it will be a Nautilus-only feature. I don't know yet, leaning towards the latter right now, but I guess we'll find out. Makes sense. Thanks again. I've updated the feature draft to include the Palimpsest UI suggestion. - Chris. -- Chris Ball c...@laptop.org One Laptop Per Child -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Btrfs snapshots feature for F13
Hi all, It'd be great to get feedback on whether this is the right idea, and how exactly the UI interaction should work, before submitting this formally. Some off-list feedback so far: * People want independent active snapshots per filesystem (i.e. btrfs /home is the live filesystem, and btrfs / is an older snapshot), which makes sense but makes the UI more complex since it'll have to show a list of (filesystem, snapshot) tuples. * Ray says not to invent a new system-config-blah, and instead to talk with davidz about Palimpsest. David, what do you think? * Several people think that the ZFS Time Slider patches to nautilus¹ look good, and want that for btrfs. Sounds plausible², but I'm personally less interested in file versioning via snapshots and more interested in working on ways to let developers feel comfortable upgrading to Rawhide daily, for the next release. * Someone on the feature's Talk Page suggests that we should encourage people using anaconda to create a btrfs rootfs separate to their /home, so that they can rollback rootfs snapshots without affecting their homedir. Could work; maybe an anaconda dialog that says hey, I see you're choosing btrfs, we're going to turn on snapshots and we suggest you use a separate /home partition. Any more thoughts? Thanks! - Chris. ¹: http://blogs.sun.com/erwann/entry/zfs_on_the_desktop_zfs http://blogs.sun.com/erwann/entry/time_slider_screencast http://blogs.sun.com/erwann/entry/new_time_slider_features_in ²: It's a bit awkward; you have to do a mount on each snapshot to be able to show the directory listing for it, but it appears that's what ZFS/Time Slider does already, so it won't be any worse.. -- Chris Ball c...@laptop.org One Laptop Per Child -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Btrfs snapshots feature for F13
Hi, This implies that all you have is a hammer but you can already run yum history undo. which works up to a point. If the older pkgs you had prior to an update are not available anywhere history undo isn't going to be able to 'undo' but so much. And of course, it's not going to work if Rawhide's broken something anywhere in the yum/rpm/*kit/etc stack, or if prelink's hosed every binary on your system again, or so on. But this would. - Chris. -- Chris Ball c...@laptop.org One Laptop Per Child -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Btrfs snapshots feature for F13
Hi, I'm not sure how much of this can/should be automated. Sorry, not quite following -- what is the caution around automatically creating a new snapshot before each yum transaction? Why shouldn't it be automated? This also keeps us out of the dangerous territory that comes with using non-ubiquitous FS features (your boot is on ext3, your root is on btrfs, your etc is on xfs and your usr is on jfs. What do you snapshot and how?) This feature would snapshot the btrfs / only, but that doesn't matter, because snapshots don't do anything until the user chooses to initiate a rollback. The user who chooses a btrfs / and a jfs /usr knows what happens when they rollback only the btrfs filesystem. (And we can print a warning to make sure of that if we decide it's necessary.) Thanks, - Chris. -- Chris Ball c...@laptop.org One Laptop Per Child -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Btrfs snapshots feature for F13
Hi, We've now created a useless and slightly dangerous object though. Regardless of the competence of the user who's problem that is, better to avoid it if we can. Okay. Perhaps the automated snapshot creation algorithm should be amended to something like: check /proc/mounts for at least one btrfs, and zero other non-btrfs filesystems, except for /boot which can be anything. Thanks, - Chris. -- Chris Ball c...@laptop.org One Laptop Per Child -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Btrfs snapshots feature for F13
Hi, I somewhat read the initial suggestion as trying to implement transactional behavior via snapshot. Just creating one shouldn't hurt. Ah. Yeah, not at all. I fail to understand how a snapshot would differentiate between yum related changes and other changes that occur by an otherwise normally operating daemon (logs for example). If someone wanted to use whole-fs snapshots for yum transactions (which I don't) the way to do it would be to only rollback changes made to files that are present in either of the RPM manifests. - Chris. -- Chris Ball c...@laptop.org One Laptop Per Child -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Xorg and multitouch
Hi, Multitouch means, several mousepointers and you can move them all seperately. No, that's what multi-pointer means. Multi-Pointer X is already in F12. Gesture support is, you make a certain sign with a mousepointer, and a certain action is triggered. Would be cool to see both together. I mean, several independent mousepointers, with each you can make a different gesture and different actions are triggered. ^^ I'm sure you can achieve this gesture support today, again using MPX in F12. Multitouch refers to technologies that involve extrapolating from motion of finger-shaped blobs on your input device to the idea that a user has performed some continuous motion with said finger(s), and reacting appropriately. It's not the same as multi-pointer X, but it does use the same core technology. - Chris. -- Chris Ball c...@laptop.org One Laptop Per Child -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Btrfs snapshots feature for F13
Hi David, thanks for the reply. Yep, we're planning to add support to DeviceKit-disks for exposing the (privileged) operations that btrfs may expose (locked down by polkit, etc etc). There are also plans to expose these operations in the UI in Palimpsest and/or Nautilus. I don't think snapshots is going to have any Palimpsest UI (it belongs in Nautilus I think) but the multi-disk stuff definitely will. I don't think it makes sense for the filesystem-level snapshot operations I describe in the feature proposal to be in Nautilus: https://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs The proposal is about system-administrator decisions on what your root directory on btrfs will look like at next boot; they should only be performed by someone deep into I am modifying the mount behavior of my fs mode. (It does make sense for a Time Slider port to Btrfs, working with file-level operations on snapshots, to live inside Nautilus. That's not part of this proposal, but would be very useful work.) Given the above, do you think you'd be okay with having: Filesystem snapshot that will be active on next boot: drop-down and Create new whole-filesystem snapshot now: label apply in a Btrfs-specific section in Palimpsest? That's all that's needed for the UI component of this feature. As always, DKD and Palimpsest is supposed to be complementary to the command-line tools. So all this is only relevant for creating nice UIs for managing btrfs. Yup, that's the case. (Oh, and if it turns out that creating/destroying btrfs snaphots isn't a privileged operation (I can't remember at this point) it would probably make sense for Nautilus to just use the btrfs tools directly instead of going through a system daemon. There's just no need to overcomplicate things.) Creating a new snapshot is unprivileged, but mounting an old one (which nautilus would need to do in order to show you the contents of a previous snapshot, so that you can decide which files you want to restore from it) requires a mount(8) call for each snapshot. Thanks, - Chris. -- Chris Ball c...@laptop.org One Laptop Per Child -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
RFC: Btrfs snapshots feature for F13
Hi, I've written up a draft of an F13 filesystem rollback feature using Btrfs snapshots that are automatically created by yum: https://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs It'd be great to get feedback on whether this is the right idea, and how exactly the UI interaction should work, before submitting this formally. Thanks! - Chris. -- Chris Ball c...@laptop.org One Laptop Per Child -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: an update to automake-1.11?
Hi, And you'll be violating the GPL (unless you're talking about a BSD-style-licensed software or configure.ac is explicitly marked with special permissions). The GPL requires you to edit the preferred form for modification, which is definitely NOT a generated file. [citation needed] I think this clause talks about *my* preferred form for modification, not yours -- it's saying that I have to distribute my changes in the form I created them in. If you write a program in Perl, and I port it to Python and release it, I haven't violated the preferred form for modification by not using Perl. - Chris. -- Chris Ball c...@laptop.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCo meeting summary for 2009-06-26
Hi Kevin, It was because you (plural) didn't want to listen to my arguments, you were just eager to shoot my proposal down no matter what. I think this is your 60th post to this thread, in the four days that it's been going. I don't have anything to say about the thread itself, but I'd encourage you to take a break from the thread and consider what else you think it's important to add to it. This is just advice, naturally; I'm interested in ways that we can use this list more constructively. - Chris. -- Chris Ball c...@laptop.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12 (#2)
Hi, The revised proposal: - Build all packages for i686 (this requires cmov) - Optimize for Atom This sounds good to me/OLPC. Thanks! - Chris. -- Chris Ball c...@laptop.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12 (#2)
Hi, On Wed, Jun 17, 2009 at 01:52:26PM -0400, Bill Nottingham wrote: - Build all packages for i686 (this requires cmov) This cuts out AMD Geode ... That's not true; Geode has cmov, and should be compatible with gcc's i686. - Chris. -- Chris Ball c...@laptop.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12
Hi, - AMD Geode I'm a little worried about this one. Although AMD stopped making the processors at the end of 2008, they were sort of popular for certain super-cheap, small (for want of a better description) Mac Mini clones that have been selling well in the UK. Like this one: Well, if we're going to consider marketshare, I'd expect the million or so Geodes already running Fedora (on the XO-1) to count for quite a bit more than some Mac Mini clones that someone might run Fedora on someday. :) To be clear about the XO-1, it's generally 686-compatible, so it's the SSE2 requirement that's a problem here. (I think we've seen a problem with liboil getting SIGILL when compiled for i686 on the XO-1, but it's much easier to contemplate recompiling one package as i586 than to make a whole new distribution as non-SSE2.) - Chris. -- Chris Ball c...@laptop.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [Phoronix] Ubuntu 9.04 vs. Fedora 11 Performance
Hi, Our Apache results on the Phoronix tests, AIUI, are from an Apache they compiled, which is not what most people are going to use. Do similar results occur when you compare the installed Apaches instead, or does the discrepancy go away? There's also no mention of whether they mitigated the way results would have changed from our use of SELinux. Why would you want to mitigate that, in a comparison of distributions out-of-the-box? (And, what would mitigate mean here?) Just another couple of gripes here, but I do agree with a previous poster that a well-thought out series of benchmarks and an explanation of their meaning would be far preferable to what Phoronix publishes. I guess I feel pretty consequentialist about this -- if the discrepancy they measured doesn't actually exist in a form that our users might hit, then they were wrong to post a badly-designed benchmark. If it does exist, on the other hand, they've done us a large favour by pointing out something we didn't know about (which might even be a large regression from F10), and I'd feel that we should (a) thank them and encourage them to run benchmarks more often, (b) fix our bug, and (c) tell them how to improve their benchmarks, with patches, so that it doesn't take so long to work out whether there's a real problem next time. The question is, which is it? - Chris. -- Chris Ball c...@laptop.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
