Re: RFE: Never, ever steal focus.
On Wed, Jan 06, 2010 at 01:27:07PM -0500, Fulko Hew wrote: I'd say... only take focus if its a child/creation of the window currently in focus. You don't want ssh passphrase windows to take focus? -- Matthew Garrett | mj...@srcf.ucam.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCo election results December 2009
On Fri, Dec 18, 2009 at 12:19:47PM -0500, Paul W. Frields wrote: Using the Fedora Range Voting method, each candidate could attain a maximum of 864 votes (4*216). Results: 1. Adam Jackson (ajax) 1028 I think there's a discrepency here :) -- Matthew Garrett | mj...@srcf.ucam.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Wed, Dec 16, 2009 at 12:30:11AM +, Paul Jakma wrote: On Tue, 15 Dec 2009, Matthew Garrett wrote: And the remaining 0.1% of the work is probably the other 99.9% of the time. I think you massively underestimate the number of corner cases present in an utterly untested configuration. My data-point is that I ran an x86-64 kernel on i386 F10 for a few months until I got tired of yum not being able to update kernel packages. The kernel side apparently works fine AFAICT. The .1% is yum. It works for me is a poor standard of support. -- Matthew Garrett | mj...@srcf.ucam.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Wed, Dec 16, 2009 at 06:29:17PM +, Paul Jakma wrote: On Wed, 16 Dec 2009, Matthew Garrett wrote: It works for me is a poor standard of support. There must be something transmogrifying my emails before it reaches other subscribers of this list, either that or I am being unreasonable in thinking that by asking /if/ Fedora would consider *supporting* this configuration (i.e. in the future) that it would be clear that: - I am not complaining about software not working quite right now The problem here is that you appear to be massively underestimating the amount of work that would be required to actually support this configuration. We'd need to audit every ioctl entry point, every file in proc and every sysfs attribute. We'd need to port every application that uses vm86 over to using x86emu. We'd need to add, test and support a 32-to-64 bit cross building toolchain. yum would need some amount of work that Seth has implied is significant. That's a lot of work for marginal benefits, and nobody seems interested in stepping up to do that work. -- Matthew Garrett | mj...@srcf.ucam.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Tue, Dec 15, 2009 at 09:28:10PM +, Paul Jakma wrote: And again, far from being some incredibly difficult thing that I'm asking for, the support is pretty much 99.9% there.. And the remaining 0.1% of the work is probably the other 99.9% of the time. I think you massively underestimate the number of corner cases present in an utterly untested configuration. -- Matthew Garrett | mj...@srcf.ucam.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Mon, Dec 14, 2009 at 05:18:47PM +, Paul Jakma wrote: For those who can't sort by thread in their MUA: To ask that 32-userspace-on-64 be supported (it pretty much all works, except for yum updating certain things, like the kernel), as there are definite benefits to a 32-by-default userspace. There's little testing effort done on this. People still occasionally trip over bugs in the ioctl conversion code in the kernel, and there's a couple of other cases where exported ABI doesn't get converted correctly. Now, while it's undeniable that these are bugs that should be fixed, it's also pretty difficult to justify adding a third x86 variant to our list of supported configurations, especially when it's known to be more problematic than the other two that already satisfy almost everybody's needs. -- Matthew Garrett | mj...@srcf.ucam.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Promoting i386 version over x86_64?
On Wed, Dec 09, 2009 at 03:00:51PM +0100, Dominik 'Rathann' Mierzejewski wrote: Actually, x86_64 is an AMD invention (originally called AMD64) and is called EM64T by Intel. The only Intel 64 I can think of is IA64, i.e. Itanium (called Itanic by some). http://www.intel.com/technology/intel64/ We have always been at war with Itanium, -- Matthew Garrett | mj...@srcf.ucam.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Who handles lidclose at login screen?
On Mon, Nov 23, 2009 at 12:44:08PM -0700, Orion Poplawski wrote: On 11/23/2009 12:43 PM, Matthew Garrett wrote: In principle, whatever handles it in your session. gnome-power-manager runs as part of the gdm session, so the KDE equivalent should be running under kdm. There is no session - I'm at the login screen. The login screen is a session, just not a user one. -- Matthew Garrett | mj...@srcf.ucam.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit policy: background and plans
On Fri, Nov 20, 2009 at 04:09:15PM +1100, James Morris wrote: Many users limit their use of the root account to essential system maintenance, and run general purpose applications as a regular unprivileged user. I know basically nobody who, on a generally single user system, explicitly switches to a console to log in as root and perform package installs there. If you're not doing that then the issue is basically moot - a user-level compromise will become a root-level compromise the next time you run anything as root. - The local session has a new means to execute in a high privilege context, i.e. that which is required to install the system itself. This is a problem alone -- everything which runs in this context is now a prime attack target. I don't think I'd agree with that. The common case for F10 and F11 will be for people to have installed a package once with the root password and then ticked the Remember authentication box. At that point, we have the same security exposure as we do with F12 (again, concentrating on the single-user machine case). I definitely agree that there's a whole range of cases where this isn't the behaviour you want. But for the vast majority of our users, I don't think there's a real security issue here. -- Matthew Garrett | mj...@srcf.ucam.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit policy: background and plans
On Fri, Nov 20, 2009 at 09:38:43AM -0500, Fulko Hew wrote: I do! And I tell everyone else too, so they learn/understand the difference between 'god' and a 'mere mortal user' (ie. root and anyone else). Actually, thinking about it, even this isn't sufficient. An attacker could change the ctrl+alt+F* bindings and use them to pop up a full-screen window that looks like the console. So you'd also need to set up securetty to ensure that root can only log in on real consoles. I really don't see this being a security issue in the common single-user case. -- Matthew Garrett | mj...@srcf.ucam.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Wi-Fi Question
On Tue, Oct 27, 2009 at 08:03:54PM +0100, Ola Thoresen wrote: Nice app. Thanks for the tip. But does anyone have any idea about how to disable the hardware kill switch, when linux insists it is enabled no matter what position the switch is really set to: What hardware is this? -- Matthew Garrett | mj...@srcf.ucam.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Wi-Fi Question
On Tue, Oct 27, 2009 at 10:40:30PM +0100, Ola Thoresen wrote: On 27. okt. 2009 21:10, Matthew Garrett wrote: What hardware is this? 02:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02) (And it is the physical switch I am turning on and off) What's it plugged into? -- Matthew Garrett | mj...@srcf.ucam.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [PATCH 3/3] dracut has initrd-generic-version instead of initrd-version (#519185)
On Tue, Sep 08, 2009 at 12:45:43PM -0400, Warren Togami wrote: On 09/04/2009 12:51 PM, Matthew Garrett wrote: Isn't the point of the new infrastructure that we can provide multiple initramfs modules that will all end up in the filesystem on boot? Users who want to add drivers could do it even more easily than they currently can. I am skeptical that we are ready for this. Not all non-x86 boot loaders are capable of handling multiple initrd's, and various types of netboot wont do it either. This is a very late time to rely upon such a new feature for something this important. cpio archives can be concatenated, right? It seems like a straightforward workaround. -- Matthew Garrett | mj...@srcf.ucam.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [PATCH 3/3] dracut has initrd-generic-version instead of initrd-version (#519185)
On Fri, Sep 04, 2009 at 10:53:19AM -0400, Jon Masters wrote: The problem I have is that some folks want to include additional drivers into their initrd. What are we going to recommend for this case? I know one can still build a kernel-specific version, but I fear that this results in many users having no benefit of the generic image because it'll not contain the additional bits they needed to add. Isn't the point of the new infrastructure that we can provide multiple initramfs modules that will all end up in the filesystem on boot? Users who want to add drivers could do it even more easily than they currently can. -- Matthew Garrett | mj...@srcf.ucam.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Minitube - youtube for your desktop, still a little early in development
On Thu, Sep 03, 2009 at 08:38:49AM -0500, Adam Miller wrote: Hey all, I packaged up this app I stumbled upon called minitube (http://flavio.tordini.org/minitube) but it seems a bit unstable and I don't really want to toss it up to a package review until its stable enough to be shipped but I wanted to mention it to see if anyone might find a use for it, would help testing and submitting bugs upstream, etc. Does it have any functionality that the totem youtube plugin doesn't? -- Matthew Garrett | mj...@srcf.ucam.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [ANNOUNCE] New Mixer Handling in PA 0.9.16/F12
On Sat, Aug 01, 2009 at 01:01:44AM -0500, Doug Ledford wrote: It's also things like erratic output via PA versus smooth output via analog input. This particular laptop pops and crackles every time the PCM starts/stops, while analog signals are much cleaner. There's a patch in the rawhide kernel that may improve this, depending on your codec. You can also disable HDA power saving. And it would be pretty easy to have a warn once dialog that tells users that attempt to adjust the CD in volume that it may not have any effect if the analog input isn't connected to the sound card or if the cd playback software skips the analog input in favor of digital data transfer. You could even ask users after an adjustment if the adjustment made any difference, and if it didn't, you could remove it from the UI. We have a solution that we know always works, and it has negligable cost. That's a much more straightforward design than one that has to attempt to explain to the user that depending on whether or not there's a specific piece of wire in their computer they may or may not hear something in the CD player. -- Matthew Garrett | mj...@srcf.ucam.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [ANNOUNCE] New Mixer Handling in PA 0.9.16/F12
On Sat, Aug 01, 2009 at 08:16:50AM -0500, Doug Ledford wrote: CD in is nothing more than an analog input. PA ignores all the analog inputs other than as a digital PCM source. Treating all the analog inputs as digital sources and not allowing the hardware to mix them to output has various drawbacks. I've just been covering some of them. You're continuing to conflate two issues - hardware mixing of multiple PCM streams (which some hardware supports but PA doesn't make use of) and having control over the levels of analog inputs that are mixed straight into the analog output stream. PA exposes some of these, but not all of them - however, you can still use an alternative mixer app if you want to configure this for your specific niche use case. When Lennart says PulseAudio does not support hardware mixing he is *not* talking about the case you're describing. -- Matthew Garrett | mj...@srcf.ucam.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [ANNOUNCE] New Mixer Handling in PA 0.9.16/F12
On Sat, Aug 01, 2009 at 12:29:36AM -0500, Doug Ledford wrote: That reading in the data digitally uses non trivial amounts of PCI and CPU bandwidth. If I can't hear the difference between the two modes, then that CPU usage is a total waste of resources. I have other things I want my CPU to be doing. If 150K/sec is non-trivial PCI bandwidth, I think you should probably ask for a refund on your motherboard. From a power management point of view I'd like to agree that offloading this from the CPU is a good thing, but Lennart's right - most newly built machines don't hook these up, and adding a control that influences CD volume on a small number of machines and does nothing whatsoever on a larger number isn't a sensible UI optimisation. -- Matthew Garrett | mj...@srcf.ucam.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [ANNOUNCE] New Mixer Handling in PA 0.9.16/F12
On Thu, Jul 30, 2009 at 10:41:34AM -0400, Doug Ledford wrote: Not hardware up mix/down mixing, but hardware mixing. And as my other post points out, I make use of it and have no intent of ever not using it. Right now I simply use gst-mixer to enable the mixing behind PA's back. I consider the fact that PA can't/won't do it to be a serious design flaw. The discussion in question was on whether or not PA would support using hardware functionality to mix multiple PCM streams. Your situation seems to be orthogonal to that. Conflating them isn't helpful. -- Matthew Garrett | mj...@srcf.ucam.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates and delays in signing packages
On Sat, Jul 18, 2009 at 05:02:15AM +0530, Rahul Sundaram wrote: Yes, there has been critical bugs. Crashes within a number of releases and atleast one potential data loss issue. I really do mean that I have a need to update often. If software is that unstable then I think it's reasonable to ask whether it's ready to be shipped in a stable distribution release. -- Matthew Garrett | mj...@srcf.ucam.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates and delays in signing packages
On Sat, Jul 18, 2009 at 06:45:21AM +0530, Rahul Sundaram wrote: On 07/18/2009 06:30 AM, Matthew Garrett wrote: If software is that unstable then I think it's reasonable to ask whether it's ready to be shipped in a stable distribution release. I think it is. It is not crashing and burning for all the users using it including me all the time. Let's take the latest bug report I have received https://bugzilla.redhat.com/show_bug.cgi?id=511053 It requires you to access the help in a particular way to get it to crash but I consider a crash a problem that needs to be fixed quickly. If it's not a common pathway then I don't think it's urgent - certainly not urgent enough that waiting an extra week is a big problem. This doesn't make it in unstable enough to be excluded compared to rest of what we have been included by default in the past and Gnote is not the default in any stable release. Anyway, you are sort of missing the point by focusing on the example given without understanding that for a certain class of software (new project where upstream is active, user demand new features etc) with frequent updates, the current system isn't working out well. I doubt I am the only maintainer with this problem. I Most of our users wait 6 months between releases. If they can wait that long to get a new piece of software in the first place, the difference between an upload a week and an upload every two weeks shouldn't be much of an issue. I just really don't see how feature requests can be that high a priority during a stable release. -- Matthew Garrett | mj...@srcf.ucam.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
ASPM enabled by default - mild potential for breakage
I've just flicked ASPM (Active State Power Management - runtime power saving on PCIe hardware) on by default, and it'll be that way in the next rawhide kernel build. There's the potential for some buggy hardware to be upset by this. If your system no longer boots or some hardware doesn't work, try booting with the pcie_aspm=off argument. If that fixes things please file a bug against the kernel and assign it to me (m...@redhat.com). Include dmesg and the output of lspci -n. There's some reasonable heuristics in the kernel to detect supported hardware, so I'm hoping that people shouldn't see any adverse affects. -- Matthew Garrett | mj...@srcf.ucam.org ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: $HOME/bin
On Mon, Jul 13, 2009 at 03:54:51PM +0200, Enrico Scholz wrote: $ echo $PATH /home/ensc/bin:/usr/lib64/qt-3.3/bin:/usr/kerberos/bin:/usr/lib64/ccache:/usr/local/bin:/usr/bin:/bin:/usr/games press alt-shift-f2 - starts the xfrun4 Run program application) $ ps wwwe `/sbin/pidof xfrun4` 4220 ?Ss 0:00 /usr/bin/xfrun4 --daemon ... PATH=/usr/local/bin:/usr/bin:/bin:/usr/games .bash_profile is only evaluated for login shells. It's probably some kind of undebuggable d-bus interaction :( Hence, use xterm to start your applications, but not this buggy desktop crap. It seems to be working as expected, given the implementation. Please don't blame parts of the software stack just because you don't understand them - it doesn't provide much incentive to improve things. -- Matthew Garrett | mj...@srcf.ucam.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: $HOME/bin
On Mon, Jul 13, 2009 at 10:48:35PM +0100, Richard W.M. Jones wrote: The same application could overwrite .bash_profile too. Or it would be very contrived to imagine a security hole that lets you create ~/bin and place an arbitrary binary into ~/bin/bash, but doesn't let you overwrite .bash_profile. So I don't think this is a security concern at all in the real world. Realistically, the concern is more likely to be binaries accidently causing subtle breakage by colliding with the expected behaviour of system utilities. -- Matthew Garrett | mj...@srcf.ucam.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Kernel changes that may affect desktops
On Wed, Jul 01, 2009 at 12:31:20AM +0200, Kevin Kofler wrote: IMHO DeviceKit should just unmount it itself and notify the desktop that it has unmounted the device so the desktop can report it (or ignore it if it doesn't know about the event). I don't see why we need to add code to every desktop to listen for a please unmount me event and send an unmount request back when this could just be handled within DeviceKit. Or even within the kernel for that matter, do we really need a roundtrip through userspace for this? When and why would we ever want to do anything *other* than unmounting the device when this event triggers? Because you might want to warn the user that they have unsaved work that will be lost if they continue? An additional problem is: what if the unmount fails due to open files? Your suggestion to just kill the applications sounds really broken to me. A forced unmount at kernel level and failing any attempts to further access that file just like what happens when an NFS mount goes offline sounds like a better solution to me. There are alternatives, like revoking the filehandles or prompting the user to close the application themselves. This is the same problem faced when unmounting any device. -- Matthew Garrett | mj...@srcf.ucam.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Kernel changes that may affect desktops
On Tue, Jun 30, 2009 at 09:01:45PM -0400, Ben Boeckel wrote: Isn't there Save As... for saving it? If not, I smell a bug report. When I'm working over sshfs and the network goes down, my editor still works with the file, the actual save is what fails. It depends on what resources you have open on the hardware. If part of your application is on the disk that's about to be disconnected, then you have problems. Umm, Windows locks files when they're opened. AFAIK, Linux doesn't enforce this. A similar problem is this: mkdir foo touch foo/bar kwrite foo/bar rm -rf foo Should kwrite be killed because rm killed the directory? No, because it still has a reference to it. Unmount works differently to remove. -- Matthew Garrett | mj...@srcf.ucam.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
On Mon, Jun 29, 2009 at 12:31:59PM -0500, Matthew Woehlke wrote: I love how the other side keeps ignoring that we have a chicken-and-egg situation here. We have two problems: 1. Fedora has trouble attracting KDE developers. 2. Fedora presents Gnome as better. Okay, it's been argued into the ground that #2 is justified by #1. The problem is, #1 is *also* justified by #2. Neither of the justifications is going to disappear until the opposing problem disappears. Refusing to do anything is just going to maintain the status-quo (vicious cycle, and all that). That's certainly an argument, though it's a harder one to make - it's not easy to show that changing #1 will result in #2 changing. However, it is easy to argue that treating KDE as equivalent to Gnome without having equivalent developer resources causes some level of cost for our users. Are the long term benefits worth it? Perhaps, but that's hard to quantify. Maybe we'd just end up reducing interest in Fedora as a whole and everyone would suffer. -- Matthew Garrett | mj...@srcf.ucam.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
On Sun, Jun 28, 2009 at 03:09:26PM +0200, Kevin Kofler wrote: Niels Haase wrote: GNOME KDE - official support from fedora (first class citizen) XFCE - spin only (second class citizen) LXDE - remix only (third class citizen) It's actually worse than that: GNOME - presented on the main download page (first class citizen) KDE - hidden behind a pointless extra link (second class citizen) The reality is that KDE *is* a second class citizen in Fedora - it doesn't get anywhere near the attention that Gnome does. If what you actually want is to change KDE's status, then that will involve attracting more developers and ensuring that they're as involved in the Fedora feature development process as the Gnome developers are. Once that's done then it's time for a discussion of how the options should be presented, but right now claiming that the two are equivalent is simply false. Changing the text on the website doesn't alter that. Fix reality before trying to fix our description of it. (And if KDE developers are failing to get involved in Fedora because of the layout of the download page, then I think there are larger problems...) -- Matthew Garrett | mj...@srcf.ucam.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
On Sun, Jun 28, 2009 at 11:35:07PM +0200, Kevin Kofler wrote: Matthew Garrett wrote: The reality is that KDE *is* a second class citizen in Fedora - it doesn't get anywhere near the attention that Gnome does. SARCASMThanks/SARCASM for insulting our (KDE SIG's) work yet again, that's SARCASMreally appreciated/SARCASM! :-/ I think the KDE SIG does a wonderful job given the resources available to them. But implying that they're able to produce the same quantity of useful work as the Fedora developers working on Gnome is either unrealistic or a direct insult to those developers. Given the same average level of competence (and assuming useful management), a larger team will produce more work in a given period of time. Where are the monthly bugfix updates of the entirety of GNOME in the stable updates? Where are the updates to minor feature releases? Oh wait, they don't exist! Yet we provide all this for KDE! We even provide a semi-official unstable repository (at kde-redhat) with the latest beta KDE backported to stable Fedora releases, again where's the equivalent service for GNOME? I think you're using the wrong metric here. and ensuring that they're as involved in the Fedora feature development process as the Gnome developers are. Most of those features are upstream GNOME features which just happen to be implemented by Fedora developers (or, in most cases more accurately, RH developers) and which are inherently or by the nature of their implementation GNOME-specific. It's simply unreasonable to expect KDE to support every single new GNOME feature at the same time as GNOME, the opposite is not true either! I work on power management. I think this is an important and worthwhile feature, and so I spend a lot of time ensuring that Fedora has bleeding-edge power management functionality that sets us apart from every other OS. This requires desktop integration. KDE does not have that level of power management integration. KDE has, in fact, a power management UI that commits almost every single power management error possible. If KDE is to be considered equivalent to Gnome, then that means we can't say Fedora has awesome power management. Instead, we're limited to saying Fedora (Gnome spin) has awesome power management. That's not a useful way to communicate what we're doing. If there are resources in the Fedora KDE SIG who are willing to help fix this, that'd be awesome. It'll involve a fair amount of upstream work, including convincing developers who have resisted this issue in the past. It's not work I'm willing to do myself. (I'll be giving a presentation on these issues at the cross desktop track at the desktop summit in a week's time. If anyone is there and interested in working on this, that'd be great) We do track features which are required for distro integration and take those seriously. I personally did a lot of the work to make these work. Some success stories: * ConsoleKit was supported in KDM right from Fedora 7 when it got introduced. I did the integration work. Excellent! * PulseAudio got enabled by default in KDE at the same time as in GNOME (Fedora 8). Rex Dieter did most of that work (it was coordinated through IRC). It involved adding a startup script to kde-settings (no longer needed in current releases because PulseAudio's startup is now handled through the standard /etc/xdg/autostart mechanism) and making aRts (Fedora 8 was KDE 3) work on top of it. Excellent! * FeatureDictionary (i.e. using hunspell throughout) was implemented for KDE in the same release which implemented it in GNOME (Fedora 9). I did the required patches (backporting the Sonnet Enchant backend to KDE 3's KSpell2, adding hunspell support to the legacy KSpell (KDE 3) / K3Spell (KDE 4)). Excellent! But this is a subset of what was added to Fedora in each of these releases, and if we're going to advertise certain important functionality as a Fedora feature then it needs to be included in the Fedora that we encourage users to use. If you want KDE to be considered on parity then either KDE needs to implement everything we define as a Fedora feature or we need to alter the fedora feature process in such a way that features are flagged for the desktops that implement them. If that's what you want, then make that argument rather than complaining about the naming. You're trying to put the cart before the horse. Once that's done then it's time for a discussion of how the options should be presented, but right now claiming that the two are equivalent is simply false. Changing the text on the website doesn't alter that. Fix reality before trying to fix our description of it. Reality doesn't need fixing, the website does. The work is being done already. I disagree, but I think that's pretty clear by now. (And if KDE developers are failing to get involved in Fedora because of the layout of the download page, then I think there are larger
Re: FESCo meeting summary for 2009-06-26
On Mon, Jun 29, 2009 at 01:54:37AM +0200, Kevin Kofler wrote: Matthew Garrett wrote: I think you're using the wrong metric here. I'm just pointing out that we're providing services the GNOME packagers aren't providing. And those are packaging-level services which I consider to be an important part of a desktop's user experience on a distro. We shouldn't forget during all this talk about features that the primary purpose of Fedora packagers is packaging, not upstream development, and we're doing a great job at that. Sure, I'd like more Fedora involvement in upstream KDE development, but upstream development is not primarily what our SIG is for. But when we talk about Fedora features, we're not talking about packaging updates. When we talk about what differentiates Fedora from other distributions, it's rarely the quality of the packaging that's the focus. People choose between distributions based on the features that they provide. If the primary focus of Fedora is to produce a compelling operating system, then upstream features and development are a significant part of making that argument to potential users. I work on power management. I think this is an important and worthwhile feature, and so I spend a lot of time ensuring that Fedora has bleeding-edge power management functionality that sets us apart from every other OS. This requires desktop integration. KDE does not have that level of power management integration. KDE has, in fact, a power management UI that commits almost every single power management error possible. If KDE is to be considered equivalent to Gnome, then that means we can't say Fedora has awesome power management. Instead, we're limited to saying Fedora (Gnome spin) has awesome power management. That's not a useful way to communicate what we're doing. Are you really sure that PowerDevil is objectively bad and this it not just a personal opinion? I don't think the people who work on PowerDevil are idiots, so they must have had some reason(s) to design the UI the way they did. And I haven't personally noticed anything obviously bad with PowerDevil. I'm sure, yes. It makes several mistakes that I've been arguing against for years (presenting power management in terms of profiles, making it easy for users to change cpu frequency governer mode without making it clear that almost anything they change there will consume more power and will probably compromise performance, implying that performance and pwoersaving are a tradeoff) and whenever I bring these issues up I'm either told that I'm wrong or that it doesn't do that. It's heavily based on how people think power management works, as opposed to how power management actually works on modern hardware. There's a lot of counterintuitive results in this field. [...] or we need to alter the fedora feature process in such a way that features are flagged for the desktops that implement them. This is obviously the right solution. Ok. This is a solid change that you can present to fesco and have discussed. It's got a lot more bearing on how we treat Gnome and KDE than the layout of the download page, and I'd consider it as something that would need to be done if you're going to argue for parity in that respect. Because, fundamentally, your argument isn't about CD naming. It's about how these two desktops are treated in the distribution. Changing the names doesn't change the treatment, whereas changing the treatment eventually results in the name change ocurring naturally. I agree. The multiple years of unpaid work I spent on Debian and Ubuntu ought to demonstrate that. I care enough about Fedora that I spend a significant amount of time working on it outside my paid hours. Many of the contributions I've made to Fedora are entirely out of the scope of my job, but I do it because I care about producing an OS that's competitive with anything else on the market. Excellent! So please try not to sound like volunteers' work is somehow inferior to paid engineers' work. I don't think it is. I think that volunteers are capable of producing work of equal quality to full-time workers. But I also think that full-time workers are able to produce more of that work, and if there's more of them to start with then that makes an even larger difference to the total contribution to the project. -- Matthew Garrett | mj...@srcf.ucam.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
On Mon, Jun 29, 2009 at 04:09:39AM +0200, Neil Thompson wrote: Personally I think that kicking KDE out would be a good idea if it would get rid of all the KDE fanbois and fanboi-type shrill argumentation. That's unnecessary. The people involved in this discussion have contributed a lot to Fedora, and there's no need to imply that they're lacking in rationality. -- Matthew Garrett | mj...@srcf.ucam.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
On Fri, Jun 26, 2009 at 05:27:12PM -0500, Matthew Woehlke wrote: Kevin Kofler wrote: As Orcan's and John's reply show, I'm far from the only one who thinks the current naming of the GNOME-based spin is misleading and biased (which was another thing the opponents to my proposal claimed during the meeting). ...and they're just the ones annoyed enough to speak up. Well, count me now in that number also. I too would like to see KDE treated as a first-class citizen, rather than blindly pushing Gnome to the ignorant masses. We need to provide a default desktop. There's no separate but equal here - Gnome in Fedora simply gets more development effort, has more documentation based around it and therefore deserves to be the default. Pretending that KDE has the same level of support does nothing to benefit KDE. -- Matthew Garrett | mj...@srcf.ucam.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
On Fri, Jun 26, 2009 at 07:44:48PM -0500, inode0 wrote: When I look at a directory listing and see Fedora-11-x86_64-Live.iso Fedora-11-x86_64-Live-KDE.iso it is pretty clear to KDE users which image they want. How about we give the poor Gnome users the same courtesy and indicate which image includes what they are looking for? Why should KDE be treated better? Sure, Fedora-11-x86_64-Live.iso could be symlinked to Fedora-11-x86_64-Live-Gnome.iso. -- Matthew Garrett | mj...@srcf.ucam.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
On Sat, Jun 27, 2009 at 03:27:30AM +0200, Kevin Kofler wrote: Matthew Garrett wrote: It's not the project's role to lift non-default software to the same level of involvement as the default software. That's a premise I don't agree with. The non-default software has many users (see below), it is in our best interest to support it well. How many of those users are potential Fedora users? Why /should/ KDE be treated equally? Because it has roughly the same amount of users, if not more, than GNOME at a global level and because even around 30% of Fedora's users are using KDE judging from the live CD download stats from the torrent tracker. (I know these statistics suffer from all sorts of inaccuracies, but that won't change the order of magnitude.) Not supporting KDE would mean losing ~30% of our current users and 50+% of potential users, and also a sizable portion of our contributors (me included). The better we support KDE, the more people in that huge pool of potential users we can attract. It is in the interest of Fedora as a whole, even GNOME users, to treat KDE as a first-class citizen. You're presenting a false choice. Given current resources, it's not possible to support both Gnome and KDE to the same level. Treating both identically would mean reducing our involvement in Gnome, without there being any strong evidence that in doing so we'd increase the size of the Fedora user base. Crippling Gnome in order to ship two above-average desktops might be fair, but Ubuntu would have a better Gnome desktop and Suse would have a better KDE desktop. The only way we can be relevant is to concentrate development on one desktop. -- Matthew Garrett | mj...@srcf.ucam.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
On Sat, Jun 27, 2009 at 04:10:16AM +0200, Kevin Kofler wrote: Matthew Garrett wrote: It's not a default if you're providing a choice. I see no reason why we can't provide a choice of 2 desktops. How is a non-Linux user supposed to choose? We've optimised the Linux install procedure to the point where there's very little unusual terminology used, but Gnome and KDE really aren't something that a user can make an informed choice about. The OpenSuse install screen gives you no information that helps you decide which you want, and the only thing I can think of that would actually help would be something like: Gnome: Your Fedora install will look like Ubuntu, but blue. Choose this option if you want to run the desktop that has more Fedora developers working on it KDE: Your Fedora install will look different to Ubuntu, but will otherwise work pretty much as well except for when things aren't as well integrated Which still isn't a great deal of help. -- Matthew Garrett | mj...@srcf.ucam.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
On Sat, Jun 27, 2009 at 04:22:34AM +0200, Kevin Kofler wrote: Matthew Garrett wrote: You're presenting a false choice. Given current resources, it's not possible to support both Gnome and KDE to the same level. Unjustified claim. Not in the slightest. We have a finite quantity of developer time. Currently more of that is spent on Gnome than on KDE. Providing the same level of KDE support involves either finding a large number of full-time developers to work on KDE or moving some of the Gnome development effort over to KDE. KDE works just fine even now, in fact we actually update KDE much more actively in post-release updates than the GNOME maintainers update GNOME. The only part of support we're truly missing is political / presentation-related. No. You're missing documentation. You're missing integration. Treating both identically would mean reducing our involvement in Gnome, Huh? I'm not expecting our GNOME developers to suddenly work on KDE! Nobody is asking for that. Better KDE support will have no effect at all on GNOME. Where does this better support magically come from? The number of people working on KDE in Fedora is small compared to the number of people working on Gnome in Fedora. without there being any strong evidence that in doing so we'd increase the size of the Fedora user base. KDE is the preferred desktop of about half (give or take a dozen percentage points depending on whom you ask) of the GNU/Linux desktop users. It seems blatantly obvious to me that supporting it well is a way to attract users. Why? The natural choice for KDE users right now is either OpenSuse or Kubuntu. Why would these users choose Fedora instead? Crippling Gnome in order to ship two above-average desktops might be fair, Where did I ask to cripple GNOME? I don't want to cripple anything! The alternative is to provide enough resources to be able to hire several full time KDE developers. but Ubuntu would have a better Gnome desktop and Suse would have a better KDE desktop. That's not a given. In fact several people who tried multiple distros have found Fedora's current KDE packaging to be the best KDE 4 packaging around. (Of course, it's all a matter of taste, openSUSE is also often claimed to be the best KDE 4, and sometimes other names come up as well.) The assertion that we do not have the resources to provide a high-quality KDE packaging is ludicrous and an insult to me and all the other KDE SIG members. My simple assertion is that a desktop maintained by a small number of part-time volunteers is unlikely to be of the same quality as one maintained by a larger number of full-time workers. To say otherwise would imply that Suse's maintainers are incompetent. The only way we can be relevant is to concentrate development on one desktop. Nonsense. See above. And in fact both the competitors you quote don't do this, Ubuntu has Kubuntu, openSUSE supports both GNOME and KDE and presents them as equally-supported options in the installer and on the download page. Kubuntu is primarily volunteer-based, though does have some amount of full-time work - but overall, the Ubuntu development process is heavily focused on Ubuntu and not Kubuntu. Aspects of the Gnome stack in OpenSuse are focuses of development, but again the bias is clear. Fedora's clearly a better Gnome desktop than OpenSuse is. -- Matthew Garrett | mj...@srcf.ucam.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PolicyKit and malware, was: What I HATE about F11
On Thu, Jun 18, 2009 at 07:09:29PM +0100, Richard W.M. Jones wrote: On Thu, Jun 18, 2009 at 11:02:22AM -0400, Matthias Clasen wrote: The retained authorization is only valid for the subject that obtained it, which will typically be a process (identified by process id and start time) or a canonical bus name. And your malware does not have either. Can the malware inject code into the process which gained the authentication (eg. using ptrace)? If you have malware in your session then it's already able to capture your password. You've already effectively lost. -- Matthew Garrett | mj...@srcf.ucam.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Porting amarok-1.4 to F11
On Wed, Jun 17, 2009 at 04:56:26PM +0200, Ingvar Hagelund wrote: * Ingvar Hagelund But amarok-2.x does not (yet) support non-hardware (that is, not found by HAL) mounts. * Kevin Kofler What would such a non-hardware mount be? Are you trying to use a partition or directory on your computer as a fake iPod? Why Not fake. Real iPods like the iPhone or the iPod Touch. They are mounted using Fuse mounts, that is sshfs or ifuse. Fuse mounts are not detected by HAL. Yes they are. You'll need an appropriate fdi file to indicate that they're an ipod, though. -- Matthew Garrett | mj...@srcf.ucam.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Porting amarok-1.4 to F11
On Wed, Jun 17, 2009 at 11:12:20AM -0700, Adam Williamson wrote: On Wed, 2009-06-17 at 16:07 +0100, Matthew Garrett wrote: Yes they are. You'll need an appropriate fdi file to indicate that they're an ipod, though. To be clear, apps like AmaroK / Rhythmbox would just talk to the iPod via libgpod or similar directly. The FUSE method of 'mounting' iPods is just another way of talking to libgpod, to give you the convenient user interface of a mounted filesystem, but it doesn't really make sense for other applications to go through the fake filesystem rather than just using the library to talk to the device directly. Right, but my understanding was that various applications required a mount point to be flagged as belonging to an ipod for them to use libgpod on it. The ipod touch and iphone can't be used as mass-storage devices - they speak a custom USB protocol which has been implemented as a fuse driver. -- Matthew Garrett | mj...@srcf.ucam.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: What I HATE about F11
On Sun, Jun 14, 2009 at 05:10:14PM +0200, Mathieu Bridon (bochecha) wrote: However, if we change the default, you have a system that may be giving too much permissions to some users depending on your taste. And the worse part is that you (as an admin) might not even know it ! The semantics of the wheel group are pretty well defined. -- Matthew Garrett | mj...@srcf.ucam.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: USB autosuspend in F12
On Wed, Jun 10, 2009 at 09:15:30AM -0400, Jesse Keating wrote: On Tue, 2009-06-09 at 19:32 +0100, Matthew Garrett wrote: Through F12 I'm going to be slowly enabling autosuspend on various pieces of USB hardware. The aim is to ensure that it's only enabled on hardware that supports it. This is going to be a combination of kernel modifications and packaging changes, and while I'll be testing as many as possible before uploading anything there's a risk that some hardware will misbehave. I'll let people know when I think I'm about to upload anything risky. Is this something worthy of being a feature? Possibly. I'd pretty much thought of it as bugfixing, but feature sounds fair. -- Matthew Garrett | mj...@srcf.ucam.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: USB autosuspend in F12
On Wed, Jun 10, 2009 at 05:16:41PM +0200, Roberto Ragusa wrote: Matthew Garrett wrote: The first part of this is an upload of libfprint which enables autosuspend on fingerprint readers. Fingerprint readers and other un-unpluggable USB laptop stuff such as flash-readers, bluetooth adapters etc. are perfect candidates for suspending. USB mass storage is more awkward, but otherwise yes. Note that this isn't inherently about suspending the device - they may go into a power savig state, but it's not required that they be fully powered down. The issue is more about letting the *bus* power down. How much we save will depend on the specific bus layout on a given machine, and also whether we can successfully autosuspend all of the drivers. -- Matthew Garrett | mj...@srcf.ucam.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
USB autosuspend in F12
USB is an irritating protocol that requires USB controllers to remain active whenever a device is attached, even if that device is doing nothing. This consumes unnecessary power and can prevent the system going into deep idle states under some circumstances. The kernel supports USB autosuspend, which allows idle USB devices to be suspended and the upstream ports to power down. This is disabled by default because it breaks various pieces of hardware. Through F12 I'm going to be slowly enabling autosuspend on various pieces of USB hardware. The aim is to ensure that it's only enabled on hardware that supports it. This is going to be a combination of kernel modifications and packaging changes, and while I'll be testing as many as possible before uploading anything there's a risk that some hardware will misbehave. I'll let people know when I think I'm about to upload anything risky. The first part of this is an upload of libfprint which enables autosuspend on fingerprint readers. I'm expecting this to be pretty safe, but there's always the possibility that a couple of people will find problems. If your fingerprint reader suddenly stops working after this change, please file a bug and include the output of lsusb. -- Matthew Garrett | mj...@srcf.ucam.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: USB autosuspend in F12
On Tue, Jun 09, 2009 at 01:18:31PM -0800, Jeff Spaleta wrote: As you move forward with this across the devicescape, how are you going to selectively enable devices to apply autosuspend to? Is this done by a whitelisting of specific device ids? Or is this going to be done based on a detected set of capabilities and then pruning that back with a blacklist? A mixture. Some devices will be explicitly whitelisted, while in other cases we'll be enabling all devices in a class (generally as determined by the kernel driver they use) and possibly blacklisting some of them. I've got some exotic homebrew usb equipment that I'm going to have to troubleshoot on my own, so it would be useful to know how you are going to slice the device space so I can figure out which devices should and should not be affected..eventually. It's unlikely that any of them will be covered by this. For now I'll be concentrating on fairly common hardware in order to get the maximum benefit at minimum effort. We'll worry about more obscure devices at some later point. -- Matthew Garrett | mj...@srcf.ucam.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Interested in scanning?
On Fri, Jun 05, 2009 at 04:32:12PM +0300, Nicu Buculei wrote: On 06/05/2009 04:14 PM, Matthias Clasen wrote: X crashing does not sound like something related to scanning in particular; but it is certainly a bug worth filing, especially if it is easily reproducible. I was not sure on which component should it be reported to, X, sane-backends/fronteds, gnomescan, xsane. If a program crashes, there's a bug in that program. There may also be a bug in whatever's triggering the crash, but that's a separate issue. FWIW I've had no trouble using xsane in F11. -- Matthew Garrett | mj...@srcf.ucam.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Thu, Jun 04, 2009 at 11:26:12PM +0200, Kevin Kofler wrote: Reindl Harald wrote: If you want that the enduser report bugs upstream you get no repsonse in many cases because the user will say WTF i wanted to help and you want to say me exactly how i have to help and after this happens trhee times he is frustrated and will never ever report bugs Your misunderstanding is there: it's US maintainers that are helping YOU reporters by fixing your bugs. If you think you don't need our help because you don't care about the bug anyway, we can just close it as INSUFFICIENT_DATA and stop there. Careful with that we. I'd rather have a large list of open but low priority and difficult to reproduce bugs than have users who never bother reporting bugs in the first place - I may never get round to fixing them myself, but having that bug open makes it easier for other people who hit the same issue to determine that it is a bug and perhaps save themselves some time. And if it ever does get fixed, then that's even better. Flagging it closed means that's less likely to happen, and the quality of the software that we ship (and, as a result, the perceived usefulness of Fedora) is lower as a result. -- Matthew Garrett | mj...@srcf.ucam.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Plans for tomorrow's (20090529) FESCo meeting
On Fri, May 29, 2009 at 02:23:23PM +0300, Jussi Lehtola wrote: On Fri, 2009-05-29 at 10:33 +0200, Till Maas wrote: There is a proposed Feature that connot be completed because kernel module packages are prohibited in Fedora: https://fedoraproject.org/wiki/Features/VirtualBox Maybe the necessary bits can be included in the Fedora kernel package itself? That's only likely to happen if the virtualbox code gets included in the upstream kernel. -- Matthew Garrett | mj...@srcf.ucam.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: turn SND_HDA_POWER_SAVE_DEFAULT back on?
On Sun, Jan 11, 2009 at 08:31:01AM -0600, Eric Sandeen wrote: (thanks to Thorsten Leemhuis for those pointers) it's no longer experimental It may no longer be functionally experimental, but does it still lead to popping on some hardware when the codec's powered up? -- Matthew Garrett | mj...@srcf.ucam.org ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
On Tue, Sep 30, 2008 at 10:33:14AM -0400, Jon Masters wrote: Yay! So then one day we can look forward to everything being built in and a user wanting to build a webcam driver having to build their own kernel too. Then we'll really have won because that user - who can follow some straightforward instructions on a website showing them how to build a driver and install it - will give up and go use Ubuntu. I don't think anyone's argued for building an entirely static kernel. Where there's a significant advantage to building something in (and Arjan has shown that there is), we should do it. If there isn't, we shouldn't. I really don't think there's any reason the vast majority of our users would want to replace their AHCI driver, and the -hda one needs solving in some way other than Download and rebuild ALSA anyway. Just because we can build our own kernels with whatever patches does not mean that all users who want to add a driver are capable of this. If users are capable of following the documentation for building an out of tree module, they're capable of following the documentation describing how to produce a modified kernel. The ones who aren't are, I'm willing to bet, a smaller number than the users who would be attracted by increased boot speeds. -- Matthew Garrett | [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
On Tue, Sep 30, 2008 at 10:38:12AM -0400, Jon Masters wrote: Nope. I'm just taking the viewpoint that users shouldn't be artificially restricted from doing so. At the point where someone suggests building something into the kernel purely in order to prevent users building an out of tree module, I think we should worry about that argument. Until then? -- Matthew Garrett | [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
On Thu, Sep 25, 2008 at 04:09:57PM -0400, Jon Masters wrote: I advocate extreme caution before just willy-nilly building everything into the kernel. Although this might seem like a great idea from the point of view of speeding up boot, there is also the pesky issue of users wanting the choice to decide which modules get loaded, and more importantly, wanting to override those modules with their own. To do this truly right we'll need to do rebinding of drivers in kernel. That's not always going to be easily possible after it's in use. Linux is not about choice. -- Matthew Garrett | [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: rawhide patches.
On Mon, Sep 29, 2008 at 10:47:05AM -0700, Roland McGrath wrote: linux-2.6-acpi-video-dos.patch linux-2.6-defaults-acpi-video.patch These are policy decisions. Probably not going usptream. Can they be turned into upstream config options? They're already runtime settable, so it's primarily a convenience thing - they're the sensible defaults given our userland. -- Matthew Garrett | [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: kernel module options for cpufreq
On Mon, Jun 30, 2008 at 09:10:28AM +0200, Adam Tkac wrote: On Fri, Jun 27, 2008 at 05:13:24PM +0100, Richard Hughes wrote: * remove CONFIG_CPU_FREQ_GOV_POWERSAVE -- ondemand automatically throttles down to lowest, and is just a hardcoded state I don't think removal of powersave governor is good idea. Generally ondemand governor does great job but in some cases doesn't. For example when I play some films in mplayer ondemand sets frequency to max which is not needed, of course. The same can be achieved by altering /sys/devices/system/cpu/*/cpufreq/scaling_max_freq, but it's still likely that you're consuming less power when ondemand is setting your frequency to max. An idle fast processor consumes less power than an active slow one. Powersave governor is also good in case that you have bad fan in your laptop and you are going to compile some big source. Without powersave it is not possible (yes, it really happens :) ) http://lkml.org/lkml/2008/6/16/100 I think we should preserve ondemand and powersave governors (and potentialy others as Dave Jones wrote in this thread). Please don't drop them in favour of your project which might be generally better but I believe there are cases where current governors are better. I'm open to indications as to what these are :) Powersave is semantically identical to ondemand with scaling_max_freq altered. Performance is semantically identical to ondemand with scaling_min_freq altered. -- Matthew Garrett | [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
