Re: packaging a static library
On Tue, 2009-12-29 at 14:41 +0100, Ralf Corsepius wrote: > On 12/29/2009 11:52 AM, Daniel Drake wrote: > > OLPC has previously had a specific version of tomcrypt/tommath > > profesionally audited for security reasons. So we obviously want to > > stick with that version. > > > > A few packages we have in Fedora currently use this frozen, audited > > version - we do so by shipping duplicate copies of that source code > > within the individual packages, rather than linking against the dynamic > > systemwide equivalents. > > Or am I going too far against common packaging practice at this point? > Yes. You are outsmarting yourselves and not doing good to other users of > the libraries, IMO. I think the argument could go both ways. In the case of OLPC, they're providing Open Source pieces that are similar to things like the TPM technologies in other systems. If a certain major PC chip manufacturer decided to release all of the design and code schematics for their TPM chips, the community would probably praise them...and then wonder what the potential could be for a bad library release to undermine them. > If all users of the library were using the same, identical shared > versions, everybody would benefit from your "auditing", maintainers > would benefit from "issues being fixed" at one place, users would > benefit from you not shipping statically linked packages. 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. Jon. -- 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, 2009-12-16 at 16:30 -0500, Przemek Klosowski wrote: > HOWEVER, just because Windows suck doesn't mean that Linux should suck > too. My own preference would be a more discriminating dialog > that offers three possibilities: 'do nothing', 'bounce the > service/application' and 'reboot'. Yup, +1 Jon. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 1 complete
On Tue, 2009-12-15 at 12:35 -0800, Toshio Kuratomi wrote: > master makes a lot of sense from a git perspective. devel (or rawhide) > makes sense from what we actually call the code that that branch eventually > makes. A symlink might alleviate the confusion but it could also add to it. > (For instance, I was operating in the kernel/devel branch but when I want to > git checkout -b devel git gives me a strange error.) > > I don't see a clear answer for what's best here, yet. :-( I think those of us who follow rawhide will quickly realize the change in naming (ok maybe a symbol is vaguely useful, and also needs to be explained somewhere when people inevitably ask) and move on. Conversely, someone who is new or hasn't followed "devel" branches before should just be able to use git how they have elsewhere and it should work. Summary: easier to make life easier for new developers. Jon. -- 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 Tue, 2009-12-15 at 12:01 -0600, Otto Haliburton wrote: > I am not sure what the argument is, factually there are packages that have > files open, locks and etc. that need to be shutdown to update, if they are > running and you replace the executable, doesn't mean that the memory image > is replaced. It is quicker and simpler to just reboot, also the list of the > packages that cause you to reboot is probably longer than the ones that are > flagged. I think that a reboot should be made whether necessary or not, > clears up a lot of grief. Wow. That's twice today that the suggestion of forcing the user to reboot whether they like it or not has been made. What a long way we've come since the early days :) Personally, I think a dialog box is pretty simple for most users (no forcing, just persuasion), and allows those who know what they're doing to ignore it. And obviously reducing the number of times you ask to just absolute necessity is a win-win. But please, no more forced reboot suggestions. This isn't MSFT. Jon. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Tue, 2009-12-15 at 16:54 +, Paul Jakma wrote: > On Mon, 14 Dec 2009, Chris Adams wrote: > > > Have you actually shown any concrete benefits, or has it all just been > > hand-waving? > > Well, the benefits were already known from the introduction of 64bit > systems in the mid 90s. E.g. a rule of thumb with AXP systems was > that they required at least 30% odd more RAM, compared to other Unix > systems (either 32bit, or 32-userspace/64kernel systems - which is > what most of the other Unix RISC vendors went with when they went to > 64bit CPUs). But again, Apples to Oranges. x86_64 (we should formally call it "Intel 64", or similar, since I'm not aware of x86_64 having a formal blessing) doesn't have the fixed instruction width that you get on most RISC ISAs. Not that any of it matters when we're already creeping up the minimum memory requirements over time and not so interested in older hardware anyway (e.g. recent i586/i686 changes). I know not everyone is living in the US, but here at least someone drew my attention to a ludicrously cheap laptop on sale last weekend that also had 3GB of RAM installed. I think we should treat it like migrating to i686 and once everyone has a 64-bit capable (x86) CPU just plan to do a gradual migration over. Jon. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FUDConF13 videos
On Tue, 2009-12-15 at 09:31 -0600, Matt Domsch wrote: > If anyone else has video or audio from this or other Fedora events > you'd care to share, please contact me and I'll help you get it into > proper ogg format, tagged, and posted to Fedora Infrastructure servers > for distribution. You rock :) Jon. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 1 complete
On Mon, 2009-12-14 at 20:22 -0800, Jesse Keating wrote: > On Mon, 2009-12-14 at 19:21 -0800, Jesse Keating wrote: > > git clone git://publictest5.fedoraproject.org/git/pkgs/kernel > > This was the wrong path: > > git clone git://publictest5.fedoraproject.org/pkgs/kernel Can you explain the tags a little Jesse? e.g. F-12-split F-12-start I have absolutely no interest in the idea of doing one giant tree btw, though I doubt that will ever get serious traction :) Also, on the subject of branches, can you include a summary of branches too? Jon. -- 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 Sun, 2009-12-13 at 16:19 -0600, Chris Adams wrote: > Once upon a time, Jon Masters said: > > Indeed. Paul, take a look at the Intel 64 ISA and you'll see it's a very > > different beast. Intel fixed a lot of the issues with the (more than 20 > > year old really x86 ISA) > > That would be AMD that fixed it, not Intel. Intel tried to push > everybody to a new architecture (Itanium), while AMD revised and > extended i386 to 64 bits. After Itanium failed to catch on in the > marketplace, Intel had to copy AMD's work. That's presumptuous and unfair. Sure, without AMD and others we'd likely be on Itanium (which I actually quite like as an architecture) but Intel 64 isn't just some copy-and-paste effort either. Besides, whatever the history we shouldn't be encouraging people to use plain older x86. Jon. -- 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 Sun, 2009-12-13 at 13:53 -0500, Tom Lane wrote: > Paul Jakma writes: > > On Wed, 18 Nov 2009, Roland McGrath wrote: > >> x86 is unlike other architectures because 64-bit also has twice as > >> many registers as 32-bit. So you get to trade off the benefits of > >> register allocation across more registers against the memory/cache > >> footprint of 64-bit pointers. > > > For what percentage of code is that an appreciable advantage? > > Pretty much everything, actually. The x86 ISA completely sucks. Indeed. Paul, take a look at the Intel 64 ISA and you'll see it's a very different beast. Intel fixed a lot of the issues with the (more than 20 year old really x86 ISA) and it's not simply a doubling of memory footprint because variable width instructions are used in the first place, and continue to be used in the newer ISA upgrade. Personally, I think anyone running i386 on x86_64 who isn't doing some kind of testing under KVM or similar is completely wasting their computing resources and should receive a free copy of the Intel documentation for the holidays ;) Jon. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: upstart-0.6.3 in rawhide, tomorrow 2009-12-10
On Thu, 2009-12-10 at 15:32 -0500, Bill Nottingham wrote: > This is done by the ACTIVE_CONSOLES parameter in /etc/sysconfig/init; > the default value is "/dev/tty/[1-6]", which means that mingetty > will be started on ttys 1 through 6. Shell globs are accepted. Nice. Great for VMs where you don't even need more than one. Jon. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why pavucontrol is not installed by default?
On Wed, 2009-12-09 at 02:44 -0500, Orcan Ogetbil wrote: > On Tue, Dec 8, 2009 at 2:05 PM, Jon Masters wrote: > > > > The new gnome-volume-control is so cut-down it's not useful to me. In > > the quest to be more Mac-like in removing mixer controls (and not even > > having any obvious "advanced" mode), I now have a choice of no audio or > > having full volume LFE output *and* whatever mixer level I have set for > > the master output. alsamixer works fine, but then I can't use the volume > > sliders on my desktop and it gets rather awkward. > Sadly, they consider this bug as an enhancement. I have had friends > who had the same hardware with me but they were using another OS. I > remember them being jealous because I had so much more control over > same sound card. It made me proud at the time. I fear that this > disease of oversimplifying will make us forget why we are using Linux. All paranoia and ranting aside, there is some truth to this. There is a definite trend in the Linux community to want to cater to the lowest common denominator by being more Mac/Windows-esque. I put up with it because I can usually ignore it (I refuse on principal to use a GUI to copy a file, for example, but that's just me being weird), but I don't see the harm in hiding the advanced stuff under a checkbox - the advanced mixer stuff is still there underneath after all. Jon. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why pavucontrol is not installed by default?
On Tue, 2009-12-08 at 21:45 +, Bastien Nocera wrote: > On Tue, 2009-12-08 at 14:05 -0500, Jon Masters wrote: > > The new gnome-volume-control is so cut-down it's not useful to me. In > > the quest to be more Mac-like in removing mixer controls > > No, it's in a quest of providing *solutions* to user's problems, and not > blindly showing everything the software and the hardware can do. I couldn't disagree more strongly. As a Linux user, I want the "show me everything" option. I don't care if I have to check a box to do it, but I want to see all the knobs and dials. And I at least expect not to have what I'm doing with alsamixer interfered with by the other tools. Jon. -- 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, 2009-12-08 at 18:41 +0100, drago01 wrote: > On Tue, Dec 8, 2009 at 5:27 PM, Rallias UberNerd > > But wouldn't it be better to use 32 bit when less then 4 GB of ram is > > present? > > no, using x86_64 means more registers, sse2 as default floating point > instruction set, better calling convention (register passing vs. > stack) or in other words in most cases faster code. Indeed. Intel 64 (x86_64) is really a different animal. More registers, different behaviors, and not just an LP64 version of what was there before. I've spent the last few weeks finally reading the x86_64 docs on my Kindle and really look forward to the older stuff just dying. Jon. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why pavucontrol is not installed by default?
On Tue, 2009-12-08 at 12:59 +0100, Tomasz Torcz wrote: > On Tue, Dec 08, 2009 at 09:51:55AM -0200, Paulo Cavalcanti wrote: > > I did a clean install of Fedora 12 and realized > > that pavucontrol was not installed by default. > > I have two sound cards and I only got sound when > > I manually installed pavucontrol and used it. > > Any reason? > pavucontrol is regarded as advance tool, but also partly > obsolete. Current gnome-volume-control superseded most of > its functionality: controlling different streams volume, > switching profile, outputs, fallback devices. The new gnome-volume-control is so cut-down it's not useful to me. In the quest to be more Mac-like in removing mixer controls (and not even having any obvious "advanced" mode), I now have a choice of no audio or having full volume LFE output *and* whatever mixer level I have set for the master output. alsamixer works fine, but then I can't use the volume sliders on my desktop and it gets rather awkward. I still pine for the days of isapnpdump when I had to do all the heavy lifting by hand, but it worked 100% of the time. Jon. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Notification of uploads to the lookaside cache
On Sat, 2009-11-21 at 19:34 -0500, Jon Stanley wrote: > As part of our ever vigilant stance towards security around our > packaging process, we have added a new feature to upload.cgi (which > accepts file uploads into the lookaside cache) which will email the > package owner (-ow...@fedoraproject.org, specifically) and > fedora-extras-comm...@redhat.com whenever a file is uploaded to the > lookaside cache. Previously this was a big black box and an area of > concern. Awesome. Thanks a whole bunch! Jon. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora with Universal Binaries?
On Thu, 2009-10-22 at 12:28 -0500, King InuYasha wrote: > http://icculus.org/fatelf/ > > > There is even a proof of concept VM of Ubuntu 9.04 that has both > 32-bit and 64-bit kernels and all the apps compiled as FatELF binaries Except, they're not really ELF binaries. ELF doesn't allow you to do both at the same time in the headers, so this adds a new header and is essentially an encapsulation for other ELF files. Thus, a kernel patch is required and it would be some time before all kernels supported it. I'm not against the notion of this...but I think some of the usual suspects need to get involved in standardizing such an ELF hack. (You might be able to do something with binfmt_misc as a hack) Jon. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: The future of "rawhide" (was [Fwd: Re: "What is the Fedora Project?"])
On Thu, 2009-10-22 at 09:50 -0700, Jesse Keating wrote: > This is my vision on how to accomplish both a always active development > stream, and a more stable pending release stream, keeping everybody > happy. Want to help? I'll be at FUDCon Toronto discussing roadblocks > to this vision and discussing why this vision sucks if anybody thinks > that it does. Or just find me on IRC/email if you want to chat about > it. Not a bad idea. In all honesty, I find rawhide is rarely fully installable out of the "box" anyway...this isn't a grumble! I think it's better to embrace reality and have multiple trees, though I am interested in whether that pending release couldn't also one day have a counterpart that had more longevity - a "testing" release (not the same as the "testing" that we currently have through updates) :) Jon. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Bug reporting URL field in packages
On Tue, 2009-10-06 at 10:43 -0700, Jesse Keating wrote: > So I guess the real question is do we want our packages built in koji to > assume a bug URL of fedora, even when used in downstream projects? I think that's a giant assumption - if the maintainer didn't put that URL in the package themselves, what makes you think automatically putting it in there is going to achieve anything different? ;) I advocate letting people choose for themselves. Jon. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [PATCH 3/3] dracut has initrd-generic- instead of initrd- (#519185)
On Fri, 2009-09-04 at 17:27 +0200, Tomasz Torcz wrote: > On Fri, Sep 04, 2009 at 11:14:43AM -0400, Dave Jones wrote: > > On Fri, Sep 04, 2009 at 10:53:19AM -0400, Jon Masters wrote: > > > > > The problem I have is that some folks want to include additional drivers > > > into their initrd. > > > > examples please. > > Out-of-tree modules: pvscsi, vmxnet (for VMWare). Generally > stuff frowned-upon. BTW, I believe changing Plymouth theme require > regeneration of initrd. Yeah. Most of it is "evil" stuff. But I am bringing it up because nobody else has - the fact of the matter is that there are lots of third party drivers and tools that are going to break if they cannot regenerate the initrd. I think it's acceptable for Fedora to completely loathe and distrust binary drivers, but I really don't think it's acceptable to actively prevent someone from using them if they would like to. What'll happen is that lots of people will start building per-kernel initrd images again, and third party websites will talk about how to "work around" dracut defaults rather than embracing them because they won't have an option for a generated, portable image. Jon. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [PATCH 3/3] dracut has initrd-generic- instead of initrd- (#519185)
On Thu, 2009-09-03 at 11:05 -0400, Tom "spot" Callaway wrote: > On 09/03/2009 10:57 AM, Hans de Goede wrote: > > It really is like having to support gentoo, versus having to support a > > distro using pre build packages. And I would really like to move to the > > having to > > support a pre-build package model for the initrd. ...but not for drivers ;) It's funny how sometimes building binaries makes life easier for users, but other times it's horribly wrong :) > The problem is this: > > The kernel binary RPM contains this pre-built initrd. The kernel source > RPM does not contain the sources necessary to make this pre-built initrd. > > This makes me rather uncomfortable from a Licensing perspective. I'm > also concerned about it from a security perspective, as these binaries > are very likely to be overlooked when security updates are pushed. The problem I have is that some folks want to include additional drivers into their initrd. What are we going to recommend for this case? I know one can still build a kernel-specific version, but I fear that this results in many users having no benefit of the generic image because it'll not contain the additional bits they needed to add. Can't we at least ensure all deps are available on the system by default, so that users *can* rebuild? Jon. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [PATCH 3/3] dracut has initrd-generic- instead of initrd- (#519185)
On Wed, 2009-08-26 at 11:45 +0200, Hans de Goede wrote: > dracut using kernel come with a prebuild initrd-generic- instead > of initrd-, so if we fail to find /boot/initrd-.img, check > for /boot/initrd-generic-.img instead. I've done things this way > so that if we ever need to generate system specific (so non generic) initrd's > for some reason the code will stay working. Is the plan to basically migrate to entirely pre-built "generic" "initrd" initramfs pre-built image files then? Will we even be generating the kernel specific stuff in the future? Jon. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: popcorn sound with kernel 2.6.29.6
On Fri, 2009-08-21 at 21:41 +0200, Chitlesh GOORAH wrote: > I am experiencing some random popcorn sound while playing mp3 and > while assisting flash based webinars with the kernel-2.6.29.6. Can you reproduce if for example running "pasuspender totem " ? Jon. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Another linux kernel NULL pointer vulnerability ( exploit here )
On Fri, 2009-08-14 at 21:23 +0200, Christoph Wickert wrote: > Am Freitag, den 14.08.2009, 14:39 -0300 schrieb Itamar Reis Peixoto: > > Hello guy's > > > > for the people who don't have updated the kernel. > > I'm running kernel-2.6.29.6-217.2.3.fc11.x86_64 and this one is not > supposed to be fixed, however... > > > http://grsecurity.net/%7Espender/wunderbar_emporium.tgz > > ... it doesn't work here. Although the author claims it's not stopped by > SELinux (he even mentions Dan by name), SELinux one more time saves the > world: FYI I saw a real life attempt to exploit this over the weekend on a machine of mine where someone had found a PHP exploit. Fortunately, I had already upgraded the kernel and their rootkit attempt failed, however it's worth emphasizing that this is certainly out there. I have more information on the rootkit they used for legitimate security researchers who are interested in the issue. Jon. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Annoying kmemleak scans
On Tue, 2009-08-11 at 16:53 +0200, Fabian Deutsch wrote: > Starting with F11 kmemleak is part of the kernel. It is quite annoying > when every couple of minutes kmemleak starts to scan for memeleak within > the kernel. I do not see any point in doing this on desktop machines, so > is there a chance of disabling it by default? > It eats quite much of battery when running F11 on a laptop. Having kmemleak turned on at least in rawhide is a good thing. As for a released kernel, I'd agree that the kthread Catalin uses probably affects battery life. Of course you could disable it, but I suppose you mentioned this because of the default - hence, copying fedora-kernel so that someone can actually answer your question. Jon. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: mcelog, Is it dead\dying?
On Fri, 2009-07-31 at 08:52 +0100, Frank Murphy wrote: > Bug: 2009 > https://bugzilla.redhat.com/show_bug.cgi?id=507026 This is a side effect of me having two bugzilla accounts and needing to periodically sync them. Sorry I missed it, I'm on the list now. Also, I will once again try moving my bugzilla email. I prefer having @jonmasters.org for "non-RH" stuff like this but that doesn't actually work well in practice so I'll probably have to have things all under one account in future to avoid the need to keep synching by hand. Jon. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Rebootless Installer
On Tue, 2009-07-14 at 02:04 -0600, Douglas McClendon wrote: > Can you spare 50 or 100K? If you can spare 100K/700M in the forthcoming > Fedora-12 LiveCD, I can provide you with a rebootless installation > experience. > > http://fedoraproject.org/wiki/Features/RebootlessInstaller > > The short story is that you boot the LiveCD/USB, run the installation, > and then, instead of rebooting into the installed OS, you are already > looking at and using it. I think this needs a lot more discussion before it's considered. As others have said, rebooting is often necessary with our current modus operandi and whether we like it or not, it is consistent. Besides, most people don't mind an *expected* reboot after they do a major upgrade. Me, I normally set aside a weekend for Fedora major upgrades anyway. It's not something I'm inclined to do without some planned downtime, since the last two times I've had an hour of fixing to do afterward. Jon. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: readline update?
On Fri, 2009-07-03 at 12:27 +0200, Miroslav Lichvar wrote: > bti-015-1.fc11 > lvm2-2.02.48-1.fc12 I mailed Greg and Alasdair about these just so they know. Jon. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Dracut now has a wiki page in the Fedora wiki...
On Fri, 2009-07-03 at 15:00 -0500, Bruno Wolff III wrote: > On Fri, Jul 03, 2009 at 10:43:34 +0100, > Adam Williamson wrote: > > > > but it's actually a lot less trouble to just do: > > > > "tar xf dracut-$version.tar.bz2" > > > > which auto-detects the archive type. It's much easier to just let it be > > handled by autodetection, and only bother specifying the archive type > > manually if the autodetection trips up. > > How long has that feature been there? I'm as amused as you are that I didn't know about that either (my guess is it's been there a while and we're just all stuck in our ways). At least we're not stuck in the 1970s and willing to move with the times - a lot of people still like to use pipes of the individual utilities ;) Jon. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: KSplice in Fedora?
On Wed, 2009-07-01 at 14:19 -0400, Bill McGonigle wrote: > On 07/01/2009 01:48 PM, Jochen Schmitt wrote: > > > > On Fedora we have kernels from the 2.6.27 and from the 2.6.28 series. > > This means, that you have to create seperates kernel patch modules for > > each kernel release which was submitted for Fedora-10. > > This is why I suggested it would be practical to set a bar. I think it would be very useful to offer rebootless updates on a schedule - so for example, "one CVE fix" followed by "must reboot within a week or so", during which time it is unlikely there will be another CVE to stack upon the first. Truly never rebooting is something most users aren't worried too much about (even with shiny Apple crap) and those who are tend to be telco/embedded types who have had their own hacks for years and years - Montavista still have something in CGL. > The example I gave was a kernel which was the latest kernel in the > past two weeks. This would usually be one, occasionally two. For a > sysadmin, it's pretty easy to schedule a reboot within two weeks. > '-r now' can be impossible. Indeed. There's a lot of value in saying that you can delay the reboot but that you're protected now - akin to the syscall table hacks we used to shove onto some systems to fix the vmsplice of the moment issue. > > The reseason to do it, is that ksplice is not able to handled patches, > > which may change global data structures. Why not ask Tim to comment on the limitations directly? The ksplice guys are pretty amenable types and I'm sure they would happily chat with you. Jon. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: KSplice in Fedora?
Hi folks, Ksplice is very interesting and I've spoken with a few people about it before. I met the (local to Cambridge, MA) ksplice guys several times and recently talked to them about the kinds of things they're doing right now. Uptrack is a nice showcase of the technology for sure. More comments below... On Tue, 2009-06-30 at 04:49 +0200, Kevin Kofler wrote: > Michael Cronenworth wrote: > > From looking at their website, it sounds like this software can take > > you from say kernel 2.6.27 to 2.6.29 without rebooting? Sounds like > > black magic. I'm intrigued. It relies upon using the existing module loading code to stop the kernel at a given moment in time (which might have to be attempted several times before succeeding in applying the ksplice patch, if the code paths being updated are currently being exercised) and inserts careful jumps to new code replacing existing functions wholesale with new ones. > It actually can't and this is why it isn't very useful within Fedora, as we > get big updates, not just minimal security patches. It would be useful for stable security updates in an enterprise distribution, and it is useful to some people in community distributions - but there's a lot of effort involved and this is where the ksplice guys have invested time in their infrastructure which we would have to entirely duplicate (and engineers too) to do this in Fedora. > KSplice can't handle that kind of updates. Actually, it technically can. > It can only handle small patches which don't change any data structures. That's a load of . I'm not sure where you get this idea from - perhaps because it's not obvious how they might achieve structural updates and so you assume it cannot be done - but actually, they can handle most kinds of update. They achieve this with shadow data structure tracking and manage the ABI differences - see the paper - and implement pre/post code hooks for things that cannot be done without a human kernel engineer. So you can also apply initcall-time fixes by implementing a custom pre-hook to perform what would happen at boot. But anyway, yes, it gets complex. And I've no doubt that for the Ubuntu kernel they're doing this for at the moment they have some of the kernel engineers they have on staff actively writing pre/post hooks. > So the official Fedora kernel updates will never be > suitable to be distributed through KSplice. That's not technically true either. It's just not practical. We would need a much larger team of people and all of the infrastructure tools developed by the ksplice guys. And it's indeterminate what the end goal would be from that - most people are happy to reboot occasionally, and those who are not can already pay Ksplice, Inc. to make updates for them. I'm not sure this is something Fedora can practically offer. Also - for those kernel folks reading. Don't discount ksplice because it sounds ugly. Tim and Waseem really do get it, and they know what they're doing - and they're actively engaging with upstream to get the bits that could be in the mainline kernel in there (ksplice doesn't require any existing kernel modifications because it also injects its own code during the ksplice patch application as part of the wrapper module). I suggest if you're interested in "add this random code patch here" type of kernel development/testing that you add ksplice to the toolbox. Jon. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Do we need split media CDs for F12?
On Mon, 2009-06-15 at 00:24 -0500, Matt Domsch wrote: > On Mon, Jun 15, 2009 at 01:09:52AM -0400, James Antill wrote: > > On Sat, 2009-06-13 at 08:46 -0500, Matt Domsch wrote: > > > (Reposting to f-d-l from my blog post last night. > > > http://domsch.com/blog/?p=85 includes a couple nice graphs to help > > > illustrate.) > > These are believable, but I'd still put money on the fact that more > > than 2.2% of users use CDs ... one of my machines here is an x86_64 Dell > > box, about 2 years old. And only has a CD drive. > > Now, sure, I normally only burn CD 1 ... and then use an exploded http > > install for anaconda. So I could probably make DVD only work, but it's > > much easier to just get the CDs. > > In this case, the netinst.iso (157MB) would suffice, right? No one is > proposing removing that. Actually, your idea is perfect. For almost all cases I can come up with, the netinst disk is fine (and, incidentally, it's all I use other than the DVD install images anyway - especially within VMs). The only counterpoint I came up with was that of folks in parts of the world who don't have access to modern hardware and don't have broadband. You might argue they could be supplied with CDs, but that presupposes that they actually will be, vs. getting Fedora via a Live CD or something else. I think the latter is far more likely now. > I'm not saying get rid of all CDs. Clearly the netinst.iso and > LiveCDs would remain under any circumstance. +1 Jon. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
FYI: ZNC IRC->Email/SMS/Twitter
Folks, If anyone here is running ZNC as an IRC bouncer for #f-d, you might be interested in something I hacked together over the weekend: http://www.jonmasters.org/pub/util/awayping/awayping.txt (I'll clean it up some more when I have time). Basically, it lets you have pings and messages matching certain patterns automatically texted, emailed, and tweeted at you while you are detached. I like it because I don't always want to be attached to IRC but I do always like to have a proxy running that can log messages for me. On public IRC, I just have it configured to email me every 5 minutes if my nick is mentioned during that time with a transcript, and then send me a direct tweet about it. If you don't use ZNC, see the SF project page. I'm interested in packaging it, but admit that I would love it if someone else were interested in sharing that. Jon. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Some pulseaudio questions...
On Sat, 2009-06-06 at 19:01 -0400, Kyle McMartin wrote: > On Sun, Jun 07, 2009 at 12:51:02AM +0200, Lennart Poettering wrote: > > What would be good to have would be a "swap niceness" value that could > > be attached to a processes or memory regions. i.e. some way to > > influence the swapping algorithm in a less binary way than just "swap > > this" or "don't swap this". > I've been working on this along with some enhancements to make fadvise > more than utterly useless... hopefully will be ready for posting soon. Main problem is proving its utility with actual benchmarks - witness the recent first class citizen VM patch thread. Jon. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Some pulseaudio questions...
On Fri, 2009-06-05 at 11:11 -0400, Jon Masters wrote: > On Fri, 2009-06-05 at 12:57 +0200, Lennart Poettering wrote: > > On Fri, 05.06.09 00:21, Jon Masters (jonat...@jonmasters.org) wrote: > > Text book RT applications use mlock()/mlockall() to lock themselves > > into memory and make sure they never are swapped out. This is > > something we cannot really do for PA given that map a *lot* of stuff > > into our address space: libraries, SHM segments for communications > > with other clients, cached samples, and so on. If we'd lock all that > > into memory there wouldn't be any memory left for much else > > Yeah, I'm aware of this. But there perhaps should be some option anyway > - after all, you already have all the support code for it, and already > handle setting real time priorities too. In my brief time with a hacked > up local build that does an mlockall right at the beginning of the > mainloop, I am hearing few audio pops and skips on this box. It's > obviously not a longer term solution, just a datapoint. I'll join the PA devel list over the weekend, it's not strictly that Fedora specific now. But one thing I'm wondering is whether you might benefit from splitting PA into a small core-util bit that were lockable and having all the rest outside in separate tasks - that's probably not too feasible at this stage though. I want to help fix whatever problems I'm getting on each of my machines running PA, rather than sound like I'm trashing talking PA as a technology. The sad reality is that Linux audio worked for me more smoothly 14 years ago when I started with Linux (and manually had to set jumpers, run isapnpdump, etc.) than it does now. It was smoother when I had early ESD[0] than it is now, and smoother when I first built experimental ALSA drivers than it is now. Things like PA are a great concept in theory, but they're not of much benefit if (as in my case) the only obvious way I can get an decent experience is to hack my system and run stuff under pasuspender. Jon. [0] And I mean alongside 0.1 enlightment, back when I had the Free Software Song as a ringtone and enjoyed hearing the startup pips as ESD opened the sound device. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Some pulseaudio questions...
On Fri, 2009-06-05 at 12:57 +0200, Lennart Poettering wrote: > On Fri, 05.06.09 00:21, Jon Masters (jonat...@jonmasters.org) wrote: > > > Folks, > > > > Anyone want to clarify my understanding of PA's use of > > mlock/posix_madvise? From looking over the code - in particular > > pa_will_need, and its callsites - it looks like PA doesn't really use > > this support that it has for locking pages. Which seems weird. > > mlock() is not actually used anymore by PA on modern kernels. I noticed :) But then, neither is the posix_madvise being used that much either, as I noted. On a related note, I have revived the upstream discussion of MCL_INHERIT and will repost patches implementing this over the weekend - then I can have a simple wrapper utility to test forcing an app like PA to do an mlockall. > Text book RT applications use mlock()/mlockall() to lock themselves > into memory and make sure they never are swapped out. This is > something we cannot really do for PA given that map a *lot* of stuff > into our address space: libraries, SHM segments for communications > with other clients, cached samples, and so on. If we'd lock all that > into memory there wouldn't be any memory left for much else Yeah, I'm aware of this. But there perhaps should be some option anyway - after all, you already have all the support code for it, and already handle setting real time priorities too. In my brief time with a hacked up local build that does an mlockall right at the beginning of the mainloop, I am hearing few audio pops and skips on this box. It's obviously not a longer term solution, just a datapoint. > There is a system call for requesting swapping in of memory: > posix_madvise(POSIX_MADV_WILLNEED). Yeah, I saw that and I think it's a nice idea. I'm not sure it's being called very often though - bear in mind I only spent a few minutes looking at the source, so I might have missed something. > > I'll admit I'm about ready to hack in some horrible mlockall hacks to > > see if that'll stop the poppy/skippyness on this box. It did drastically reduce it. The box is under extremely heavy stress as it's running a lot of stuff - dozens of firefox, many evolution windows, IRC, rhythmbox, a few VMs, etc. I'm looking forward to the IO Controller patches so I can e.g. prevent evolution from hogging more than a certain amount of disk bandwidth, which I'm sure will help. > I doubt that locking PA into memory will fix your issues. If PA drops > out often this might have various reasons, but probably not > swapping. Often the timing calls of your sound driver are inaccurate > and cause PA to miss its deadlines. The Intel HDA driver on here doesn't appear to be in your badlist any more, but maybe I am wrong: 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02) > To work around that you could try > disabling timer-based scheduling mode and revert to sound card IRQ > scheduled playback. For that try passing "tsched=0" to > module-hal-detect in /etc/pulse/default.pa. I will try that. > Then restart PA. Another issue might be that PA does not actually > get scheduled often enough by the kernel. I don't think it's that. There's no closed source driver installed. I also am currently running PA as an RT task and my SMI detector shows that this box is not disappearing off into SMI land too often. > Usually running "pulseaudio -v" in a terminal might give you a > hint what might be going wrong. Not very much useful output when I set it into a debug loglevel - maybe this is different. Jon. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Some pulseaudio questions...
Folks, Anyone want to clarify my understanding of PA's use of mlock/posix_madvise? From looking over the code - in particular pa_will_need, and its callsites - it looks like PA doesn't really use this support that it has for locking pages. Which seems weird. I'll admit I'm about ready to hack in some horrible mlockall hacks to see if that'll stop the poppy/skippyness on this box. Jon. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
