| 1 |
On Thu, Sep 15, 2011 at 3:01 AM, Joost Roeleveld <joost@××××××××.org> wrote: |
| 2 |
> There are not many people who agree with you here. |
| 3 |
> The changes will lead to a C:-drive, similar to MS Windows, where everything |
| 4 |
> has to be a single partition. |
| 5 |
|
| 6 |
Technically, this isn't true. %PROGRAMFILES need not be on |
| 7 |
%SYSTEMDRIVE%. %PROGRAMFILES(x86)% need not be on the same drive as |
| 8 |
%PROGRAMFILES%. I believe most of the system key locations are allowed |
| 9 |
to be in disparate locations. |
| 10 |
|
| 11 |
> For various reasons, using seperate partitions are a better solution: |
| 12 |
> - It allows for the use of filesystems better suited to the type of files and |
| 13 |
> usage on each partition. |
| 14 |
> - It prevents a single part of the filesystem to kill the entire system. (I |
| 15 |
> can risk loosing 1 partition and not loose the rest of my data) |
| 16 |
|
| 17 |
Fully concur. |
| 18 |
|
| 19 |
>> In my humble opinion, what you just said is a little pedantic. You can |
| 20 |
>> disagree with the proposed changes, you can argue why you think |
| 21 |
>> another approach could be better. But just saying "the implementation |
| 22 |
>> of it isn't thought through", is a little insulting to the devs. I |
| 23 |
>> think they though about the implementation a lot. |
| 24 |
> |
| 25 |
> They may have thought about it, but didn't think things through. |
| 26 |
> I have already stated a better way of doing it in the past few days. I will |
| 27 |
> repeat it here. |
| 28 |
> |
| 29 |
> The problem-scope that udev is TRYING to solve should NOT be solved in a |
| 30 |
> single tool. |
| 31 |
|
| 32 |
Concur. |
| 33 |
|
| 34 |
> The main purpose of udev is to populate the /dev-tree. |
| 35 |
> The running of scripts based on /dev-tree events should be in a seperate tool |
| 36 |
> that starts later in the boot-process. |
| 37 |
|
| 38 |
I'm not *entirely* convinced this is the case, because it feels like |
| 39 |
some situations like network devices (nbd, iSCSI) or loopback would |
| 40 |
require userland tools to bring up once networking is up. |
| 41 |
|
| 42 |
> Merging these 2, without properly handling failures, is bad design. |
| 43 |
|
| 44 |
Concur. |
| 45 |
|
| 46 |
>> Again, to me is not "breaking it". To me is "improving it". |
| 47 |
> |
| 48 |
> Adding another SPOF (Single Point Of Failure) is not an improvement. |
| 49 |
|
| 50 |
Concur. |
| 51 |
|
| 52 |
-- |
| 53 |
:wq |
Archives