Developers are users, they come from out of the community; if the community (including developers) has no further interest, then either neither or both sides are to be blamed for that but not a single side.
..the same goes for recruiting new people, it's not only the users that don't step up but also the developers making it not interesting enough to join for them.

Ah but who has the power out of those two groups to change the recruiting environment?

And no "become a developer and change it" is not an answer to recruitment problems: the whole point is that becoming a developer is off-putting, and even more so when one reads the list. Because "developers are disciplined in private" whereas "users are disciplined in public" usually by getting insulted when they say something a developer disagrees with, and then responding in a similar tone, which brings down all hell on their shoulders. No-one else looking at that would welcome it. Nor would you if the boot were on the other foot.

Quote:

And at moments like that when a distro runs empty; lowering the recruitment barrier would perhaps help, but that goes at the cost of some quality

No-one mentioned lowering the skill-bar: that would be a dumb idea as you outline.

Quote:

There is no such thing as "the users are the problem" because then a developer would simply be referring to oneself as well;

Perhaps conceptually: and I sincerely hope you stick to that stance when someone tries to recruit you to one of those cliques. If you're burning-out it's not so easy: at that point you're running ragged, not thinking straight and getting more and more fed up with user demands, and you can't really pick on anyone else. So you lash out at them, and then someone whispers in your IRC..

And burnout happens to every developer at some point in their careers: your first one is a horrible experience, believe me. No-one likes to talk about it, and in corporations they do not: so-and-so just got fired/rage-quit/had a breakdown, and we don't talk about people who are persona non-grata, just like we don't talk about people who died. Not in companies usually: everyone is trying not to appear weak, and not to lose face. And why talk about someone who's gone? What possible advantage is there? Whereas one might become tarred by association, or appear "soft" as opposed to emotionally-adjusted.

You will find reference to the "7 year burnout" here and there, but it can happen at any point: the more you care about it, the more time you put into it, the more probable it is. It's not a question of if: but when. Certainly in any collective working on software, it will happen. The more people involved, the more often it will happen. It's just the nature of it. Eventually you learn to spot the signs, and back yourself away from the situation: it's hard to do, because you care.

For more, see "Support burnout" here: http://freenode.net/channel_guidelines.shtml In essence you cannot do everything, so when you're feeling ragged, don't get into detailed arguments: get some sleep, some food, a shower and see your friends or family, or just go for a walk.

"The coder does not live by code alone."

Come near some of us when you're burning out, and we tease you mercilessly until you finally laugh, or give up and give us a sad face; something to show we're not arguing with your overworked fore-brain any more: and then we can get through to you. If we know you, and hang out with you, that is.

I use LVM for all of my non-root directory needs but specifically keep root (and /boot for that matter) as traditional partitions specifically to avoid an initramfs because it's just another complication and potential point of failure.

I've been configuring my own kernels since the mid-90s, tuning them to my systems as needed. I don't need a one size fits all solution that throws everything into a module "just in case" and as we are not a binary distro, where the kernel, initramfs and core boot packages like lvm, get upgraded in sync with each other, having things fall out of sync due to an upgrade not warning about the need to rebuild initramfs becomes more likely and may cause boot failure.

