Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)

[Greg KH]

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.

> 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.

> > 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.

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 :)

> 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