On Wednesday, September 14, 2011 10:30:03 AM Canek Peláez Valdés wrote: > On Wed, Sep 14, 2011 at 1:52 AM, Joost Roeleveld <jo...@antarean.org> wrote: > > On Tuesday, September 13, 2011 06:33:01 PM Canek Peláez Valdés wrote: > >> On Tue, Sep 13, 2011 at 6:10 PM, Michael Schreckenbauer > >> <grim...@gmx.de> > > > > wrote: > >> > If gentoo follows fedora on this mandatory initramfs trail, I'll > >> > switch to FreeBSD completely. My software works on way more > >> > systems than just "Linux". > >> > >> That's of course your prerogative. And, as I said before: "Linux > >> strives to be much more than Unix, and that means do things > >> differently." If you want to do things the same way that it was done > >> in the last 20 years, maybe Linux is not the best of choices. > > > > I read it before, but to be much more then Unix, Linux should be doing > > things better. Being different is what led to MS Windows' > > But that's the thing: we (you and me) don't see the situation the same > way. To me, the proposed changes are for the better.
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. 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) > >> I myself think the new technologies are worth to change the way we did > >> things before. But that's just me. > > > > The new technologies have great merit. But, the implementation of it > > isn't thought through. > > 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. 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. Merging these 2, without properly handling failures, is bad design. Forcing ALL Linux users to use a C-drive is one of the worst design flaws I have ever encountered. Forcing the use of an init* which can leave systems unbootable, is also a design flaw. How do you propose to fix the situation where the init* is broken and someone is unable to mount all the filesystems needed to rebuild the init* because udev, which SHOULD be populating the /dev-tree, refuses to do the single job it is designed to do? Then rethink about the fact that not all computers are easily accessible and/or have cd-drives/usb-ports active. My desktop has them active, my servers don't as I do not need USB on the server. > >> >> And maybe I shouldn't even mention it, but I don't use OpenRC. I > >> >> use > >> >> systemd. And it works great on Gentoo. > >> > > >> > Well. Linux only. If I wanted a monoculture, I would use > >> > MS-Windows or > >> > OSX. > >> > >> Relax man. I mention what I use: I'm not forcing you (or anybody else) > >> to use it. But I repeat (because I said it before) that I care about > >> Linux, and Linux only. > > > > If you care about Linux, why do you allow it to be broken in such a > > fundamental way? > > Again, to me is not "breaking it". To me is "improving it". Adding another SPOF (Single Point Of Failure) is not an improvement. -- Joost
