* Jorge Manuel B. S. Vicetto schrieb am 01.08.11 um 11:19 Uhr: > I agree with Eray. Furthermore, please stop trying to reverse "the > game". It's those that want to break existing policies and conventions > that have to justify why they want to do that, not those that want to > keep using what has worked for years.
I wouldn't call the current static -workarounds, and files from / using files from /usr, neither a clean solution or working The separation is unnecessary maintaince burden for something that has maintaince free replacement > You may not need or like it, but I want to be able to use > partition schemes like the following without needing to use > an initramfs: Sorry for dismissing the lines below that ":" mark then. Feel free to ignore me, no offense taken, but I'll be disappointed if you won't provide a reasoning for resisting part of the solution > Also, desktop users that don't split the /usr path might not like the > "stress" that /usr/portage will add to the / partition - not to talk > about the size and inode constraints. Good point, so handbook will need a patch for /usr/portage partition recommendation after the fact > I'm growing tired of how complex and over-designed desktop technologies > that hide stuff from the users keep trying to break the "unix way" and > convince us they're "awesome". No, I don't need or want *kit, groups > exist for something. No, applications that do "magic stuff" with dbus > and xml (and I like xml) on the users back and hide how X work aren't a > "good thing(tm)". Then one should do something about it, like providing an alternative or at very least, provide upstreams with patches for making the new stacks optional > Finally, Gentoo's init system is and will likely be for a long time > openrc, so stop trying to push crazy or experimental init systems - most > with a seemingly "poor design" and unable to do what an init system > needs to do (start and stop services). This isn't about systemd, but indeed it will solve one compability obstacle for them too. No harm there.