As a matter of fact, the site is sold. It is in flux, and I am awaiting contact from Daniel Robbins to transfer the domain name. Once that's done, then it will be up to the new owners of the site where it goes from here.

As for using seeds presently, they are still useable. The site is still up and running, even now.

pappy, your work really helped me several times last year, thanks! Let's see if the new owner of the site will update it.
Was searching today for 3.12.13 and found just up to 3.12.01._________________Emerging en gentoo

Thank you for the praise. As for what the new owner of the site is or isn't doing, I am no longer a part of it, so I am now on the outside looking in. If you wish to move forward using a seed, simply download the seed closest to your current kernel version, and run make oldconfig. That will set the seed to the latest kernel version. From there, you can use any of the other make scripts to do the final configuring, like always.

I can't begin to express how happy I am that my project not only found favor, but found enough favor that it's been adapted. I, too, hope that the new page will succeed where I couldn't; in being able to keep up with the changes in the kernel settings and how they were used in Gentoo. Once I really began working on that side of things, I realized that I might have bitten a bit more off than I could chew.

Still, that page helped me a lot. That it will go on is perhaps the proudest accomplishment of my reality. Now, to conquer show biz (hehehe).

Well, apart from the month+ old wiki page it looks pretty much abandoned to me. It was down for quite a while (Funtoo as well, provider trouble). But it hasn't seen an update since the November 28 one. Oldconfig still works for the current Gentoo 3.12.13, but as soon as they adopt 3.14, you suddenly have to answer three pages filled with questions. It's too bad, really. As a primarily Windows administrator I really don't know what most of those options do...

There's not a lot I can do about what is or isn't happening to the new site. It's no longer mine.

I can say that using make oldconfig to move up kernel family-wise usually requires only hitting enter, as most options default to no or off. If your .config works properly for your system, you don't need to add anything. Hitting enter will get you right through. If you do encounter a "Y", hit the question mark and <enter>. That will give you an idea of what the thing is you're using. As a general rule, if it is recommended for use, use it. If it has bad effects, stop using it.

For the most part, once your hardware is set, it is set. New kernel families always add new devices. Unless you've been specifically waiting for a certain driver for a certain machine, you aren't going to need any new hardware devices. While sometimes, new processes show up in the kernel that are necessary, it's not a common thing for those changes to even be in the realm of what you, as a user, can actually change.

Don't forget that anything you don't know about the kernel can be answered by googling the symbol in question. Sometimes, you only get standard help. Sometimes, you get an entire dissertation on the setting in question, including best practice settings. Also, consult any programs you might use that will require certain things of the kernel. Most packages that require certain kernel settings will make you aware of that at emerge time. Some packages will fail to build. Others will build, but will do so in a whiny fashion. In either case, set the kernel as needed, and those issues tend to go away.

While not everyone can know the entirety of the minutia associated with the modern computer, there are certain things that are as unchanging as you can get. Knowing the beast in a hardware sense is a good idea if you're planning to work with computer administration. Knowing only software is limiting.

I started out nicely, by Googling the options to read what they did (most stuff I didn't have a clue what it meant). But like I said, after number 35-40 you get annoyed and just hold enter until the prompt re-appears. Enough scrolling to fill a few pages.
I always figured you turned off stuff that was on by default to make the whole 'seed' thing more efficient. So the more I leave at default, the more removed I become from your 'ideal', so to speak.

So I should have the serenity to accept the N's that need no change, question and change the Y's that need it (like new drivers), and the wisdom to know the difference then?

It can be a steep learning curve starting out with maintaining a kernel config; but you've got to start somewhere, once you're past that it can become easier over time.

What I did is start from upstream's defconfig, given I prefer working out my own kernel config over taking a preset; then, I went on to go once through the entire menuconfig (but I come from a Windows enthusiastic background; so, this includes some research online) and set it up for a lifetime to come. With kernel upgrades, I'm not too bothered running oldconfig; I just use my previous kernel config and let it take on the defaults for new matters. One thing to note is that new drivers often are modules; so, they only load on demand and don't change performance or reliability as they don't load. There are however a few other things that might change; for these, I once in a while just do a diff between an old and new config to see what has changed.

Let us take for example a diff between 3.14 and 3.15; that diff for me is only 620 lines, with only 74 removals and 131 additions (some removals and additions combine to changes) which roughly gives me something like an overestimated 100 kernel config variables to go through. Let's see ... "CONFIG_GENERIC_EARLY_IOREMAP=y" (menuconfig tells me my arch forces this enabled, so I can skip), "# CONFIG_EFI_MIXED is not set" (I don't use EFI, so I can skip), ... and so on; a lot of these, along the lines of EFI, you'll be able to tell what you want them to be by just seeing the kernel config variable. Some need a quick search or a bit more investigation, but in general it shouldn't be too much work to go through them every X months; especially since this investigation can be helped by looking into resources that tell you what's new and changed which also explain it to some extent.