Before this one gets lost in the shuffle ( ) I thought this was an interesting point. For manual kernel builders (and that's clearly a lot of us), the process is necessarily a multi-step one, and I imagine most of us have our systems and scripts for at least partially automating it. I always keep current and last-good kernels installed, so once a new one's emerged my process is:

Unmerge the oldest kernel and clean up everything left behind

Update the /usr/src/linux symlink

Copy over the current kernel's .config and make oldconfig, make, make modules_install

Mount /boot

Copy kernel, System.map and .config to /boot

grub2-mkconfig

Umount /boot (after ls -l'ing what's in there, for my peace of mind!)

Scripting this was a trial-and-error business, but it's pretty bombproof now. The last time it let me down was kernel-3.0, because it wasn't 3.0.0 and my version-detection method fell over - I didn't know about ls -v then

I'm glad I don't need to build third-party kmods like ndiswrapper any more, at least, but certainly we all have to keep on our toes however we go about updating kernel/boot stuff, not to mention critical libs (though portage is getting much better at alerting us to those). Sure, I could doubtless work dracut into my script, but sooner or later that'd go "ping" too, you can bet on it.

Has anyone here *not* had to recover from such an unexpected (and unwarned) b0rkage in their early (or not so early!) days with Gentoo? I see it as kinda a rite of passage

Ah but who has the power out of those two groups to change the recruiting environment?

Both do, just answer the question "if I were a ... then what would I do to get Gentoo more manpower?", because where there is a will there is a way. Yet that doesn't imply that it is for that person to do it; it eventually has to come from everyone that cares, or perhaps a small group or one individual that has seen the light and can push it forward.

steveL wrote:

And no "become a developer and change it" is not an answer to recruitment problems: the whole point is that becoming a developer is off-putting, and even more so when one reads the list. Because "developers are disciplined in private" whereas "users are disciplined in public" usually by getting insulted when they say something a developer disagrees with, and then responding in a similar tone, which brings down all hell on their shoulders.

It is often seen as off-putting, but most of it really isn't. Okay, well, you do have the quizzes that require some up front work you have to go through to understand enough to contribute without tree breaking mistakes, but I don't think there's much that could be shortened about the length of the quizzes. On the other hand, the reviews that happen after that are meant to help you and not to judge you or give you points based on how well you did. I think it is quite rare for someone to make it through the quizzes but not through review. As for developers that insult, they should be reported; I've not seen this yet, and I hope that to stay that way.

steveL wrote:

No-one mentioned lowering the skill-bar: that would be a dumb idea as you outline.

It would be an implicit consequence of shortening the quizzes; which I would perceive as a dumb idea as well, unless there really is something in the quizzes that shouldn't be in there.

Yes, needing an initramfs to decrypt my system LVM cointaining root, home and everything else.

Until very recently I did not use any initramfs. I had only my home directories on dmcrypt volumes that where mounted with pam_mount at login time - since I thought my root partition does not have anything of private information on it anyway. I also created a very complicated mount setup to have /var/log not in the root partition, but on an encrypted volume as well, as well as some other places in /var that may contain information about usage, temporary files etc.

The reason to do it that complicated was that I really hated initramfs'es, because they slow down boot, several times they messed up udev, failed to boot when I forgot to update them after a kernel upgrade etc. But since I tried dracut and its integration with systemd, I'm very happy with the performance and dynamic functionality. Also, now that my paranoia (?) about someone taking my laptop, changing some binaries on my non-ecrypted root and install keyloggers or something like that to defeat all my security messures, is satisfied, I really feel better about this much simpler and more secure setup. That's why I'm really happy dracut exists to make my life easy to have a fully encrypted system without any hassle (which I always had when I tried it with genkernel initramfs'es).

A month ago, my answer would have been 'no'. I recently encrypted my root partition(s), and as far as I know, a initramfs is necessary for this. I configure my kernels manually, and use genkernel to build the initramfs for me.

The last really nasty b0rkage I had was expat and modular Xorg together.
expat wasn't mentioned
The steps for Xorg started with removing monolithic Xorg. Then the sky fell in.

This was a good few years ago now.

Uhhhhh.... Just when I'd almost blocked out the expat clusterfun... Nurse! I guess that must have distracted me from the Xorg thing; that or I was already hip-deep in woes with X at the time, which as I recall was not uncommon back then.

I just voted "No, I do my own kernel so it's just more work". Besides that, i'm not a fan of initrd/initramfs so i'm actively keeping my configuration in a way i don't need it
In my case that means no encryption on my rootfs and raid layout v0.9 so it can be autodetected by the kernel._________________The gentoo way of bringing peace to the world:
USE="-war" emerge --newuse world

My answer has been «Yes, other reasons».
The reason is that I've never found a manageable solution (I mange a tenth of computers) to have LVM, /usr separate and so on.
Also, the actual intrmafs solution is not only annoying, but also not well working for me.

So it looks like the vast majority who are using one are doing so because they have to; because of this chicken-and-egg problem, "To mount this partition at boot, I need access to something that's on this partition".

In a sense, the userspace stuff in question (that we need to put in our initramfs) is no different to the kernel: that needs to be somewhere the bootloader can access it too. So maybe the paradigm is actually not so great here: if your whatever-it-is is needed by the boot process, it really should also live on /boot (or wherever you access your kernel from). Then you would not need an initramfs, with its duplication of files that are already on-disk.

I guess the argument against that is that the types of binaries involved would then need all their libraries (unless they are all built statically, which isn't too desirable), conf files and everything else on there too. I don't think that's unreasonable personally, but people like all their bins, libs and, er, etcs in the usual locations. Also many/most of these items are not exclusively for booting, so if they're all in /boot that goes against the everyday, non-boot-critical work they also do.

No easy resolution without tearing up LSB and starting again, I guess. Maybe there'd be something clever you could do with unionfs or such to satisfy both camps, but mandating use of unionfs would probably be no more popular than mandating use of an initramfs ... My head hurts now.

No easy resolution without tearing up LSB and starting again, I guess. Maybe there'd be something clever you could do with unionfs or such to satisfy both camps, but mandating use of unionfs would probably be no more popular than mandating use of an initramfs ... My head hurts now.

It has the same fragility that an initramfs has... if the end system gets updated by a tool that, say, alters a partition format that isn't backward compatible, but the boot system doesn't get that update, your system won't boot.

There are two solutions -

Keep things as they always have been, with the tools needed for boot and system repair in / (whether static linked or linked only to /lib)

or

Go all Microsoft and make a full blown systemwide C:\ and just be done with it. This is essentially what the /usr merge is

The problem has arisen mostly because of laziness (I'm just going to link wherever and install everything in /usr even if something really belongs in /bin without actually giving much thought to what I'm doing), ignorance (my init needs a web server) and arrogance (my program is so special that it needs to touch everything in the system at boot and it's the greatest thing since sliced bread! showing ignorance and laziness of why that might not be a good idea).

Unfortunately there is no "Partly on specific system" answer, so I chose "Yes, other reasons".

I have three machines with gentoo on it:

Company laptop - Here I do not have an initrd. /usr is not an individual partition, so I do not need one for /usr to be premounted or to hack away the system to be able to work with a separate /usr without an initrd. A hackery that might break any other update. Not good on a production system IMHO,

Company desktop - The same. No separate /usr, no frustration.

Private desktop - This one is different. Here I have 4x500GB SATA drives, that live happily together in a firmware (aka "fake") RAID0 stripe set. It is a dual boot machine, and I wanted both Gentoo Linux and Windows 7 to be able to use it. (If it were a Linux-only machine, I'd've used mdadm instead of the firmware RAID.). So I need a dmraid initrd here to be able to boot from the firmware RAID. However, genkernel can be used to only produce the initrd, so the difference to the other two machines is just one line in my build-a-new-kernel-script.

I answered yes. As I understand it, having a separate /var & /usr requires initramfs, yes?

If you have modules built-in to kernel for mobo and HDD controller, and you don't need any devices setup by udev to mount local partitions, then you can use patches to two initscripts to get udev to start after localmount. There's no point doing that if you're already setup though, unless you want to (eg you don't want to maintain an initramfs, since it must be kept in sync with rootfs for things like lvm etc. and/or you don't want the additional step at kernel build/point of failure.)

Note that this won't work if you have root on lvm/RAID/encrypted: which has always been the cut-off where you traditionally needed an initrd. Many of use a slim rootfs, and have most other things on lvm; /usr on LVM was actually documented in the Gentoo LVM guide for many years. I for one have run out of space on /usr a couple of times over the years, before I switched to LVM, and have two drives on my desktop, so just split the disks into volume-groups: deb, gent2, and var, with spare space to allocate as I see fit. Swap and /tmp are direct partitions, as is /home.

In any event, /var and /opt, effectively all local partitions where either helper scripts, libs or directories they use might live, are required going forward: that was the requirement stated on the dev ML about 2.5 years ago. For a while alsa needed /var, for example, and realistically helpers might be anywhere, though that's less of a problem on Gentoo; depends on whether you have 3rd-party drivers I guess. The patches fulfil that requirement.

I am not opposed to using one if needed. Been there, done that. But doing it just for the sake of doing it when it's not necessary is plain silly in my opinion. If, in the future, it becomes unavoidable, it's not something that I'll cry about

saellaven wrote:

Go all Microsoft and make a full blown systemwide C:\ and just be done with it. This is essentially what the /usr merge is

Well, you can redirect My Documents to D: and even put "C:\Program files" into E:, and that won't make Windows any more POSIX-like. There are setups where having a separate /usr really serves no purpose. But that's a discussion for another [dozen] thread[s]._________________Gentoo Handbook | My website

I answered yes. As I understand it, having a separate /var & /usr requires initramfs, yes?

For /usr that's true now, yes. As for /var - good question, and one I was about to ask myself! (Just been pondering moving /var or at least /var/log onto flash media)

My server has /var as a separate partition from /, and I can confirm that (at the moment) it boots just fine without an initramfs._________________If ~amd64 ebuilds are cutting edge, then git-9999 ebuilds are chainsaws.
"Not everyone can ride a unicycle, does that mean we should put another wheel on it?" - Lokheed

I answered yes. As I understand it, having a separate /var & /usr requires initramfs, yes?

If you have modules built-in to kernel for mobo and HDD controller, and you don't need any devices setup by udev to mount local partitions, then you can use patches to two initscripts to get udev to start after localmount. There's no point doing that if you're already setup though, unless you want to (eg you don't want to maintain an initramfs, since it must be kept in sync with rootfs for things like lvm etc. and/or you don't want the additional step at kernel build/point of failure.)
...

As a matter of interest, why is that (the last bit about being in sync)? I have raid and lvm in my initramfs on a simple system, and haven't been punctilious about updating the versions in the initramfs, yet haven't seen any problems. I can see that if I create new raid devices or volumes with a new version of the software then I ought to update that in the initramfs in case there isn't forward compatibility.

Yes grub2 claims to support that but if you look closer you need new gpt partition thing and that is for sure a source of problems.

After 2 years tehy still have not well documented all features of grub2.

"New GPT partition thing" is not really so new these days, nor is it all that problematic in my experience (though my setups have not been all that adventurous, I admit).

GPT is required by (U)EFI which is fast becoming standard on current machines, so there's no getting away from it forever. Also, with EFI the kernel can load itself without needing a bootloader, so perhaps this actually makes life easier in some ways, but that's not something I've investigated yet myself.

I strongly agree about grub2 though; very impressive, but too many "How do I...?" left to figure out the hard way.