Re: RFE: Never, ever steal focus.
On Wed, Jan 6, 2010 at 10:00 AM, nodata l...@nodata.co.uk 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: RFE: Never, ever steal focus.
On Wed, Jan 6, 2010 at 1:08 PM, Adam Jackson a...@redhat.com 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 l...@nodata.co.uk 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 a...@redhat.com 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: packaging a static library
On Wed, Dec 30, 2009 at 2:05 AM, Ralf Corsepius rc040...@freenet.de 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 ja...@redhat.com 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 skvi...@fedoraproject.org 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 p...@dishone.st 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 Tue, Dec 8, 2009 at 12:47 PM, Ralf Corsepius rc040...@freenet.de 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: Video: 5 Fun Things in Fedora 12
2009/11/30 Máirín Duffy mai...@linuxgrrl.com: Hi, I just posted a 15 minute 'fun things in Fedora' video. It's on YouTube - I tried blip.tv and the upload kept stalling, so I split the video in to and got it up on YouTube just so I could make it available more quickly. http://mairin.wordpress.com/2009/11/30/5-fun-things-in-fedora-12-video/ Hope you enjoy, Unfortunately, one of the five fun things is not watching the five fun things videos in a stock fedora install. The site requires flash. … If anyone doing fedora marketing wants to put up videos that don't require proprietary software to view, please feel free to drop me an email. I'd be glad to help, or if I'm too busy I can connect you with someone else willing and able to help. Supporting open video technology isn't especially hard, and it doesn't require losing compatibility with people still on proprietary platforms. ... though it is a little more involved than just dropping the videos on youtube. -- Fedora-marketing-list mailing list Fedora-marketing-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-marketing-list
Re: Video: 5 Fun Things in Fedora 12
2009/11/30 Máirín Duffy mai...@linuxgrrl.com: To be fair, the video is aimed at people who are not yet using Fedora. Understood. But it's poor sales for fedora when you use an approach which works less well for Fedora than it does for windows. Obviously excluding non-linux users is not an option. The site requires flash. … If anyone doing fedora marketing wants to put up videos that don't require proprietary software to view, please feel free to drop me an email. I'd be glad to help, or if I'm too busy I can connect you with someone else willing and able to help. Supporting open video technology isn't especially hard, and it doesn't require losing compatibility with people still on proprietary platforms. ... though it is a little more involved than just dropping the videos on youtube. I hope you didn't mean to hurt my feelings with your message because it could certainly be interpreted that way. ! No, I didn't. We all have important things to do with our time, there is no crime in not taking some step, even an easy one, when we think doing so will conserve some resources. I had no idea what your intentions were, only that the result required flash. I assumed that you simply were unaware of the issue and was trying to offer to help out, rather than just complaining that it ought to be done some other way. The point of saying that its easy is that I simply wanted to make the point that I'm not suggesting you undertake a super-human effort. Obviously I failed to account for the difficulties that you already had! As noted, the videos were created in Fedora 12 using PiTiVi. I attempted to encode them 3 times, for a total of 3 hours rendering time (I let the last one render overnight last night since I had wasted hours already) using an Ogg container, Theora video codecs, and Vorbis Celt sound codecs. Every single time, the video rendered completely out-of-sync. Even though gstreamer was used to render it, it refused to play in gstreamer players, only playing in mplayer. CELT? Celt is completely inapplicable for this use case. PiTiVi shouldn't be offering it. This bug sounds vaguely like what you experienced: https://bugzilla.gnome.org/show_bug.cgi?id=600215 One possible work around would be to render to high quality MJPEG in AVI (which is effectively lossless) plus PCM audio then use a tool like ffmpeg to Theora to transcode. [snip] You can ask anyone who knows me - I am insanely religious about software freedom and codec freedom. After spending hours filming, editing, rendering, and uploading these video (I would guesstimate about 12 hours total, during my holiday vacation time) I became impatient and just wanted to share the video instead of putting myself through continued pain trying to do it the right way. Can you help me get this working with ogg blip.tv? Is there a bug in PiTiVi or F12's theora / ogg / celt / vorbis encoders that resulted in my having such a poor experience? What do you suggest? I used all of the default settings in PiTiVi as I wasn't sure what encoder settings to tweak (and at ~1 hour rendering time per attempt making wild guesses would not be a prudent usage of my time.) There must be a bug, because the encoders alone are no less speedy than what you ended up using, at least not in any material way. I've never used pitivi before, but I'll install it and attempt to reproduce your issue. Could you possibly make your project file available to me if I'm unable to reproduce this with a trivial test case? -- Fedora-marketing-list mailing list Fedora-marketing-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-marketing-list
Re: memset bugs.
On Fri, Nov 27, 2009 at 1:26 AM, Roopesh Majeti roopesh.maj...@gmail.com 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: PackageKit policy: background and plans
On Mon, Nov 23, 2009 at 9:37 AM, Krzysztof Halasa k...@pm.waw.pl wrote: Kevin Kofler kevin.kof...@chello.at 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: PackageKit policy: background and plans
On Mon, Nov 23, 2009 at 2:13 PM, Peter Jones pjo...@redhat.com 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 k...@pm.waw.pl 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 6:43 PM, Jesse Keating jkeat...@j2solutions.net 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: Security testing: need for a security policy, and a security-critical package process
On Mon, Nov 23, 2009 at 6:39 PM, Jesse Keating jkeat...@redhat.com 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: Security testing: need for a security policy, and a security-critical package process
On Mon, Nov 23, 2009 at 9:10 PM, Adam Williamson awill...@redhat.com 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: F12: where did window properties go?
2009/11/20 Pádraig Brady p...@draigbrady.com: 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 ceme...@u.washington.edu 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: Promoting i386 version over x86_64?
On Wed, Nov 18, 2009 at 9:13 PM, King InuYasha ngomp...@gmail.com 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: Promoting i386 version over x86_64?
On Wed, Nov 18, 2009 at 1:55 AM, Josephine Tannhäuser josephine.tannhau...@googlemail.com wrote: 2009/11/18, Gregory Maxwell gmaxw...@gmail.com: 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 jgar...@pobox.com 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
Re: Security policy oversight needed?
On Wed, Nov 18, 2009 at 7:37 PM, Mike McGrath mmcgr...@redhat.com 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
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 is about to happen
On Tue, Sep 29, 2009 at 9:42 PM, Chris Adams cmad...@hiwaay.net wrote: Once upon a time, Steve Dickson ste...@redhat.com 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 ktdre...@ktdreyer.com 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 michael.silva...@gmail.com wrote: On Tue, Sep 8, 2009 at 9:46 PM, Alexandre Oliva aol...@redhat.com 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 Millermaxamill...@gmail.com 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 9:40 AM, Bastien Nocerabnoc...@redhat.com wrote: On Sun, 2009-08-16 at 18:02 -0400, Gregory Maxwell wrote: snip 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 Mon, Aug 17, 2009 at 6:31 PM, Mathieu Bridon (bochecha)boche...@fedoraproject.org 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
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: Empathy default in F12?
On Sun, Aug 16, 2009 at 3:40 AM, Rahul Sundaramsunda...@fedoraproject.org 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
Re: Lower Process Capabilities
On Wed, Jul 29, 2009 at 9:32 AM, Stephen Smalleys...@tycho.nsa.gov 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 Adamscmad...@hiwaay.net wrote: Once upon a time, Tom spot Callaway tcall...@redhat.com 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 Grubbsgr...@redhat.com 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 McGrathrol...@redhat.com 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: Time for 2.6.30 in F-11?
On Sat, Jul 4, 2009 at 6:40 AM, Bojan Smojverbo...@rexursive.com 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 Eissererlinuxhi...@gmail.com 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
On Mon, Jun 15, 2009 at 1:53 PM, Bill Nottinghamnott...@redhat.com 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 Sundaramsunda...@fedoraproject.org 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)
2009/6/8 Kelly Miller lightsolphoe...@gmail.com: 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 Mon, Jun 8, 2009 at 5:47 PM, Ben Boeckelmaths...@gmail.com 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)
On Thu, Jun 4, 2009 at 5:47 PM, Kevin Kofler kevin.kof...@chello.at 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 frankl...@gmail.com 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
Re: FLOSS Multimedia Support in Fedora
2009/2/8 Martin Sourada martin.sour...@gmail.com: Hi, sorry for cross-posting but I wanted all interested parties to not miss this email ;-) There has been some media related discussion in the -devel list and one of the points I have taken form it is that we should promote FLOSS multimedia and don't blame others for doing it (even if it's done in a not ideal way)... Now, the problem is that the actual support of these in our system is crappy. I don't think that is the correct take-away. Everything works in gstreamer. The correct conclusion is that support for free formats in media infrastructure primarily designed, built, and maintained for non-free formats currently stinks for the free stuff. It's another indicator that Fedora should discontinue shipping these non-free media focused infrastructures rather than continuing to patch the non-free stuff out. Of course, support for the free formats should be fixed in that, but that really shouldn't be a Fedora issue. [snip] Also feel free to reference upstream bugs about the mentioned issues. The videos used for reference testing are available at my fedora people page [2]. It's probably important to have a more complete test. Right now you're using what is probably the simplest possible test: Just a regular file with video in it. That case is important, but it is also important to test more complicated cases, such as tests including audio, subtitles, oddball muxing, and chaining. It's no good if a player works for your simple case but crashes as soon as someone gives it a subtitled input. It would also be good to try all mixtures of (FLAC|Speex|Vorbis) * (Theora|Dirac) * (w/ | w/o subtitles) * (OGG|Mkv) which is 24 combinations by itself. (although I don't know how worthwhile the Mkv testing is— as far as I can tell it's mostly unseen outside of the movie piracy / anime fansub sites; and at those its usually used with H264) For Ogg it's also important to test seeking, because some applications have historically gotten it wrong. Seeking with Ogg should be done with Newton–Raphson (ideally) or bisection. There have been broken applications (ffmpeg in the past; for example) which seek in Ogg with a linear scan starting at the file beginning, which is quite intolerable for any reasonably large file. Unfortunately this test needs a large (~hundreds of MBytes) test file, so it's hard to distribute a test. Some of the proprietary-codecs focused tools provide their own home grown implementations of the codecs (i.e. ffmpeg). These often do not implement the full spec, so its important to test their behaviour. Here are some resources for doing that: Some good tests for Ogg/Theora: http://v2v.cc/~j/theora_testsuite/ There are test vectors for Vorbis here: http://people.xiph.org/~xiphmont/test-vectors/vorbis/ ___ Fedora-art-list mailing list Fedora-art-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-art-list
Re: Infinite Freedom???
On 6/18/07, Rahul Sundaram [EMAIL PROTECTED] wrote: http://fedoraproject.org/wiki/Packaging/Guidelines#head-adf31c383612aac313719f7b4f8167b7dcf245d2 FSF position on this seems to be rather inconsistent to me since they have endorsed certain distributions as Free even if they include such firmware in the kernel inherited from upstream. They have? Where? As far as I know the only GNU/Linux distribution currently endorsed by the FSF is gNewSense. gNewSense ships a patched kernel which removes all the blobs. If you are aware of anything in gNewSense which isn't consistent with the position that user loadable firmware needs to be free, please let them know.. I'm sure they will be glad to fix it. I think it is past due for Fedora to take at least a half-step and segregate the non-free firmware into separate packages which can be excluded at install time. Doing so will not win Fedora any credit from the FSF, but it will do nothing to harm the standing hardware compatibility and it will enable those who care and who want to avoid that hardware to do so. Increasing awareness is good for everyone. Really, I think it's quite unfortunate that the 'most free'/FSF approved' distro is based on Ubuntu... a distribution which hasn't a fraction of Fedora's commitment to freedom. .. but it is what it is. -- Fedora-marketing-list mailing list Fedora-marketing-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-marketing-list
Re: ESR gives up on Fedora
On 2/21/07, Francesco Ugolini [EMAIL PROTECTED] wrote: Read this article: http://enterprise.linux.com/enterprise/07/02/21/1340237.shtml?tid=23tid=12 . I think we have to reflect on this pamphlet, and we have to answer him, directly or indirectly. I hope that some developers can help us understand deeper the objections and work together to change the situation. Before I loaded the URL I knew he would be complaining because we have not accepted proprietary and patent encumbered formats. I think the fact that he still harps on that point diminishes the credibility of the rest of his arguments. I am personally quite glad that Fedora has a long term vision of a world of truly free software, one which can't exist if in order to get useful things done we must load up on non-free formats. Non-free formats carry a high price even if they cost no money directly. It is unfortunate that a more long term perspective seems irreconcilable with ESR's short term wishes for desktop domination. -- Fedora-marketing-list mailing list Fedora-marketing-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-marketing-list
Re: fedora logo on wikipedia
On 4/26/06, Nicu Buculei [EMAIL PROTECTED] wrote: It was not clear from the initial message about which image you are talking about, I modified it: http://en.wikipedia.org/wiki/Image:Fedora_project_organization.png Anyway, that chart could use a complete revamp, it is made in 2004 and illustrate the structure of Fedora at that time (it has no mention of Extras, Legacy). I would gladly do a new chart, but I need help of figuring which are all the entities and the relations between them. Make sure you upload the next one as SVG. :) -- Fedora-marketing-list mailing list Fedora-marketing-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-marketing-list
Re: Active Vs Passive was..Why getting Shared Media rolling is important
On 4/14/06, Karlie Robinson [EMAIL PROTECTED] wrote: [snip] little kids using Fedora/Linux means to the big picture and to the RH bottom line in years to come. If my marketing ideas aren't helpful to you here, I won't waste any more of your time. I think there are some small scale related project out there... for example, trying to get python made the selected programming language in beginning computer science classes in highschools.There should be a lot of opportunity for collaboration on this effort. -- Fedora-marketing-list mailing list Fedora-marketing-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-marketing-list
Re: Free/Open Source fonts
On 9/21/05, Peter Jones [EMAIL PROTECTED] wrote: That's just not the case. There's a reason Ariel has very slight differences from Helvetica, and it's not that MS didn't think Helvetica looked right. It's also not that they couldn't figure out how to copy it. Taking a copyright-protected font for the artwork will not conflict the open source values of Fedora. I think it's reasonable to use a copyrighted font, yes. I don't.. but beyond that, do we really want that font? I showed the proposed fedora logo to three folks in my little local fedora-using community, and all three of them made a negative comment about the font, and I was specifically told that the one used on the fedora desktop logo looked nicer. This surprised me somewhat, because I hadn't even noticed the font, ... I was too busy trying to come up with an explanation of why I felt the bubble shape felt wrong. In general I don't know what we're saying about the usefulness of the infinite freedom desktop if you can't even reproduce its logo with a free font. :) Since the characters can just be distributed as paths, perhaps it's not a big issue, but I'd presume that it may be desirable to have the sub-projects text in the same typeface, so the use of a non-free font might even present practical issues. -- Fedora-marketing-list mailing list Fedora-marketing-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-marketing-list