An option you've skipped over is in general not going to drop your performance or reliability; so, trying to work on every option might not give you more benefit for the cost that you put into it. And in the case that you did skip over one or another option that did drop it, you've got a good reason to investigate further; my system works excellent for me, even when I didn't check my kernel config the last major releases. But who knows it might break soon; so, this reminds me of checking the new options sooner or later.

Given such a kernel config, I wouldn't consider a kernel seed (as my own specific work for my specific ssytem would become useless); they make more sense to me if you can start from them, like when you're new to Gentoo and someone tells you "you should look into the kernel seeds" or when your kernel and the defconfig is totally broken and a kernel seed appears to work. If the continuation of the kernel seeds succeed, it is nice to have that as that definitely helps out for a start; but in the lack thereof, it's not too hard to maintain the kernel config on your own. And if it is to some, we could work together to make the process of maintaining the kernel config across kernel upgrades easier; I'm pretty sure that besides the commands to run, there is still somewhat an undocumented area to explore and document.

Yes. Through a strange confluence of my reality, my knowledge of electronics and computers, as well as my love for getting people hooked on Linux, I became the defacto kernel configuration guru. Perhaps it was those thousand or more .configs I've generated in my time of running the site. Maybe it was making bug reports or hacking my kernel source to eliminate a built in one second delay that does nothing.

Since I have kept every .config I've ever generated, mine and those of others, I am left with a limitless supply of kernel configuration files, old and new, that are proved to have resulted in functional computers. When my old, reliable laptop died recently, I had a .config for this substitute system already stashed away and waiting. One funtoo install later, and that kernel's direct descendant (v-3.15_rc5) is making it possible for me to see and reply to this message.

While I have stopped working the site, I do still know how to set up kernels for those who desire me to do so. The past few weeks have been devoted to bringing the process a bit more in line with what's out there, and moving data around in my personal cloud system so that I have every bit of data I need from that old laptop ready to be accessed. Now that that's done, I am quite willing to do kernel configuration.

Since I am doing it as a individual, I request a five dollar donation for these services. While I will always do them for free, I don't think it's out of the realm of acceptable that the information I have garnered is worth something. For the user, I don't think that paying five dollars to diminish irritation is out of the realm of acceptable, either. If you are a business owner, and want to use my expertise, I ask for a minimum twenty dollar donation. You'll feel better, because you're paying a man for his time and effort on your behalf. I'll feel better, because as a struggling independent contractor, I need all the gigs I can get. Considering how much Microsoft is ripping people off for it's bug-ridden offerings, even businesses who splurge are still getting a better deal than anything left in the MS stable of "operating systems".

Seeds are still great thanks pappy. Used the 3.12 seed with 3.15 kernel with nearly zero issues. So a heads up for anyone else who runs into this...

If you use UEFI grub make sure you have...

Code:

CONFIG_FIRMWARE_EDID=y
CONFIG_FB_EFI=y

Otherwise it just says loading kernel and makes you pull your hair out

I had initially followed the nvidia blob advice of disabling everything in the FB section which is probably fine for MBR grub, not EFI._________________CFLAGS="-OmgWTFR1CE --fun-lol-loops --march=asmx86go"

if you haven't noticed kernel seeds v2.0 is up now @ wiki.kernel-seeds.org there isn't much to see but the original site is located @ kernel-seeds.org

im going to start looking into it a bit... @ the windows admin, make menuconfig & exit will auto default everything that's changed since pappy edited the kernel configs, no questions asked. since they are defaults it may be bloated a little bit but it will still work as the seed did for the most part. again might introduce a little bloat till things on the funtoo side get arranged & ordered.

A. Since most new settings in the kernel are for new cards and devices, hitting "N" remains the best way to answer questions during make oldconfig.

B. I'm still linked to this thread, and anytime anyone posts here, I get the message. It may take a day or two to show up, but I do respond.

C. While I'm not keeping up with kernel-seeds.org and what it's up to presently, I do still know how to work on .configs to make them nice, pretty, and small.

