On Thu, Sep 8, 2011 at 12:06 PM, Michael Schreckenbauer <grim...@gmx.de> wrote: > Am Donnerstag, 8. September 2011, 11:13:58 schrieb Canek Peláez Valdés: >> On Thu, Sep 8, 2011 at 4:09 AM, Michael Schreckenbauer <grim...@gmx.de> > wrote: >> > Am Mittwoch, 7. September 2011, 23:33:35 schrieb Canek Peláez Valdés: >> >> I don't see any problem with an initramfs larger than the kernel. It >> >> will handle a lot of stuff. But if you don't want to change your /boot >> >> partition, then don't upgrade to new kernels. >> > >> > How about accepting the fact, that there are a lot of things out there >> > "you don't see"? Get over it. People have told a lot of valid reasons. >> > They might not seem valid to you, but that's not their problem. >> >> Relax man, I keep saying that is *I* who don't see a valid reason. >> That doesn't mean there is no valid reason; I thought that went >> without saying. Sorry if it sounded like I was invalidating all you >> guys reasons. >> >> My primary point was that, I *you* have your reasons to keep a >> separated /usr, then by all means do it. You will only need an >> initramfs. > > That's the point. You *need* an initramfs. You know KISS?
If it's so "simple", write the code for support the option of not having an initramfs. If it's not that simple, then what KISS are we talking about? >> > Have you *ever* thought about machines, that are not x86 or x86_64? >> > Here's an intersting read: >> > http://permalink.gmane.org/gmane.linux.gentoo.devel/72769 >> >> No, I haven't thought about them, because I don't use them. What it >> has to do with anything? > > Well, I linked a mail. MIPS is mentioned. As I read it, there are cases with > MIPS, where the initramfs *has* to be built into the kernel *and* the kernel- > image is size restricted. That's the problem with an initramfs bigger than the > kernel itself. That's a MIPS restriction. Then with MIPS you will need to put /usr in /, and problem solved. But no, everyone wants everything, and exactly the way they want. Well, then they will need to write the code to support it, because no developer is forced to support every single architecture in the whole damn world, in every possible configuration available. >> >> Change happens. >> > >> > That's right. And sometimes these changes are simply bad ideas. >> >> If so you think, then write the code to support the *really good* ideas. > > Ah. Criticism is only allowed, if you are writing the code. Not in my world, > sorry. By all means, criticize as much as you want. What I meant by "If so you think, then write the code to support the *really good* ideas" is that you have the *option* to do that. You can of course complain forever: that will not mean that anybody (and in particular the developers) will listen. >> >> >> > Mounting it read-only >> >> >> > seems the only sensible one, and then I think is better to >> >> >> > go all >> >> >> > the way and mount / read-only. >> >> >> >> >> >> Putting /etc on a read-only filesystem seems a really bad idea. >> >> > >> >> > To say the least. >> >> >> >> It works, and it makes life easier for upstream. Which are the ones >> >> writting the code. >> > >> > Hu? There's one upstream writing all the code for all the stuff we use? >> > That's news to me. >> >> Well, in this case by "upstream" I was meaning the Gentoo devs. > > Not all of the gentoo-devs are in favour of the idea. Of course not. But, as with anything Open Source related, the ones that write the support code will prevail. The complainers (if they only complain) will not change anything. My point is: if everything would be the other way around, and the Gentoo (or kernel, or udev) developers decided that the True One Way (TM) to do things were to separate / and /usr, I would do it. I did it when me moved from ipchains to iptables, and that was particularly painful because every single damn script just stopped working. But such is life: i didn't write the code. If I wanted to keep up with development, I needed to change my way of doing things. I have rolled with the change every single time since I started to use Linux in 1996 (damn, I'm old), and sometimes it bite you in the ass in the long run (hello HAL!) But most of the times is for a good reason, and everything kinda improves. And since I'm not writing code, just taking advantage of getting it for free (as in beer and as in speech), I usually trust developers. It usually pays off. Of course, sometimes it doesn't (hello devfs!), but what are you going to do? Look a gift horse in the mouth? In the long term, trusting the developers usually it's the way to go. Been here a long time, I stick to my guns. Don't like it? Well, complain if you want, but if you don't writing some code it would probably be for nothing. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
