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