From my point of view kernel.org is the right place to get a kernel. Usually I clone the git repository from mainline. Maybe you could also use a recent vanilla kernel and apply the patches from Ubuntu. You'll find the diff at the linux-image package page. Be aware that there could be some conflicts which you have to resolve. So the first version is probably better.
I guess you wouldn't find any good .config
in the wild. What I find helpful is make localmodconfig
in the kernel source. First you copy your old config to /usr/src/linux-2.6
(or the place where your kernel sources are) and then you execute this command. It will disable all module which are not loaded. So you gain more customization in the first place.
I'm not aware of any patches which are good for Lucid.
I'm a member of a local LUG. We make from time to time kernel workshops. Here all members meet. We configure a kernel and talk about our knowledge of different entries. In the end all profit from it and this helps to build better kernels. So if I look for optimisation I would ask our members. If that is not an option, reading the Linux Kernel mailing list could also help to find a solution. You'll find often some discussion which are helpful.
As software is being developed, before it is "released", the software in its unreleased or "unfinished" state may still be quite usable at any given moment in time, as devs are making changes to it and either adding features or preparing it for a future release.
A daily build usually means that some machine grabs the unreleased software every night at one particular moment in time, compiles it, and puts it up for developers to test.
Obviously, it may or may not be usable, depending on what stage of development it's at, what the release strategy for that project is, etc. What you are testing is a snapshot of unfinished software at one moment in time.
Sometimes, the software may well be very nearly ready for release, in which case it'll often work quite well already. If the developers have declared a "freeze" it means that they minimise changes, only fixing existing bugs. During that stage, a nightly build of a piece of software is more likely to be quite usable since it's getting close to release time.
If you are talking about daily builds of the Live CD or a Installer CD, then these are builds made of the installation medium based based on snapshots of the current development process. All the above applies. These should usually work pretty well due to their release strategy, though it's not uncommon for some things to be broken.
There's no point installing any piece of software from a daily build unless you are testing features that are currently in development and not yet released, and you are willing to put up with it being a bit broken or unfinished.
Best Answer
No they're not. Let's clarify a distinction here,
Does the system support "reproducible builds"?
Yes all systems support packages that are deterministic.
Does the system enforce "reproducible builds"?
Nope, though it does help diagnose problems, and works is being done to make packages reproducible -- bugs are being reported and handled anyway.
Is everything, without exception, reproducible?
Not even close.
Now let's define "reproducible builds"
Now let's talk about what is required
Check out this page under "How" which lays down three criteria
the build system needs to be made entirely deterministic: transforming a given source must always create the same result. Typically, the current date and time must not be recorded and output always has to be written in the same order.
the set of tools used to perform the build and more generally the build environment should either be recorded or pre-defined.
users should be given a way to recreate a close enough build 3., perform the build process, and verify that the output matches the original build.
You can find more documentation about all of that here.
As to why Ubuntu isn't currently reproducible, things like Perl currently fail because
-V
stores the compiler args for convenience -- they're waiting on GCC to patch this upstream. A lot of this functionality could simply nuked. Some other problems: some man pages and programs have the build dates compiled in, others compile in mutable paths to shared libraries and the like.Not being reproducible isn't a problem or a vulnerability. It just makes it harder to verify that you haven't been tampered with, and currently that functionality is being viewed as more valuable.
You can follow Debian's progress towards determinism here