On Sat, Nov 17, 2012 at 10:49 PM, Greg KH <gre...@gentoo.org> wrote: > On Sun, Nov 18, 2012 at 12:35:22AM -0500, Richard Yao wrote: >> On 11/18/2012 12:19 AM, Greg KH wrote: >> > On Sun, Nov 18, 2012 at 12:00:52AM -0500, Richard Yao wrote: >> >>> I'm genuinely interested in your goals, in detail, otherwise I would >> >>> not have asked about them. Perhaps I am totally wrong and your fork >> >>> makes sense, perhaps, to me, not. But without knowing such goals, >> >>> there's no way that anyone can get an idea about this. >> >> >> >> I am afraid that I have to disappoint you. If we were using the >> >> waterfall model, I could outline some very nice long term goals for you, >> >> but we are doing AGILE development, so long term goals have not been >> >> well defined. Some short term goals have been defined, but I imagine >> >> that you are already familiar with them. I suggest asking again after >> >> our first tag. >> > >> > I'll ignore the fact that project goals have nothing to do with >> > waterfall or agile, and ask, what are your short-term goals? >> > >> > Why is this an "official" Gentoo project without this being discussed in >> > an open manner? >> >> We are in the process of getting started. If you read my original email, >> you would know that the announcement was supposed to occur relatively >> soon. The reason I sent it was because the Gentoo Council meeting >> required something be sent sooner than we were ready. > > The "announce later, act first" seems like a new move for the Gentoo > Council to be taking. Is this really an official act that the council > is approving? > > Why wait to announce a project that is being hosted on a Gentoo account, > with Gentoo Foundation copyrights on them? I don't understand the > delay. > >> >>> Wait, what? The kmod introduction was deliberate and solves a real >> >>> problem. kmod itself was created _because_ of these issues that had >> >>> been seen and found. It was written for the systemd/udev projects to >> >>> use, and had been worked on for a long time by a number of developers. >> >>> By removing it, you have now negated that solution and we are back to >> >>> the old problems we had before. That doesn't seem very wise to me, does >> >>> it to you? >> >>> >> >>> thanks, >> >>> >> >>> greg k-h >> >> >> >> Having a builtin is a good idea, but the implementation as a mandatory >> >> dependency on kmod is not. The plan is to reintroduce it as an optional >> >> dependency, so that distributions (and Gentoo users) that do not want it >> >> can avoid it. None of us want to force dependencies on others and there >> >> is no need for this one. >> > >> > You do realize that you didn't really drop the dependency at all, right? >> >> kmod does not exist on my system and eudev builds without a problem. > > Are you using busybox to load your kernel modules? Are you saying that > this is something that will be required here? > > Or is this change because you want to use busybox to load your modules? > If so, why not just use mdev instead of udev at all? That's what mdev > was created for, busybox-like systems that don't want the "heavy" udev > on them. > >> I am thinking of writing my own busybox-style code to handle module >> loading in the builtin when the configure script is told not to build >> with kmod. Does this not avoid the dependency? > > So we will now have 3 different Linux kernel loaders floating around? > What's wrong with using kmod in the first place? What does it do that > is so wrong? > > And again, back to my original point above, you have reintroduced the > problem that kmod solved. How is that good? > >> >> With that said, Linux distributions are victims of people continually >> >> trying to reinvent the wheel with no formal planning. >> > >> > Huh? Really? It's as if you think we all are just throwing stuff >> > against the wall and seeing what sticks? We aren't responding to real >> > users, customers, research, history, and competitors? Your dismissal of >> > the people who create the system you are using seems pretty bold. >> >> The result of what the existing people have been doing has been the >> equivalent of throwing stuff against the wall for many of us. > > Really? What, specifically, is wrong with the existing systemd solution > that you have a problem with? Specifics please, otherwise they can't be > fixed. >
So I'm pretty sure the concerns were laid out in other threads. 1) systemd-udev will require systemd. Stated by the systemd maintainers themselves as a thing they want to do in the future. Some users don't want to use systemd. We could go into detail as to why; but I think that is not as important as one may think. The point is that the desire is there, and thusly there are users who want to make other systems (namely openrc) work. People like openrc. My VMs for instance, boot reasonably quickly. Booting 5 seconds faster may be super duper, but not at the cost of an existing reliable solution. >> We have decided to try doing things ourselves to see if we can do >> better. We think we can. > > That's wonderful, seriously. But why is this suddenly an official > Gentoo project? When did that happen, and why? Why not just do a > "normal" project and if it matures and is good enough, then add it to > the distro like all other packages are added. > > My main point here is the fact that this is now being seen as an act by > Gentoo, the distro / foundation. And that happened in private, without > any anouncement. Which is not good on many levels. I'm unsure on what grounds you disapprove. People start (and abandon) projects often in Gentoo. Suddenly you dislike one such project and object to this practice? Certainly if we had to get some sort of Foundation consensus (for anything) nothing would happen. We can't even get more than 40% of foundation members to vote. > >> > Have you studied the problem area for booting, process monitoring, >> > system isolation, device creation and notification, persistant naming, >> > multiple users with multiple displays, and the like, and found that >> > Linux is lacking in this area? If so, I would love to learn more, as I >> > want Linux, and Gentoo, to succeed. Without knowing the problems you >> > are having, there's no way anyone will ever change. >> >> We already have OpenRC, which has been found to work well on both Gentoo >> Linux and Gentoo FreeBSD. The integration of udev into systemd has >> caused problems for existing OpenRC systems with people being told that >> it is okay to break configurations that users had been told to use over >> well over a decade. Many of us consider that to be unacceptable. > > Part of the goal of systemd is to unify all Linux distros startup logic, > and configuration logic, to make things unified to help a whole lot of > things happen better and faster in the end. It is a move to save > effort, and, is succeeding quite well. If Gentoo does not wish to > participate in this effort, then those of us who are participating in > it, and are Gentoo developers, should be told this so that we can decide > what we wish to do. You presume Gentoo acts as a whole. This is almost never true. Just because we host the project, and gentoo staffs the project, or even that the copyright is on the project, doesn't mean 'we reached a consensus and decided systemd sucks.' Certainly the existing sytemd maintainer in Gentoo doesn't think so. However a number of folks *do* think so, and are willing to put effort into it. I'm unsure why we should prevent them from doing so. For the guy who earlier claimed that forking was great and encouraged it; I am confused as to why it is suddenly discouraged now. > > OpenRC is great, and has worked well for 10+ years. But seriously, it > is creaky in places, and doesn't do much at all compared to what systemd > offers. If Gentoo wants to ignore systemd, it does so at its own peril. > > Oh, and systemd has nothing to do with the /usr issue, don't ever get > that confused. A separate /usr broke a long time ago, systemd just now > shows you how broken your system really was, and you didn't notice it :) I agree I think folks think they can solve this with udev. I think even the early patches to try to 'fix' it are going to teach them that it is perhaps harder than they know. Perhaps they are merely inexperienced, and they will learn from the effort. > >> Anyway, results are what are important. If you are interested in what we >> are doing, then I suggest coming back in a month to see what we have >> produced. > > Why a month? Where did that deadline come from? > > And again, the main question that has never been answered yet, "What are > you trying to do here?" > > thanks, > > greg k-h >
