| 1 |
On Thu, Sep 15, 2011 at 5:16 PM, Joost Roeleveld <joost@××××××××.org> wrote: |
| 2 |
> On Thursday, September 15, 2011 04:42:23 PM Mike Edenfield wrote: |
| 3 |
>> On Wednesday, September 14, 2011 01:36:56 PM Dale wrote: |
| 4 |
>> > Canek Peláez Valdés wrote: |
| 5 |
>> > > But that's the thing: we (you and me) don't see the situation the |
| 6 |
>> > > same |
| 7 |
>> > > way. To me, the proposed changes are for the better. |
| 8 |
>> > |
| 9 |
>> > You are one of very few that feel this way. |
| 10 |
>> |
| 11 |
>> You are probably correct that he's one of the relatively few people (along |
| 12 |
>> with the udev developer, and those few people for whom it will fix their |
| 13 |
>> problems) who think these changes are a real improvement. |
| 14 |
> |
| 15 |
> If for those people using an initramfs solves their problems, then I'm not |
| 16 |
> against it. And I don't think many others are either. |
| 17 |
> But why are people forced to use an initramfs where it is not needed? |
| 18 |
|
| 19 |
<bad_joke>Well, technically it's not "forced"... if you put /usr in / |
| 20 |
then you don't need it...</bad_joke> |
| 21 |
|
| 22 |
The thing is that the initramfs solution solves the general problem |
| 23 |
(as the devs keep trying to explain in -dev). You may not *want* to |
| 24 |
use an initramfs, but it *will* solve the problem. |
| 25 |
|
| 26 |
The devs *could* make up an alternative for an initramfs for those |
| 27 |
people who fell they don't need one, but then they (not us) need to |
| 28 |
maintain it, test it, document it, etc. It is not worth it if the |
| 29 |
initramfs works for everyone... even for those who don't want it. |
| 30 |
|
| 31 |
>> I would estimate that the vast, vast, vast majority of users are those such |
| 32 |
>> as myslelf, who have no opinion whatsoever, and either will not be affected |
| 33 |
>> at all by these changes (because they don't separate / and /usr), or will |
| 34 |
>> simply apply the proposed initramfs solution and move on. |
| 35 |
> |
| 36 |
> You also don't have /var (or /var/log) seperated? Or any of the other parts of |
| 37 |
> the filesystem that might be required by udev-rules? |
| 38 |
|
| 39 |
Many laptop users don't split /, among other things because the free |
| 40 |
space gets fragmented. Also, some people keep Windows (and their |
| 41 |
recovery partitions), and with a swap they got already used the four |
| 42 |
extended partition, and some people don't like logical partitions. And |
| 43 |
it's really the same as not wanting an initramfs. |
| 44 |
|
| 45 |
>> Then there are those relatively few people, such as the handful making up |
| 46 |
>> the rest of this thread, who think that these changes are a horrible idea |
| 47 |
>> and will have a severe deterimental affect on their systems. |
| 48 |
> |
| 49 |
> Any added complexity is another thing that can go wrong. |
| 50 |
|
| 51 |
Take that to the limit and then we will still be using only the terminal (no X). |
| 52 |
|
| 53 |
> In the thread on gentoo-dev, I am trying to figure out 3 things: |
| 54 |
> 1) How are the Gentoo Developers planning on adding this new change? |
| 55 |
> 2) What are the options for not having to have an initramfs if the udev-rules |
| 56 |
> used don't actually require /usr and co to be mounted. |
| 57 |
> 3) Get their input in a possible alternative (like fixing the, what I see, |
| 58 |
> design-flaws of udev) |
| 59 |
> |
| 60 |
> On "1", I am actually quite pleased. The actual information I could find |
| 61 |
> previously sounded a lot worse. I've just got a few more questions open based |
| 62 |
> on their answers. Once I have the full picture, I'll post it back here. |
| 63 |
> |
| 64 |
> For "2", I've only just started. I'll also post back here on what my findings |
| 65 |
> are. |
| 66 |
> |
| 67 |
> For "3", I've got some feedback on how udev currently handles things. These |
| 68 |
> actually have given me a few other ways in which to try to "solve" the issue. |
| 69 |
> I'll need to try to find out how udev actually handles the "retry" queue |
| 70 |
> currently. |
| 71 |
|
| 72 |
I also think the discussion in -dev is really good, and I think is |
| 73 |
cleaning the air abot many issues. |
| 74 |
|
| 75 |
>> Not that the relative "size" of the various sides in this debate is really |
| 76 |
>> the issue, but despite the tone of this and the other thread, I don't think |
| 77 |
>> there's really a huge, overwhelming outcry against these changes. |
| 78 |
> |
| 79 |
> I wonder how many are actually aware of these changes. But yes, I think plenty |
| 80 |
> of people will not care and if the Gentoo-devs handle this correctly (which, |
| 81 |
> so far, I think they are) those people won't even notice. |
| 82 |
|
| 83 |
Concur. |
| 84 |
|
| 85 |
> But, there will always be some people who get bitten by this and my reasons |
| 86 |
> for going with parts 1 and 2 is to see how to keep this group as small as |
| 87 |
> possible. |
| 88 |
|
| 89 |
I think most of the Gentoo users, if able to survive the installation, |
| 90 |
are able to deal with almost anything. |
| 91 |
|
| 92 |
Regards. |
| 93 |
-- |
| 94 |
Canek Peláez Valdés |
| 95 |
Posgrado en Ciencia e Ingeniería de la Computación |
| 96 |
Universidad Nacional Autónoma de México |
Archives