[haiku] Re: [GSsC] usermode Haiku or file system development
- From: Stephan Assmus <superstippi@xxxxxx>
- To: haiku@xxxxxxxxxxxxx
- Date: Wed, 07 Apr 2010 15:07:15 +0200
On 2010-04-07 at 14:44:43 [+0200], PulkoMandy <pulkomandy@xxxxxxxxx> wrote:
> Le Wed, 07 Apr 2010 14:19:44 +0200, Lucian Adrian Grijincu
> <lucian.grijincu@xxxxxxxxx> a écrit:
>
> > I'm completely aware of the licensing issue and how distributing code
> > linked to GPL would affect companies using Haiku.
> > IANAL, but I think distributing such a file system driver as a
> > loadable module would not let GPL go viral on the rest of the kernel.
>
> It wouldn't.
> But the choice of making haiku free software was made in a different
> context and thinking than the choice of many other projects. Basically the
> idea was to secure the code so if the project dies (like that hapenned for
> Be, Inc), the code is still there and other people can take over the work.
> Most of the people working on Haiku at that time were not coming from the
> opensource world, but people willing to keep their favourite OS alive, for
> all kinds of different reasons, including being able to sell proprietary
> software for it.
>
> This is the spirit of Haiku : you can contribute to the project and take
> from it the way you want, and we make it possible to use it as a
> closed-source application with all the changes you may need. Thus, we are
> trying to keep gpl code away from the system core.
All correct, but this would be an optional module you can easily remove if
you need to for licensing reasons. I would completely remove the licensing
question from the discussion, since IMHO it is not relevant for an optional
feature. Haiku contains optional components which are GPL right now, so why
even make this a point of the discussion?
> > Such objections were raised for ndiswrapper but some users found value
> > in it.
> > I understand why you don't see this as a morally/ideologically correct
> > solution.
> > I know how convoluted the Linux ext3/4 code can be, especially when
> > you throw journalization into the mix and I have seen problems created
> > by file systems silently eating away data.
> > I don't think it's a clean way to do things either, but I see it as a
> > pragmatic choice: have the functionality here, now and concentrate on
> > the things that make Haiku great.
>
> Well, native support of the filesystems on my hard disk seems like a thing
> that makes haiku great :o)
This is only half the truth from a pragmatic standpoint. I would love to
use NTFS, which has a native driver, but I don't trust it after having read
some pieces of the code, so I don't. Pretty much the same applies to FAT,
although that has much improved due to Romain's work. Filesystems are
especially sensitive to problems in the implementation.
> We are trying to get things done the right way. When I look at linux and
> see things like gnash, with hundreds of dependancies that were not really
> strictly needed, I fear the same may happen to Haiku...
>
> The same holds for ndiswrapper as you say, but also with wine. Wine is
> slightly older but definitely didn't help with linux getting more native
> apps (google applications are tested with it but never get a really native
> port to linux, which in turns lock them from running on a different OS or
> CPU architecture...)
Hm, IMHO some arguemnts don't really apply to the situation at hand. LKL
would only be a dependency if you want to use any of the filesystems it
offers. The CPU architecture argument may be relevant to Google apps and
Wine, but it wouldn't apply to LKL.
After my initial doubts, I am starting to follow Lucian's argumentation.
Each one of us has a different area of interest in the Haiku world. With
some stuff, we are just glad it works and we don't care how. We just want
it to work reliably. For everyone of us who just wants a filesystem to work
reliably, LKL may be a good solution. For the very few who care greatly
about providing a native implementation for a particular FS, with great and
clean code, he can work on it and give LKL one less reason to be used.
After all, we do have a pretty annoying resource problem, where everyone is
already completely overwhelmed by work on so many things.
Best regards,
-Stephan
Other related posts:
