Re: Why do we need lua in-tree again? Yet another call for actual evidence, please. (was Re: Moving Lua source codes)

[Aleksej Saushev <asau%inbox.ru@localhost>]

  Hello,

Lourival Vieira Neto <lourival.neto%gmail.com@localhost> writes:

> On Fri, Oct 18, 2013 at 1:31 PM, Aleksej Saushev <asau%inbox.ru@localhost> 
> wrote:
>> (...)
>>> Lua is a tool, not an end in itself. I think that you are formulating
>>> a chicken-and-egg problem: we need the basic support for then having
>>> applications, and we need applications for then having basic support.
>>
>> The problem with your approach is that such "chicken-and-egg" problems
>> are to be solved _at_once_ rather than laying "eggs" everywhere around
>> and have everyone else wait till at least one "chicken" appears.
>
> No. I'm talking about put just one egg, just a device driver.

Sorry, but this is not "just one egg". "And counting" was your reaction
to complaints that almost all the code related to Lua is the code to
support Lua itself rather than anything else.

>>> Sure, we do not *need* a script language interpreter embedded in the
>>> kernel, as we do not need a specific file system. But I do not get why
>>> we should not. There is current development of applications being done
>>> right now. Also, there is a few interesting works that used Lunatik in
>>> Linux [1, 2] that could be done more easily now in NetBSD just because
>>> we have the right environment for that. That is not about needing, but
>>> it is about supporting a certain kind of agile development,
>>> prototyping, customization and experimentation in the NetBSD kernel
>>> (how could it be hurtful?). I think that is why we *should* (not need)
>>> have this on the tree. IMHO.
>>
>> I have to point out that "interesting work" is commonly used as a sort of
>> euphemism to refer to highly experimental work with unclear future.
>
> Yes. But I'm talking about "interesting *user* work". I'm not claiming
> that they should be in the kernel. I'm just saying that, IMHO, we
> should incorporate a small device driver that facilitates this kind of
> development (outside the tree).

I'm of opinion that this device driver can and should stay outside the tree
until its utility can be demonstrated without this much strain.
At last this is one of the reasons why we support kernel modules.

>> You tell that there's "interesting work" using Lua in Linux.
>> Was it accepted in any experimental Linux distribution like Fedora?
>> What was the outcome of discussion among linux kernel developers?
>> Currently there's no indication that it was accepted anywhere.
>
> Really don't know. I'm not a member of these communities neither I'm
> claiming to incorporate such works here. However, I think that there
> was a discussion about PacketScript on OpenWRT, but I don't know how
> it evolved.

This demonstrates that Lua isn't actually useful in the kernel.

>> I doubt very much that we want such unreliable development practices
>> like "agile" ones in the kernel, and experimentation work can be done
>> easier and better in a branch or a personal repository.
>
> I agree with you in this point: experimental work should be done aside
> from the tree.
>
>> And last. The appeal to "why not" is defective. NetBSD is not your
>> personal playground, there exist other people who have to deal with
>> the inadvertent mess you can leave after you. That's why you ought
>> to present solid arguments that justify why other people should tolerate
>> your experimentations.
>
> I guess you misunderstood that. I'm not arguing that we should do it
> just because there is no contrary argument. I sincerely asked 'why
> not?' trying to understand the contrary argumentation. Also, I'm not
> saying that you should tolerate my experimentation. Far away from
> that. I haven't committed anything nor tried to impose nothing.

On my side it sounded like that, sorry, if I'm wrong.

> I'm
> just trying to make a  point of view and understand yours. When I
> talked about experimentation, I was trying to say that providing
> support for that kind of experimentation for users sounds a good idea
> for me and I don't see how it is prejudicial. Which doesn't mean that
> I'm proposing that my personal experimentation should be in tree.

The problem as I see it is that we have one developer (two at most)
pushing hard for Lua in base and in kernel and providing no satisfactory
arguments why this is to be done at all. Lack of any real code for years
reinforces such doubts.

"Why not" sounds as an argument for highly experimental work in this context.
And I wouldn't have anything against this "why not" if all the work were
dressed accordingly. For now I'd say that Lua support hasn't demonstrated
any benefit. I'd say that it should be removed and the work continued
in a branch until benefits become more clear.


-- 
BCE HA MOPE!