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