Re: RFE: Never, ever steal focus.
On Wed, Jan 6, 2010 at 1:08 PM, Adam Jackson wrote: > On Wed, 2010-01-06 at 11:23 -0600, Serge E. Hallyn wrote: >> There is no case where I want a new window or popup to take focus. Makes >> for an easy algorithm. (hitting r in mutt is not a problem :) > > There is no case where _you_ want this, sure. Some people what that. Many other people want the focus change to happen in a _few_ limited cases where it makes sense. Current behaviour fails to accurately predict those cases (no doubt because, in part, the limited acceptable cases differ from person to person), and so you get unexpected focus theft. This is bad for everyone. I think most people are actually in (2), in that a focus steal directly in response to an action by the user an instant ago isn't usually considered bad. Detecting that seems impossible (since you really need to measure intent, did I intend a new window to come up?). And even some people don't want that: I always prefer to load URLs in the background ... click-click-click pipelining up tabs which load in the background hiding the page load display. Fortunately that works *fine* for me using my hacked up configuration, /except/ when firefox pops up an alert box of any kind. I think people are generally more comfortable with the computer when it is highly predictable. _Never_ stealing focus wouldn't be optimal for everyone, but at least it wouldn't be surprising. If you cant get it right, at least be predictable. On Wed, Jan 6, 2010 at 4:01 PM, nodata wrote: > I either start typing a password into a dialog then something steals focus > and the password is in cleartext, or or the other way round: I start typing > something in one apps, a password dialog pops up, and I end up typing > non-passwords there. Ugh. Dangerous and not good. > > This must be solvable, not just for password entry. In the never-steal case you can learn (through trial and error :( ) to always click before typing a password. In the (sometimes or always) focus stealing case you can't even be conditioned to work with it, unless you consider visceral terror between each keystroke that the computer will do something unexpected causing you to type v.e.r.y.s.l.o.w.l.y. Both fail, one fails in a more predictable way. If nothing else, a configuration option would be good. Though I still hold that the state least likely to continually produce surprise should pretty much always be the default. On Wed, Jan 6, 2010 at 1:41 PM, Adam Jackson wrote: > To pick an example from my daily life: Someone pastes a bugzilla URL at > me on IRC, and I need to go scroll through it to see what they're > talking about. Thats pretty much the opposite of how I work. I'd rather the link loaded in the backround so that my flow isn't interrupted waiting for it to load. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFE: Never, ever steal focus.
On Wed, Jan 6, 2010 at 10:00 AM, nodata wrote: > I'd like to suggest an enhancement for Fedora 13: nothing should ever steal > focus from the window I am typing in. If I am typing in a shell window, or > in a word processor, or an e-mail, nothing should ever take keyboard focus > away from that window. > > Clearly I'm missing something, otherwise we would have this, hence the > posting to the list :) Firefox's focus stealing constantly drives me nuts. Trigger something to load things in another tab which later pops up some dialog (like an htauth dialog), then switch to another workspace ... and BAM, you're in the middle of typing and firefox has stolen focus. Helps if you're on a slow network so you have time to really get into your work on the other window before the theft happens. I had thought this was a consequence some non-standard window manager configuration I had... it drives me nuts but I've never seemed to be able to find the cause. If you'd like to try it out... go to http://www.pagetutor.com/keeper/http_authentication/index.html middle click the secret stuff link and then quickly (via the keyboard) switch to another workspace. (quickly is only required if your network is fast and the site is fast... I've had firefox steal focus many minutes after I last interacted with it) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: packaging a static library
On Wed, Dec 30, 2009 at 2:05 AM, Ralf Corsepius wrote: > On 12/30/2009 07:29 AM, Jon Masters wrote: >> One presumes that such auditing is expensive, lengthy, and not often to >> be repeated. Committing to undertaking a full code audit on every update >> would seem to be a little unreasonable of a request. So I think it's >> obvious that if they want to use an audited version, there will have to >> be a separate audited version. > > Well, I disagree: If they want to use "their auditied version", they haven't > understood how open source works. They qualify as jerks who prefer to use > proprietary forks instead of "paying back" to "upstream" and the wider > user-base. I'm sure any fixes have been contributed back and that any difference in /functionality/ are inconsequential. This reality invalidates your hostile accusation. On that point— please tone down the rhetoric, even if "haven't", "jerks", and "proprietary forks" are fair labels it's rather premature in the conversation to pull them out. This kind of name calling shuts down rational thinking. The concern here has nothing to do with the material functionality or directly measurable quality of libtommath, but instead it has everything to do with the color of the bits (http://ansuz.sooke.bc.ca/lawpoli/colour/2004061001.php). The audited version has a quality which is not held by any other version, but the quality in question is not an aspect of the functionality. It's the quality of being assured. There is nothing incompatible between assurance and open-source, although assurance is something that few open source packages bother providing today, partially because assurance is so costly. Thus the interest in formal methods (http://www.dwheeler.com/essays/oss_software_assurance.pdf), as they can theoretically lower the lifetime costs of high assurance. Crypto/bignum libraries evolve slowly enough that it isn't at all surprising to see even soft-assurances being seen as more valuable than improvements to the code. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Mass rebuild for F13?
On Mon, Dec 21, 2009 at 5:50 AM, Jakub Jelinek wrote: > I do not intend to jump to GCC 4.5 for F13, that would mean I and others > would have to spend almost all our time on that already by now, while there > is still a lot of work on GCC 4.4 bugfixing. > GCC 4.4-RH contains several GCC 4.5 new features backported, so I think we > can leave GCC 4.5 as a new feature to F14. Has any thought been given to the changes needed to make use of LTO when the switch to 4.5 is eventually made? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: packages requiring me to reboot...
On Wed, Dec 16, 2009 at 11:43 AM, Seth Vidal wrote: > you're an experienced user? You're comfortable knowing what does and what > does not require a reboot? Then why are you using PK? > > Disable pk and do the updates directly via yum. > > Bam - no more requests to reboot. This is a completely bogus rationale but one I commonly hear on this list. I, and many other fedora users would be quite *capable* of running our systems with any help of a distribution, we could go and fetch from source and do all the integration ourselves... ...but we'd actually like to get some work done using our computers and don't want to burn our lives away playing master-of-my-own-distro, though we're willing to spend some time contributing to a shared effort to build a good distribution for many. In exchange for not having to personally micro-manage things, we're willing to tolerate some things being configured in violation of our own preferences or aesthetics, or even a few things being outright broken, but that doesn't mean that it's not important for it to work right. Yes, I'm quite capable of executing some big manual process or changing packagekit to behave like I want. But every such action has costs, it takes time and effort which usually has to be repeated every upgrade. The non-standard configuration carries the risk of triggering bugs in other system components, breaking the upgrade process, etc. The gratuitous reboots are harmful to all users. They diminish a significant advantage our systems can have compared to alternatives like Microsoft Windows. They discourage the reporting of bugs in applications… "System acting weird? Just restart!". When triggered at inconvenient times they can cause significant harm by interrupting people's work. Yes— users with more expertise are more likely to complain about this, but thats not reason to dismiss the issue. If there were truly a disconnect here betweens the needs of the novices and those of the expert users you could argue favouring the novices, but that just isn't applicable here. -- 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 7:33 AM, Paul Jakma wrote: > If I put you in front of 2 identical machines, one running 32bit > and one 64bit software, would you be able to tell which one was > which, from the interactive performance of common applications? I'd > be willing to bet that for the vast majority of applications you > wouldn't be. Yet I could tell from the applications where performance is important. You reject my metric, I reject yours. Something of an impasse. [snip] > time, when email and browser apps start to demand 4GB+, but that time is a > while away I enjoyed how in nearly one breath you claim that performance is usually irrelevant then go on to name an application where performance is quite visible: A considerable amount of page load time is browser rendering. (It's also not too hard to make firefox use more than 3GB of virtual address space, though I admit you do need to work at it a little) What was the point of this conversation again? People have demonstrated on this list, with benchmarks, that x86_64 makes a material performance improvement across a broad swath of applications where performance matters. You point out that users don't care about performance in many cases. I do not disagree but I have no clue how we can qualify or quantify that. Certainly, when some website posts benchmarks of Fedora vs other distribution those threads get a lot of discussion but that isn't really evidence. I also do not know how it is relevant, in context of x86_64, to Fedora as the use of x86_64 is effectively free. The costs, such as reduced compatibility with binary browser plugins, are simply not relevant to many people. You're obviously convinced of your opinion, other people hold the view that good performance is part of the distribution's core job. Other than the point that x86_64 also increases security (from greatly increased address space layout randomization, and reduced PIE cost), I think we've hit on every point for and against using x86_64 in this thread— yet I think not a single person has changed their initial view. I don't see how any resolution is going to come from further discussion. -- 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 9, 2009 at 4:51 PM, Seth Vidal wrote: > and then you have to do that as well for updates. :( Not if you don't have a separate updates repo, no? -- 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 Tue, Dec 8, 2009 at 12:47 PM, Ralf Corsepius wrote: > That's one side, the other side is: > * Larger demands on RAM (x86_64 is more demanding on memory > requirements). Even if it were a full doubling (which is the absolute worst case possible), it would only be pushing the effective cost of memory back roughly 18 months or so. In reality the increase should be much less than 2x. > * More packages (rpms) to cope with. Hmm? I'm not sure what you're talking about there. It's completely reasonable to run an exclusively x86_64 system. I don't see why it implies any more packages. > * The "faster" is hardly sensible to ordinary users. You could equally say that the difference in memory consumption is not relevant to most ordinary users. Performance matters to everyone at least sometimes, but memory is only a big issue when you don't have enough. I think very few people running fedora are all that low on memory. Fedora has already chosen to make the 32bit builds incompatible with pre-686 systems for performance gains much smaller than you typically get from x86_64 vs x86, so it seems that some people think that performance is pretty important. Even the most undemanding users care about performance in at least some areas, for example on any given hardware x86_64 libtheora can play larger videos than 32-bit. On some hardware x86_64 vs 32bit is the difference between good and bad 1080p playback. I think if your position is that most users don't care about performance and other things (like compatibility) are more important then you should strongly promote x86_64 Fedora for everyone who can use it. If x86_64 fedora is widely used by those who can there will be less pressure to put leading-edge but less compatible features into the 32bit fedora build. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: memset bugs.
On Fri, Nov 27, 2009 at 1:26 AM, Roopesh Majeti wrote: > Hi All, > Iam new to this fedora world.. a small question on the below discussion: > It is mentioned that having, zero in the third argument is legitimate use > cases. Can somebody direct me to such a use case, as i feel, giving memset a > zero, is asking it, not to do anything [ might have side effects, not sure > from my end, though ]. It's legitimate because the zero may ultimately be derived from macro values and restructuring the code to avoid the memset depending on defined values may be non-trivial or even impossible. John Reiser provided a good example: http://www.linux-archive.org/fedora-development/286221-memset-bugs.html Where its not a programming bug the memset(,,0) is harmless: GCC optimizes it out completely. A literal zero prior to preprocessing is either a bug, or some kind of dead- code causing place-holder. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
On Mon, Nov 23, 2009 at 9:10 PM, Adam Williamson wrote: > Having said that - is everyone agreeing that it's fine for each spin SIG > to be entirely in charge of defining and implementing security policy [snip] Different spins having different security makes sense, especially if the differences are well documented. Hopefully the differences are an invitation to do bone-headed things: If some some spin decided to make every user run as root, ship with no firewalling, have password-less accounts, or have insecure services enabled by default, etc. it would risk tarnishing the Fedora image and result in Fedora being banned from networks even if it really was just the insecure-spin. I'm sure that everyone can be trusted not to do these things, but it may be worth stating explicitly that security should be a goal for all spins— only the details of the trade-offs should differ. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
On Mon, Nov 23, 2009 at 6:39 PM, Jesse Keating wrote: > Sure, I don't disagree, but I think we can take spots list and use it > for the 'guest account'. Then you start picking things off the list as > you move up the stack to 'university computer lab user (is that really > much different from guest?)', to 'non-admin user', to 'admin user'. I tend to think of guest as equal to "kiosk" i.e. the user is expected to be toxic waste incarnate, with no accountability... and that it is acceptable to substantially limit a guest in a way which wouldn't be so acceptable for a regular user. For example, the account could be locked down with MLS so that regardless of how other users have (mis-)configured their home directory permissions guest can't touch it (or other user's files in /tmp), or strict ulimits on guests so they can't OOM the system or forkbomb it. Users that have named accounts can usually be presumed to have some accountability: they may be clueless but if they do something malicious you know who they are. They're also less likely to enjoy bizarre limitations on their abilities. I think this generally maps well to the capabilities of a regular user account on a classic multi-user unix system. I suppose you could go on to define a kind of power-user role which has, effectively, all the 'safe' parts of root... the idea being that the user probably has root on the system in any case, so giving the safe bits (mostly various system level settings like adjusting the time, user-application add/remove, system updates, etc) makes things easier and eliminates transitions to the more dangerous admin account. -- 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 Mon, Nov 23, 2009 at 6:43 PM, Jesse Keating wrote: > This is precisely the dialog that has been removed from F12 and is not > planned to be returned. My understanding was that this was removed because collecting the root password during a user session is insecure because there could be a sniffer or the dialog could be faked. If I understand you correctly you are saying that even if this weakness were addressed (e.g. through whatever means make fast user switching secure) that the feature would not be re-introduced. Am I misunderstanding? If I am not misunderstand, can you point me to the real reason that this feature was removed? Thanks! -- 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 Mon, Nov 23, 2009 at 2:13 PM, Peter Jones wrote: > On 11/23/2009 01:24 PM, Gregory Maxwell wrote: >> I haven't tried the the fast user switching in fedora... Hopefully it is >> using some kernel mode secure path to prevent users from stealing each others >> credentials, if it isn't then one should be established for it. Why not use >> the >> same facility to switch to a system administration desktop, locked down a >> bit by >> default (use SE linux to make various unsafe user tasks like firefox, >> open office, etc unable to run in this admin context) to discourage >> casual use. > > Wait, you're arguing for this *instead* of finer-grained elevations of > privilege > governed by policy files which can be locally overridden safely? I'm arguing for a secure way for users to obtain authoization to perform administrative operations instead of elevating them by default, and expecting the computer operator to go and hunt down the moving target of security holes in every new version of Fedora. This isn't mutually exclusive with finer-grained elevations but would allow finer grained elevations to stay out of the default install: When additional privileged is needed, the system prompts you to authenticate via a secure prompt. At that point if you have the required credentials you could authorize the activity and, optionally, permit that account to perform the same operation in the future. Obviously this kind of one-off permission granting isn't reasonable in a large environment, but large environments are the place where "customize the policy" is a workable answer especially when the systems is secure by default and customization can be applied selectively at the greatest pain points. This is a point I think people miss when advancing the position that it's only to be less secure for convince sake as you can customize your way out of a security hole: Customization has a non-trivial cost. If it didn't we'd all run build our systems from scratch rather than using distributions. To customize you must learn, understand, and track changes from version to version. If you're only customizing to make your systems easier the customization trade-off is easy to balance: When something annoys you, you learn about and then customize only that. But when you need to customize to get the expected security behaviour you must carefully evaluate all the security properties because insecurity is largely invisible until its too late. >> Surely this would be preferable to reducing the security against >> common casual threats. > > I think you've characterized things backwards here. Perhaps. I know that in my environment someone running software on my account to sniff the credentials is less likely than someone sitting at my computer and twiddling knobs while I walk away (but not long enough to get away with rebooting the system). If they could sit at my account they could start up such a sniffer, but the sort of people who would screw with my systems probably wouldn't. On Mon, Nov 23, 2009 at 4:40 PM, Krzysztof Halasa wrote: > I'm not talking about reducing security. su, sudo are already suid root > (on most systems at least, especially su). Yes, this is, or at least may > be, a security risk. Admin entering root's password in insecure session > to install software is another security risk. That obviously doesn't > mean I want non-root users to install system software at will. Though this isn't necessary. A facility to obtain elevated authority could be provided which eliminates this risk. > I just say that when it comes to entering the root password (and/or > installing system software), it should be done in a secure manner, > preferably not from within user X session (unless the risk = the fact > of user = root equivalency is explicitly and specifically understood > and accepted). Sorry— I thought you were taking the further position that because entering the password is also a risk, that it's okay to simply give subsets of privileged to users. You're correct. It's a risk which should and can be eliminated. -- 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 Mon, Nov 23, 2009 at 9:37 AM, Krzysztof Halasa wrote: > Kevin Kofler writes: >>> I never tick those boxes. I'd like to know how to get rid of them >>> entirely. >> Upgrade to F12 (with the latest PackageKit update), there's no such checkbox >> in F12's PolicyKit. > This is good. > > Also we should remember that user entering root password in user's > session makes the user account practically equivalent to root (it can be > seen as a protection against incidental damage, but not against a real > attack). The only secure way has to use a fully trusted path from the > person to the root process - e.g. logging as root (or root-equivalent) > initially, with a physically secured console (some sysrq-k or > ctrl-alt-del combo which cannot be remapped or blocked by non-root etc). > > E.g. using su or in most cases sudo etc. makes the non-root account > equivalent to root. This can be, of course, deemed secure as long as we > accept and understand this equivalency. There are many kinds of security threat out there. For example, a few dishonest people within the fedora project could conspire to backdoor the heck out of Fedora with a reasonable chance of not getting caught. Does this fact mean that we should not bother with signing packages or other security measures? Likewise, someone could load up some kind of X sniffer that intercepts the root password when its typed in. Someone could also break into your house and take apart your computer. Yet in many environments these threats are insignificant compared to a co-worker or family member casually twiddling around with the machine. I haven't tried the the fast user switching in fedora... Hopefully it is using some kernel mode secure path to prevent users from stealing each others credentials, if it isn't then one should be established for it. Why not use the same facility to switch to a system administration desktop, locked down a bit by default (use SE linux to make various unsafe user tasks like firefox, open office, etc unable to run in this admin context) to discourage casual use. Surely this would be preferable to reducing the security against common casual threats. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F12: where did window properties go?
2009/11/20 Pádraig Brady : > Jesse Keating wrote: >> You're making the assumption that the change was made to save space. It >> wasn't. I can't find the original thread right now, but it's part of a >> cleanup on configuration tools. Upstream felt it no longer necessary to >> expose this > > Wow. Did they get any estimates on the % of users that set this option > before coming to that decision? > > IMHO the only advantage an overlapping window manager has over > say a tiling window manager is in conjunction with sloppy focus. This is completely consistent with what is going on a decade of behaviour from that particular upstream. If you don't want your usability removed in the name of usability, don't use gnome. A quick google on this will find you dozens of times were that particular complaint fest has been had... it won't be productive to have it again. -- 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 12:26 AM, Conrad Meyer wrote: > On the contrary. On the typical single user system, it's just as bad if an > attacker can steal / delete / modify the user's files as it is if the attacker > can modify / delete system files. Privilege escalation isn't needed to delete > everything the single user cares about. Not quite. For example, it's much easier to fix a system which has only had a user account compromised, since if you actually trust that its only the user account you can skip the full reinstall. This is also assuming a strictly single user system. With features like fast user switching it wouldn't be inadvisable or especially inconvenient to operate business and pleasure activities from separate accounts. I don't know anyone that does this today, but as it becomes easier to do so and if the systems don't continue to go down the route of giving the local accounts root access then it may be a practice which becomes common. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security policy oversight needed?
On Thu, Nov 19, 2009 at 12:40 PM, Jesse Keating wrote: > On Thu, 2009-11-19 at 12:33 -0500, Gregory Maxwell wrote: >> ...add what you want, and have PolicyKit pulled in as a dependency. >> When this discussion came up I tried doing a yum erase PolicyKit on >> one of my systems and had it offer to remove some 372 package, >> including xorg-x11-drivers. > I'm not sure what you're trying to say here. PolicyKit is an integral > part of our distribution. The policies that get loaded into PolicyKit > can come from different sources though, either a blanket policy package, > or individual policy files to go along with individual packages. So in > your case, while you have PolicyKit installed, you may not have had > PackageKit, nor the policy that would grant PackageKit to do thing for > local users. We obviously must be talking past each other. I see people complaining that they don't want these non-unixy policies being silently installed on systems where they are surprising and where they are configured in invisible ways that skilled unix admins will fail to discover. You pointed out that a server install can/should be conducted by installing a fairly limited set of packages. I'm trying to point out that installing limited packages doesn't fix the problem because it is not clear which packages are responsible for setting (subverting, depending on your outlook) system wide security policy… except PolicyKit itself, which you can't leave out. In the past I could simply check to see if a package contained SUID 0 binaries or modified a small number of fairly obvious system config files and have good confidence that it wasn't changing the root/user boundary line. This takes us back to the beginning of the thread where Chris was calling for auditing, oversight, and accounting for significant security modifying behaviours. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security policy oversight needed?
On Thu, Nov 19, 2009 at 11:42 AM, Jesse Keating wrote: > We have a server spin, and it's boot.iso/netinst.iso. And no, I am not > joking. Servers are installed by starting with the smallest possible > package set to get the system booted and on the network, then adding the > specific functionality you want the server to perform, such as http > server, or mail server. Nothing more. It is the very essence of start > from nothing, add what you want. ...add what you want, and have PolicyKit pulled in as a dependency. When this discussion came up I tried doing a yum erase PolicyKit on one of my systems and had it offer to remove some 372 package, including xorg-x11-drivers. I don't mind at all that I have to type my administrator password in to do root privileged things on my desktop or laptop. I don't want the normal security model to be circumvented in odd ways. And I really wanted a batteries-not-included server I'd install gentoo. -- 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, Nov 18, 2009 at 9:13 PM, King InuYasha wrote: > Except, that could be false advertising. In most cases, where CPU > computation is not used heavily, 64-bit is actually SLOWER than the 32-bit > counterpart. Optimizations are narrowing the gap, but it still remains > true. You might want to try restating that, because what you're saying sounds like "In cases where the CPU isn't used, 32bit is faster". Which isn't sensible. What I think you're intending to say that x86_64 is only faster on small tight pure-compute kernels like data compression or image processing, but I don't believe that is correct anymore. The biggest gaps I encounter in x86_64 performance anymore tend to be due to things like missing optimizations in glibc. x86_64 supporting 64bit registers is really only a small aspect of the enhancements. Other important improvements include SSE2 as a mandatory architectural feature (as well as a number of other things, like cmov), support for larger processes, improvements to syscall entry, and a doubling of the registers (also sse registers). The last of these is very important because x86 has historically been very register starved and x86_64 makes it basically reasonable. The primary downside of x86_64 is that the larger pointers increase memory usage. You might expect to see some loss in performance from increased cache footprint, but I don't on the multi-megabyte caches on the desktop CPUs. Suggest a benchmark. Now— On a memory starved system. Thats another matter entirely, you have my full agreement that 32bit installs are better off if the alternative is 64bits and swapping. :) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security policy oversight needed?
On Wed, Nov 18, 2009 at 7:37 PM, Mike McGrath wrote: > I think that's too subjective though. I'd be more in favor of a simple, How is this subjective? At one time it was the norm that you had to justify a SUID 0 binary. Packagekit is basically allowing the same thing through other means. It should be subject to at least the same scrutiny. > broad view of what the user should be able to do without root. It's > possible "install packages" would be on that list, it's possible not. > That way packages could ask themselves "does this break the policy?" If > it doesn't, great. If it does, time for a bug report. > > Better then a review process because then everyone would generally know > what to expect. Some kind of review and disclosure should still be required because security holes can be astonishingly difficult to spot as bugs, yet utterly trivial to exploit. The time configuration policy is actually a fantastic example of this: After it was pointed out that any user could change the time willy-nilly the complaint was disregarded and denied by many because the dialog *did* ask for a password, as would be the classic unix security model expectation. Except… it was asking for the *users* password rather than a root password— so if you happen to know both (or if they are the same) you could test it and fail to realize that it was violating the long-standing expectation. There is also the significant possibility of policy interaction. A sufficiently general policy (i.e. one which isn't just the policykit policy) could possibly permit configurations which are acceptable in isolation but which are hazardous in practice. E.g. perhaps one policy permits the install of packages from pre-configured repos and another policy permits the user to add repos (to make it easy to navigate them in the package management interface). (Not the adding packages from existing repos isn't already a terrible security hole: Unless you have very specific rules about the default configuration of packages in the repo it's likely that some of the packages will violate the security expectations when installed) -- 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, Nov 18, 2009 at 1:55 AM, Josephine Tannhäuser wrote: > 2009/11/18, Gregory Maxwell : >> I noticed that http://fedoraproject.org/get-fedora appears to be >> strongly promoting i386 Fedora over x86_64. Is this intentional or an >> oversight? > I think this is a script which reads your currently used architecture > and provide a dl link. please insert a x86_64 livecd and try it again! As others have pointed out: this is not so and probably can't produce reasonable results. On Wed, Nov 18, 2009 at 1:55 AM, Jeff Garzik wrote: > However, if you just want a single "download now" button, 32-bit would get > you the widest hardware coverage. Absolutely. Although it was my understanding that the stated goal was to encourage everyone on capable hardware to run x86_64, and previous editions of the download page did seem to do that. I don't personally have much of a horse in that race beyond the fact that I argued against dropping support for some older systems in the 32 bit build based on the position that users on new hardware should be running x86_64. There is obviously a trade-off in having the simplest possible install vs getting people the best platform support. Considering the complexity of the overall install I think the extra work to select an architecture at download time would be a comparatively small hurdle. In any case— the trade-off here should be consciously chosen and not the result of an oversight in the development of the download page. (Which I think think is generally quite good). -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Promoting i386 version over x86_64?
I noticed that http://fedoraproject.org/get-fedora appears to be strongly promoting i386 Fedora over x86_64. Is this intentional or an oversight? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Buyer Beware: A Major Change in NFS (in Rawhide) is about to happen
On Mon, Oct 26, 2009 at 1:13 PM, Steve Dickson wrote: > On a pre F-12 Server: > 2) Added the '/ *(ro,fsid=0)' entry to the /etc/exportsfile and > reset the exports with 'exportfs -arv' (see exports(5) for details). *Please* stop recommending this to people. This is a myopic configuration change which will violate the security assumptions of almost any system out there. It's not what practically anyone wants. Arguably the exports tool should even prohibit this kind of configuration unless you set some yes-I-really-intend-to-be-completely-insecure knob, it's certainly not something that should be recommended as a fix for "help! nfs stopped working when I upgrade to F13". -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Buyer Beware: A Major Change in NFS is about to happen
On Tue, Sep 29, 2009 at 9:42 PM, Chris Adams wrote: > Once upon a time, Steve Dickson said: >> On the server (Which is suggested): >> * Add the following entry to the /etc/exports file: >> / *(ro,fsid=0) Note: 'fsid=0' is explained in the exports(5) man pages. > > The "suggested solution" is to change your NFS servers (that work just > fine with other clients today) to export the root filesystem to > everybody? Yea— It would be ill-advised to actually recommend this to people. Someone might actually listen and be rather unhappy that your suggestion undermined their security assumptions. (Okay, you can say someone who doesn't understand what that line does shouldn't be adding it to their exports; but people will) If this change in default behavior doesn't go in to F12 does the correct handling of the pseudo-root go in? For all the arguments against accepting the behavior change at a late date, accepting the server fixes seems far less scary and getting them in ASAP will make the behavior change less disruptive in the future. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: crypto consolidation status?
On Sun, Sep 27, 2009 at 1:44 AM, Ken Dreyer wrote: > I read the wiki page[1] on Fedora's effort to consolidate all the > crypto libraries. Quite an ambitious task! FWN [2] reported on the > rather large discussion back in '07, but I didn't see any resolution. > Is this still a goal for Fedora? The main wiki page hasn't been edited > in almost a year (although the scorecard is still being maintained). > > The reason I bring all of this up is that Server Name Indication has > recently been implemented into httpd's mod_ssl, but SNI is not present > in mod_nss[3]. If we abandon mod_ssl for mod_nss, we would lose this > functionality. [snip] Is this even a fair and reasonable goal unless the NSS upstream is really interested in becoming a superset of the functionality offered by the other crypto libraries? (I don't know for surethat NSS' goal is not to— but I think thats unlikely. It's hard to even start a comparison because NSS doesn't appear to have developer documentation covering low level cryptographic functions) Is it reasonable when other package upstreams may not find the licensing of NSS to be acceptable (i.e. an upstream which is 100% BSD for it and all its dependencies), or would prefer not to use NSS for stylistic reasons— Would fedora carry patches for these applications in perpetuity? It's not even clear to me what exactly some of these goals mean i.e. "Get a cert using Firefox, use it in SSH" when ssh doesn't (normally) use X.509 certificates. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GCC var-tracking-assignments: testing and bug reports appreciated
On Wed, Sep 9, 2009 at 11:53 PM, Michel Alexandre Salim wrote: > On Tue, Sep 8, 2009 at 9:46 PM, Alexandre Oliva wrote: >> Jakub built gcc-4.4.1-10 earlier today, with a new feature that >> generates much better debug information in optimized programs. >> >> The feature has been under development for a couple of years, and it's >> recently been accepted into GCC, for GCC 4.5. We've backported it for >> Fedora 12. >> >> I'd appreciate if you Cc: me on any bug reports you hit that might be >> related with this new feature (GCC internal compiler errors, verify_ssa >> failures, crashes, etc). >> > This bug affects LLVM on ppc: > > https://bugzilla.redhat.com/show_bug.cgi?id=522316 I don't see a more recent pass in Koji. Did you try compiling with -fno-var-tracking-assignments does it help? -- 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 3, 2009 at 9:38 AM, 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. [snip] What would be the point of packaging something which can not operate without codecs that fedora can not and should not ship? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Empathy default in F12?
On Mon, Aug 17, 2009 at 6:31 PM, Mathieu Bridon (bochecha) wrote: >> I understand the urge to ship empathy because it's included in gnome >> -- but let's be honest: if the two clients were judged side-by-side >> and rated, there's not a chance in hell empathy would win. : ) > > ... and yet some of us definitely prefer it to Pidgin. :) > > I'm not sure the default apps should be chosen by popularity. Each > spin is produced by a team. This team has a vision of what they want > their spin to be like, and they choose the default apps according to > this vision. If you want to participate in the choice of the default [snip] I don't think anyone is calling for a vote here. (Though if there were one… I think the outcome would be obvious). The kind of non-trivial feature gaps that have been raised are exactly the sort of criteria which should influence in a decision, regardless of popularity. Vision is grand. I hope that software which meets peoples needs, and software which protects people's confidentiality is part of the shared fedora vision. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Empathy default in F12?
On Mon, Aug 17, 2009 at 9:40 AM, Bastien Nocera wrote: > On Sun, 2009-08-16 at 18:02 -0400, Gregory Maxwell wrote: > >> But since other people may not care about that (i.e. Empathy >> developers mock people who want confidentiality, i.e. >> http://resiak.livejournal.com/60614.html ), I thought I'd see if I >> had any other concerns. > > Given that this was an April's Fool, I don't really see what the problem > is here... > > You'll have to find another source to prove that the upstream don't > actually care about OTR support. Do I? It was an aside. It is indisputable that the functionality does not currently exist, and is not planned. The official FAQ[1] states that they only intend to support protocol-native encryption. This position neglects the large base of users that have no interest in switching IM networks and who are completely satisfied by auto-negotiating overlay encryption. [1] http://live.gnome.org/Empathy/FAQ#head-a0dc4ab0af32e3bc3a350974a791764b8fb35c39 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Empathy default in F12?
On Sun, Aug 16, 2009 at 3:40 AM, Rahul Sundaram wrote: > On 08/16/2009 01:05 PM, Gregory Maxwell wrote: >> The F12 feature still indicates the switch to Empathy as a default IM >> client in Fedora. >> >> However, the talk page for the feature >> (https://fedoraproject.org/wiki/Talk:Features/Empathy) raises material >> concerns that the switch to Empathy would result in an insufficiently >> justified loss of functionality. >> >> Where does this currently stand? > > My understanding is that Empathy is still planned to be the default. > What specific concerns do you have? For me? It doesn't support OTR. Which is basically a non-starer for me. Thanks to the robust support in whatever client is popular in OSX plus pidgin on windows every single one of my contacts is OTR-enabled. Pushing people back to eavesdropping vulnerable IM is arguably unethical and not something that I'm going to do. But since other people may not care about that (i.e. Empathy developers mock people who want confidentiality, i.e. http://resiak.livejournal.com/60614.html ), I thought I'd see if I had any other concerns. Testing rawhide I found that it doesn't appear to have file transfer, which isn't a feature I use much but I know its important to other people. Cheers! -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Empathy default in F12?
The F12 feature still indicates the switch to Empathy as a default IM client in Fedora. However, the talk page for the feature (https://fedoraproject.org/wiki/Talk:Features/Empathy) raises material concerns that the switch to Empathy would result in an insufficiently justified loss of functionality. Where does this currently stand? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Lower Process Capabilities
On Wed, Jul 29, 2009 at 9:32 AM, Stephen Smalley wrote: > If you want something more akin to privilege bracketing within a > program, then a closer analog in SELinux would be setcon(3) to switch to > a more restricted domain. But in general our goal is to enforce > security goals at the system level and not depend on the correctness of > the application to shed privilege. [snip] But then, of course, we depend on the correctness of the system to deny privileges. Considering the number of users that disable SELinux entirely— this surely can't be counted on. And the historic number of applications which fail to shed privilege (to the limited extents possible) shows that depending on the application also isn't a complete solution. It seems to me that the approaches could be complimentary— It would be very nice if applications could drop any SELinux controlled privileged at runtime, either temporarily or permanently. This would not replace the system level protection but would supplement it by remaining active even if the wider protection were partially disabled, by offering finer granularity, and by giving developers a greater opportunity to participate in the use of SELinux (perhaps resulting in more applications being structured in SELinux friendly ways). Capabilities are agreed to be far too coarse, and they only subset root when we really want to subset user permissions too. SELinux provides many nice hooks. Developers would like to right software that remains as secure as possible even if a user has goofed up the file permissions. Is there no possible improvement here? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: License change for ghostscript
On Wed, Aug 5, 2009 at 6:32 PM, Chris Adams wrote: > Once upon a time, Tom spot Callaway said: >> On 08/05/2009 02:38 PM, Jussi Lehtola wrote: >> >Apropos, what's the license in case a GPL package links against OpenSSL? >> >GPL with exceptions or what? Or is it even allowed? >> >> So, in this specific case, I'm still arguing with Red Hat Legal, and we >> have not determined our final stance. > > This brings up something I've wondered: if you program to an API where > there are multiple implementations, is your program a derived work of > one of them, the other, or both? [snip] So— you make the matter a lot harder to discuss by taking about "your program (being) a derived work". The whole notion of the linking boundary creating a derived work is unnecessary for copyleft, and trying to apply it adds more confusion than clarity. Here is a conceptual framework for analyzing the issue which is pretty robust against corner cases like the multiple APIs: The licenses of pagkage X is only relevant when you are using/distributing package X and can only set the conditions under which you may use/distribute it. However, the license can stipulate nearly arbitrary conditions: "Can only make copies of this on tuesday", "This license is void for copies placed on physical media which have been stored within 15 feet of a microsoft product", "Only valid for use by women named 'Bob'", etc. None of these should be understood as effecting things outside of the software in any kind of direct way: The license hasn't required you to get a sex and name change, but rather said you can't use the software unless you do. So if you create a piece of software that can equally link to X or Y, and you never use/distribute X yourself you are simply not within reach of X's licensing terms. If someone else takes your software and X then sticks them on a CD, then they are obligated to follow X's license, which may include terms that make depends about the licensing of other software— ... software that links to it... software on the same media software in the same building ... software that starts with the same letter. Doesn't matter. Whatever the conditions are, they are the conditions for using X. If you can't simultaneously satisfy the requirements of X and the requirements of some other software package you'll have to stop distributing one or the other or risk litigation from whomevers requirements you're violating. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: openssh-blacklist - careless waste of space.
On Fri, Jul 31, 2009 at 11:31 AM, Steve Grubb wrote: > On Friday 31 July 2009 04:42:12 am Frank Murphy wrote: >> I think what is meant, it that the app is useless, without either >> web\media input. Which the user should not have to do to take full >> advantage of it. > > I think this is a bit like virus definitions. It's more akin to a bad password list. > 800Mb is excessive to ship in a > package. I think the definitions could be created by a script, but will take > some time to generate. Maybe adding a generator for people not connected would > let them recreate the content? > > But a 800Mb package is bigger than the livecd. What?! Openssh-blacklist is a list of bad keys that could have been generated by the debian lack of entropy bug. In it should be a couple of text files: A DSA key file, and an RSA key file for each of a couple common key sizes. Each file should have 100k lines or so with just a fingerprint on them.. all in all it should just be a couple of mbytes. It looks like that distribution also includes the full public and private keyparts for the bad keys in addition to the fingerprints. That isn't needed for bad key screening— that additional info is only really needed by attackers. After the vulnerability I screened the accounts on my systems and found a couple of these bad keys just from giving my ubuntu/debian running friends access to rsync data, so this is a risk for fedora users too. Not only should this install without requiring a live internet connection but these, or at least a subset with the most common key sizes, should really be part of the default ssh install along with the feature in SSH that causes it to refuse to use these keys. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Firewall rules using SELinux context (Was Re: RFE: FireKit)
On Fri, Jul 24, 2009 at 5:49 PM, Roland McGrath wrote: > So I think most of us in this discussion probably don't actually understand > SECMARK. I sure didn't. I think I might now, sort of. The SELinux policy > just says contexts, and it doesn't say anything about the port numbers. > The point of SECMARK is that you write port-matching rules that are what > sets the context on those packets. You have to write those rules by hand > (or somehow) or else there just aren't ever any packets anywhere that are > marked with the right context so they match the SELinux policy for what the > given daemon is allowed to see. > > So I think what one really wants is just a better level of admin/packaging > coordination. That is, you would really like to write in one place both > the SELinux policy and the port numbers (i.e. iptables matching rules) you [snip] Not just port numbers. For example. I might want to confine CUPS to only speak to localhost and 192.168.1.1/32; 192.168.10.1/32; 192.168.15.3/32, so that if something running as cups_t is compromised it can only talk to my print servers and not phone home or get messages from an external botnet controller. I think SECMARK can do this, but I think that it would require me to change the SE linux policy to only allow cups_t to touch cups marked packets. I think this would be much easier to administer as pure firewall rules, i.e. -S 192.168.1.1/32 --dctx cups_t -j ACCEPT ... --dctx cups_t -j REJECT --sctx cups_t -D 192.168.1.1/32 -j ACCEPT --sctx cups_t -j REJECT As far as I can tell the only way to get the same general behavior from SECMARK is it to make the SELINUX policy require the marking then have a bunch of marking rules. Then your apps break if the firewall is not activated. I consider this a bootstrapping problem. I'm also not sure how you could achieve multiple contexts being permitted to access a particular set of traffic using secmark nor can I figure out how you could accomplish the output side. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: http://www.fsf.org/news/dont-depend-on-mono
On Tue, Jul 7, 2009 at 10:05 AM, Adam Jackson wrote: [snip] > So, if Frobnitz Inc. distributed Mono, and then filed suit against > Microsoft for infringing one of Frobnitz' patents in the Microsoft C# > implementation, they would lose the right to distribute Mono [1]. [snip] > In other words, it's a MAD agreement. You're not even agreeing that any Sadly most MAD agreements are also uni-lateral disarmament agreements. They are only really mutual when the participants are true peers and otherwise magnify existing power imbalances between the parties. Try this alternative scenario: Over time Frobnitz amasses a large portfolio of patents which it places in trust to help defend its free software business. Frobnitz scrupulously avoids encumbered technoligy without irrevocable free software compatible licenses, but it does rely heavily on technology available under terms like the ones under discussion. Later Microsoft initiates spurious patent litigation against Frobnitz which will ultimately fail but cost frobnitz millions in the process (perhaps as part of an attempted takeover). Normally Frobnitz would use its defensive portfolio to discourage this sort of attack, but unfortunately this option has been eliminated because any patent litigation would result in the revocation of permission for several pieces of technology which it is openly and publicly practicing, depends on for compatibility, etc. If Frobnitz doesn't think the MAD-covered patents are valid or applicable and that it could quickly and cheaply fight them, then it doesn't matter much, but in that case it didn't really need the MAD grant at all. If they are valid then frobnitz would be better off if they retained the flexibility of So to sometimes these 'MAD' terms are just 'AD', nothing much mutual about them. Of course, if you aren't the sort that would keep a patent stockpile for defense, the distinction is moot. But, it's still naive to look at that kind of 'MAD' grant as a cure-all. -greg [speaking for no one but himself] -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Time for 2.6.30 in F-11?
On Sat, Jul 4, 2009 at 6:40 AM, Bojan Smojver wrote: > Now that .1 is out, is there anything in particular stopping F-11 from > having this kernel? Worth mentioning— .30 makes a non-backwards-compatible BTRFS format change. So if you go .30 on a BTRFS system you can't go back. (though, I suppose that can be seen an argument for getting Fedora to .30 sooner) -- 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)
On Tue, Jun 23, 2009 at 4:19 PM, Clemens Eisserer wrote: >> 1) Optimizing for P4 is ... messy >> 2) If you're using C2D, etc., you can already use the 64-bit distro. > So why not stay with generic, where most users would benefit. > > Sure I could use 64-bit, as could all the others using 32-bit on > 64-bit capable CPUs (I guess 50% of all fedora-x86 users). Fedora x86_64 is the solution for good performance for those systems. The difference between 32bit mode and 64bit mode dwarfs all the little compiler tweaks we could discuss. Optimizing for atom makes sense because it's the most modern hardware which doesn't have a higher performing alternative than the 32bit build. Moreover, as an in-order core it atom should gain more from optimization than most cpus and generally optimizations for atom are harmless or even beneficial for other CPUs, while optimization for highly out of order CPUs can be devastating for in-order cores. As you can see in Bill's post upthread optimizing for atom is mildly beneficial even to P4. Amusingly, on my own code at least -mtune=atom produces significantly faster code than -mtune=geode on my geode LX. P4 is pretty much a lost cause. The move to i686 from i586 itself will make P4 slower, while helping most everything else by about the same margin that it hurt p4. Optimizing for P4 will probably hurt everything, certainly atom. Atom systems are frequently battery powered, so improvements there can also to increased battery life. P4, OTOH, already requires a locally installed atomic power plant so energy isn't an issue there. ... -- 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)
On Wed, Jun 17, 2009 at 1:52 PM, Bill Nottingham wrote: > Given the loud feedback, I've updated the proposal at: > https://fedoraproject.org/wiki/Features/F12X86Support > > The revised proposal: > > - Build all packages for i686 (this requires cmov) > - Optimize for Atom > > Why? > > - We don't really support i586 in any meaningful matter > - OLPC still works with base i686 > - We are likely doing a mass rebuild for F-12 anyways, might as well switch > while we're doing it > - Atom is the only currently produced 32-bit x86 chip of note; optimize > for what's currently available > > If you want numbers, I did some benchmarking of code [1] with various > build options on a variety of processors, with the F-11 gcc code. All > of these results are relative to a F-11 baseline of "-march=i586 > -mtune=generic". > > P4 2.4Ghz Athlon 3400+ Core2Duo E6850 Atom N270 > march=i686/ -1.1% +2.0% +0.9% +0.6% > mtune=generic > march=i586/ +0.3% -0.3% -0.2% +1.3% > mtune=atom > march=i686/ -1.5% +1.2% +0.5% +1.7% > mtune=atom If there is a mass rebuild… Consider: -Os on the x86 build? -O3 on x86_64? (Back in 2007 I would have screamed loudly that the auto-vectorizer produces broken code; but today it appears to work fine.) -- 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
On Tue, Jun 16, 2009 at 4:21 PM, Steven M. Parrish wrote: [snip] > I would instead propose that instead of killing off i586 that instead we make > i686+SSE2 a new primary arch. This will allow us to not only optimize Fedora > for i686+SSE2 but still maintain a viable arch i586 for not only the XO-1.0 > but also for the many older but still usable machines that would otherwise be > excluded from using Fedora. IMO the 32bit atom is the only remaining major x86 (32bit) arch worth optimizing for... P4 stinks (and, in fact, the addition of CMOV will very likely slow P4 down anyways)... Since ATOM is in-order it's a pretty distinct optimization target compared to other modern 32bit x86, though it doesn't seem like gcc is especially good at targeting it yet. Perhaps this particular proposal should just be left for another release cycle or two, and see what interest is like then. It would be unfortunate to spawn a whole new architecture when it may turn out to be uninteresting in a release or two. (It would also be another incentive for people not to move their x86_64 systems to an x86_64 build… which isn't something we should be creating). -- 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
2009/6/16 梁穗隆 : [snip] > So I suggest that Fedora 12 change 32-bit x86 arch to i686+SSE, not > i686+SSE2. Before someone picks up this particular suggestion and runs with it: SSE is not complete enough to replace x87. You don't get the kind of gain from SSE only that you can get from SSE2. The primary application for SSE without SSE2 is hand optimized code… stuff that already does runtime detection. -- 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
On Mon, Jun 15, 2009 at 6:01 PM, Bill Nottingham wrote: > Gregory Maxwell (gmaxw...@gmail.com) said: >> I doubt having consistently lower FP precision is anything many users >> are asking for. The few that do can usually take care of themselves. > > And yet you say we should push them all to x86_64, which has > the same lower precision? You misunderstand me. I don't think people care. Code that depends on the order of FPU register spills on it is broken. I'm saying it's not a feature. It's neutral. Or nearly so. >> > - More clearly delineates our support set of targets, sticking true >> > to forwards innovation, not necessarily legacy support >> >> If thats the case why maintain x86 at all? > > Because it's 58% of our userbase (source: F11 torrent stats.) The relevant break down is what percentage is x86 no sse2 vs x86 no x86_64 vs x86 w/ x86_64. >> Take your answer and now apply it to why fedora should maintain >> support for x86 CPUs without SSE2. > > Because that's significantly less of our userbase. I'd love to have > harder numbers, but we're still talking about a set of CPUs that > (outside of corner cases like the Geode and C3) ceased production > anywhere from 4 (Athlon) to 6 (P3) to 10 (P2) years ago. 'outside'. Please don't just dismiss these recent systems, they are a real issue. I have low power x86 which I purchased *recently* (geode box for audio conferencing, this year; and a via box from ~two years ago) without SSE2. Most of my systems are x86_64, but what is x86 is not sse capable. Anything of mine that needed performance became x86_64 a long time ago. On Mon, Jun 15, 2009 at 6:04 PM, Bill Nottingham wrote: >> It would probably be most interesting to perform that test on the >> x86-only ATOM, since I can see CMOV being a bigger win on an in-order >> CPU. >> (I can't personally protest: I think all the x86 stuff I have has CMOV). > Last time I profiled it (using the bits of openbench that actually worked), > i586 -> i686 was an improvement of 1% (Core2Duo) to 2% (Atom). Athlon64 was > essentially equal. > SPECCPU results showed similar. That sounds about right to me. -- 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
On Mon, Jun 15, 2009 at 5:48 PM, Jerry James wrote: > On Mon, Jun 15, 2009 at 3:42 PM, Bill Nottingham wrote: >> Not that it matters for Fedora, but I doubt many people are paying >> $whatever_the_price_of_RHEL_is to run on a 6, 7, 10-year old machine. And >> RHEL 5 only supports (base) i686 or greater already. > > You know, I haven't seen anybody object to the "i686" part yet. All > of the objections, as far as I have noticed, have been to the "+ SSE2" > part. I didn't raise that point because it was beaten pretty thoroughly in the past thread. The i686 vs i586 difference is cmov. Is dropping hardware worth this instruction? I suggested some benchmarking and demonstrated that it's a very small improvement for Theora. I'm not sure if anyone got around to testing freetype, firefox, or any of the other couple CPU heavy desktop apps. It would probably be most interesting to perform that test on the x86-only ATOM, since I can see CMOV being a bigger win on an in-order CPU. (I can't personally protest: I think all the x86 stuff I have has CMOV). -- 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
On Mon, Jun 15, 2009 at 1:53 PM, Bill Nottingham wrote: [snip] > - Faster and more consistent FP math by using SSE2 registers I doubt having consistently lower FP precision is anything many users are asking for. The few that do can usually take care of themselves. > - Allows for autovectorization by GCC where necessary Autovectorization is seldom effective, alas. SSE2 is part of the x86_64 basic arch. > - More clearly delineates our support set of targets, sticking true > to forwards innovation, not necessarily legacy support If thats the case why maintain x86 at all? Take your answer and now apply it to why fedora should maintain support for x86 CPUs without SSE2. In my case, this change would eliminate all of my x86 (not _64) systems save one pentium 4 box which is boxed up and turned off because its such a waste of power. The benefit of constraining x86 to SSE2 enabled chips is fairly small. The benefit of dropping x86 entirely would be much much greater. Of course, the cost is much greater too, but I believe that the latter still maintains the better cost/benefit ratio. Though I don't think either should be done. -- 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
On Fri, Jun 12, 2009 at 9:31 AM, Rahul Sundaram wrote: > On 06/12/2009 06:42 PM, Kyle McMartin wrote: > >> It's almost certainly attributable to the default install using audit. >> Roland and various others have done a lot of work improving things, but >> there is always going to be a per-syscall overhead to this kind of >> thing. A few extra usec a syscall adds up after a few hundred thousand >> calls... > > Is there a benefit to running audit by default? Is it worth the cost? What percentage of users do you think need even a small fraction of the raw http transaction rate fedora can provide? Obviously people do run a lot of CPU heavy CGIs, but since those generally spend time processing rather than just making syscalls they won't be as impacted as this. Anyone needing to handle thousands of small HTTP transactions per-second is doing something fairly specialized. They should be quite capable of performing whatever performance tweaks are required. For everyone else, and even many of the high performance shops, even a modest security gain is 'worth the cost' of a pretty substantial loss in peak http request rate. Even for small users the 'cost' of dealing with even one security breach in, say, 10 years would easily pay for a second CPU in the few cases where serving thousands of requests per second is material. Obviously you want to extract as much performance as possible, and don't want to take a loss for no gain. But if after fixing any bugs Fedora is slower because of a security feature then that needs to be touted as a *benefit* of fedora. From a marketing perspective people are more likely to believe advantages when you couple them with a negative in any case: "Furthermore, Fedora is more secure than other alternatives. Features like X, Y, and Z make Fedora robust against even unforeseen attacks. These features do result in a performance hit, for example 5,000 HTTP requests per second vs 10,000, the impact is negligible on normal workloads. Since some of the worlds largest websites only do 60,000 req/sec[1] (and have hundreds of servers), we think your time and security should take precedence. Of course, these security features can be disabled if your requirements dictate." [1] http://www.nedworks.org/~mark/reqstats/reqstats-daily.png -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: the end of life for flash player (HTML5)
On Mon, Jun 8, 2009 at 5:47 PM, Ben Boeckel wrote: > Nokia argued against it for patent worries. Probably worried > that if it did get done, some patent troll would come out of > the woodwork with some obscure patent and sue all OGG the > distributors. If you're going to play the numbers the MPEG codecs have a far worse track record of attracting litigation from trolls. The argument was actually more nuanced than that. It's more along the lines of "We're already committed to shipping H.264 and taking whatever surprise litigation risk there exists from that; even if the risk of negative surprises with Ogg/Theora is lower it would still be an addition to the risk we're already assuming, even evaluating the risks of alternatives has a cost to us, so the adoption of anything as a baseline other than what we're already using is not in our interests" Which isn't an insane argument, but it does have a simple solution: Sufficient market adoption will justify those costs. It's also positive that the only companies who have taken a clear public position against adopting Ogg/Theora as a baseline are companies whom receive payments for the use of MPEG-LA licensed technology. Those who merely pay to play are still shipping Theora. > Apple's biggest complaint was that hardware decoders for Theora > were far and few between (despite there being specs for it). > Their excuse was that H.264 has hardware implementations in > current hardware and handhelds don't have the power to do the > decoding in software. This isn't a correct knock in any case: Typical mobile devices (er, like the iphone) implement H.264 using the regular SIMD instruction sets of pretty boring general purpose CPUs or fairly common off the shelf DSPs (I.e. the c64x on TI OMAP). The existing handhelds very much do have the power to decode Theora in software, at least if someone would bother adding neon versions of the assembly optimized parts. (Although even my anaemic openmoko can *decode* Theora in real time with a totally unoptimized implementation; though display has bandwidth problems; most modern handhelds have far more horsepower.) Direct "hardware" support for non-trivial parts of the decode is something that seems to have been largely abandoned in the late 90s after everyone realized that this stuff changes too fast for economic silicon implementation. When people say hardware support these days usually mean "carefully optimized versions for my embedded processor" or possibly "use of hardware overlay and colorspace conversion" which works equally well for Theora. That said, there is a synthesizable VHDL implementation the back half of the the Theora decoder available: http://svn.xiph.org/trunk/theora-fpga/ (most of the rest of the decode process is more easily and effectively done on a general purpose CPU). So it's not even "there exists a spec" it's "there exists a hardware design needing only integration and manufacture". But as I said, generally true hardware implementation isn't done for decoders anymore. Even the $0.10 vorbis player on a chip is just software on a tiny DSP. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: the end of life for flash player (HTML5)
2009/6/8 Kelly Miller : > Thanks to Apple, that isn't going to be happening. Apple's pushing for the > required default video codec to be the aforementioned nonfree MPEG4/H.264 > codec, and they don't seem to care whether it can be shipped by anybody > else. Perhaps pedantry but for the sake of accuracy: Some of the patent holders in the MPEG-LA patent pool (Apple and Nokia) pushed hard for there to be no royalty-free baseline recommended in the standard. I'm not aware of anyone, Apple included, pushing for H.264 in the standard since the adoption of an encumbered format as formal formal default is simply a complete non-starter. What Apple has done is ship systems which can only play H.264 using the video tag out of the box. You could accurately accuse Apple of pushing for H.264 as a defacto standard, but not a "required default". For desktop Safari usage Ogg/Theora+Vorbis support can be added by installing the XiphQT codec package. While requiring an install was unfortunate flash itself is an existence proof that required installations don't make wide adoption impossible. The apple desktops also have decent Java support and websites can fall back to java playback. (Theoretically Flash playback of Ogg/Theora is also possible now; but the intersection of Flash gurus and free software developers is nearly the empty set) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: the end of life for flash player (HTML5)
On Thu, Jun 4, 2009 at 5:47 PM, Kevin Kofler wrote: [snip] > the way there though. It's NOT good that they're hardcoding a browser check > for only Firefox though, Don't worry, plenty of people have pointed out that it isn't the way to go. HTML 5 video provides the right tools for querying for support for not only the video tag itself but for supported codecs. Some of that wasn't there in the earlier firefox betas, which probably encouraged the use of simple useragent based checking. It's there now. > the latest Arora which does support HTML 5 video > is not recognized, that's broken!) The string "video" doesn't occur anywhere in the current Arora git. Can you point me to more information? In testing I find that a couple of problems: (1) it appears the it doesn't begin until it has completely transferred the file(?) (2) audio plays but video does not (3) seeking does nothing Here is a simple example that queries the browser for support, and if HTML 5 video isn't supported it falls back to using the Java player: http://www.celt-codec.org/presentations/ Thanks! -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why not to create Fedora-us and Fedora-non-us branches?
On Tue, May 26, 2009 at 3:17 PM, Frank Murphy wrote: > Bill Nottingham wrote: >> >> Peter Lemenkov (lemen...@gmail.com) said: ... what exactly are you trying >> to accomplish? >> >> Make it legal to ship MP3 code? Sorry, those are patented in Europe as >> well. >> >> > > Patents are *currently* illegal in Europe, (though they may be granted). > The patents offices being self-funding and all that. > > http://en.wikipedia.org/wiki/Software_patents_under_the_European_Patent_Convention > "Article 52" Codec patents are generally not 'software patents' in the common patent-speak meaning of the words. A typical (well written) codec patent will make little or no mention of computer software. Instead they speak of specific useful transformations of information in mechanical terms as well as machine embodiments. This puts them largely outside of the domain of what is normally discussed in the content of "software patents" (which, have recently been written abstractly without any real reference to any machine or mechanical process). The bulk of codec patent holders are European companies (I.e. Fraunhofer, Nokia, etc). The collection of royalties for codecs is a multi-billion dollar a year industry. There are many well funded companies spending considerable amounts of money licensing codecs, even on products which they only intend to market in Europe. On that basis, I think it's safe to conclude that there is more to the situation than you are suggesting. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