D. I may have wiped out over a terabyte of uncompressed kernel source, but it's not that hard to emerge sources, set up a different .config, and remove them after I'm done.

So, I am still here, just a bit more in the background. While I do charge now for setting up kernel .configs, I don't overcharge. From my way of thinking, five bucks to get your kernel set properly (twenty minimum for businesses making the request) is a drop in the bucket compared to what you would pay if you had to come to MickeySoft with questions concerning the operational kernel and its settings. They get a huge amount of money to more or less tell you to reinstall your OS; seemingly the only way one can presently fix your Windows installation when it contracts digital leprosy.

I do plan on staying around here at least as long as I continue to suck oxygen from the atmosphere. So, if you have issues, I'm more than happy to help. I'm cheaper than MickeySoft, and much cuter than Bill Gates.

Alright, since Kernel-Seeds 2.0 is very much vaporware, I'll take a Gentoo-Sources 3.14.14 x64 seed so I can experiment with my new setup. It's the latest one I'm getting from stable portage. So, how do you want your fee, PayPal?

Alright, since Kernel-Seeds 2.0 is very much vaporware, I'll take a Gentoo-Sources 3.14.14 x64 seed so I can experiment with my new setup. It's the latest one I'm getting from stable portage. So, how do you want your fee, PayPal?

If I wanted an 3.14.16 i686 as well, that would be 10, then?

I'd need the following:

1. The results of cat /proc/cpuinfo and lspci -n from both machines.
2. Your current .config(s), if applicable.
3. A copy of /etc/fstab from each machine.

Yes, it would be ten for two. I will send you a URL once I'm done.

Cheers,
Pappy

PS: The latest and greatest is the 3.17 family, if you're thinking about taking an opportunity to move way up kernel-wise, this would be the time to really go there._________________This space left intentionally blank, except for these ASCII symbols.

Actually, all I need is a clean .config-seed without hardware support, the way you used to make them. I have a text-file with all the hardware that I need to enable for my system. I take the seed, switch on the options from my text file, bake the kernel and I'm good to go. I need to test it in VMware first anyway. Less work for you, right?

As for 3.17, when I fully update portage and do an emerge gentoo-sources, I get 3.14.14 on the x64 branch. It's for my home-brewed NAS, so I'm not going ~x64.

I think I can handle the make oldconfig for revisions or small minor version updates. But the jump from 3.10 to 3.14 gives me half a tree of pages with questions, mostly due to storage improvements.

I also wonder if btrfs will act differently now that it's considered stable. Although I despise its inability to output free space properly. When applications start complaining about write errors even though the system thinks there's still 20GiB free, it takes a little while to figure out btrfs fi show actually informs the operator that the disk is indeed full. Hopefully, that's been fixed by now...

Actually, all I need is a clean .config-seed without hardware support, the way you used to make them. I have a text-file with all the hardware that I need to enable for my system. I take the seed, switch on the options from my text file, bake the kernel and I'm good to go. I need to test it in VMware first anyway. Less work for you, right?

As for 3.17, when I fully update portage and do an emerge gentoo-sources, I get 3.14.14 on the x64 branch. It's for my home-brewed NAS, so I'm not going ~x64.

I still need the requested data in order to start fresh.

I would recommend moving up as high as you can kernel family-wise. If you're using reiserfs, this pretty much limits you to late 3.15, later 3.16, and 3.17 as it sits presently. If you don't, then 3.14 should work out just fine.

I forget that being on the bleeding edge isn't necessarily where others want to hang out, like I do. I'm running 3.17. That just means I get to deal with the latest, most cutting edge bugs available.

So, send along that information, and I can set you up with fresh, virgin .configs.

I'm currently using XFS and ext4. I have been considering ZFS, but the RAID-functionality - although better - is not as flexible as MDADM, and it doesn't play nice with cryptsetup, from what I read. If only those later versions were open-sourced.
So I'll probably migrate to BTRFS.

How do I attach files? Just put them in a code block? That would take up a lot of space...
Anyway, sent you a PM, I've been off-topic for too long.

As for the topic...
Anyone hear anything about kernel-seeds 2.0? Any update, somewhere in the background?

Actually, I'm pretty sure the efx2 file system is older than reiserfs. That said, one updates kernels for the latest and greatest security updates and some other nice bits that come in here and there. Newer kernel sources are the best for cutting edge hardware, fresh on the market, and most likely not well supported right off the bat.