better install experience

Thu Oct 11 14:28:04 UTC 2007

On 11/10/2007, Szabolcs Szakacsits <szaka at ntfs-3g.org> wrote:
>
>
> On 10/10/2007, Christopher Brown wrote:
> >     On Wed, 2007-10-10 at 23:02 +0200, Thorsten Leemhuis wrote:
> >
> > >    There are two ntfs implementations. One is old, crufted, and poorly
> > >    maintained.

Not sure what is to blame here but Thorsten didn't write that, Spot did.

>
> > Sorry but that is bullshit. Old and crufted aren't very good technical
>
> As I mentioned previously, the kernel driver and ntfs-3g have the same
> source base. When I developed ntfs-3g then I noted the potentially serious
> problems in the kernel (e.g. in truncate). I also mentioned them to Dave
> Jones. I never got a reply for any of my emails.

You're surprised by that?

Recently a buffer overflow
> was discovered (Andrew Morton fixed it), driver hangs during logfile reset
> (maintainer made a patch).

I'm sorry I can't see the relevance of this as an argument. Both issues were
fixed, one by the maintainer. What's the problem?

It seems as the kernel evolves, the kernel NTFS driver isn't adjusted as
> Miklos Szeredi does for the FUSE kernel module, so the kernel side of the
> NTFS-3G driver can stay safe, deadlock and corruption free, no need to
> worry about it. He is also extremely responsive both design and
> troubleshooting discussions and quality coding wise. He is employed by
> Novell and allowed to work on FUSE in a certain amount of his work time.

I'm mad keen to see figures of enterprise installations running FUSE over
kernel drivers. I mean _really_ keen.

> arguments and poorly maintained is simply untrue.
>
> The maintainer has been working for a non-Linux company since 2005 and
> from
> that point his open source contribution and leadership role is minimal.

Here we agree.

I've worked with him 4 years when it was decided finally a year ago that a
> partial fork is needed to ensure driver reliability and maintainability.

Partial? Could you define this? Please remember that I was/am a member of
the linux-ntfs project and although my contribution was only in the package
department for Rich Russon when he was around, there was nothing to indicate
you were intending to fork. and even then there was no real reason given in
your announcement that you were doing it for the above purpose.

For example we (linux-ntfs team at that time) were reported that some ntfs
> utilities made Vista unbootable. The reason was found and fixed a year
> ago,
> still the official bugfix was released only 10 days ago. The serious fix
> was sitting in the CVS for a year.

Whats wrong with bugging Linus to get it applied then? I'm having a hard
time believe crucial fixes sit in cvs simply because someone wont write an
email saying "Linus, please apply...". If Anton wont sign off (or comment)
then I'm inclined to agree the driver is dead in the water but it doesn't
look like this happened.

Obviously everybody thinks differently what is "poorly maintained". For me
> the above is one sign, amongst several others.
>
> > If this boils down to "It doesn't have write support, bwaaaaaaaah" then
> > "poorly maintained" isn't much of one either. The reason there have been
> > so few git commits is because it works fine in the state that its in and
> > as I explained, the core developer is focused mainly on the new driver
> > which, license debates aside, will be released in about a year.
>
> In 2005, we were offered NTFS code in favour of letting a company use and
> dual licence what we have developed. Then it became 2006 then the story
> changed a bit then the date was 2007 and then 2008.

True and I agree that actions speak louder than words. My original point was
that I believe Fedora should ship with the ntfs kernel driver enabled,
mount.ntfs should actually be named mount.ntfs-3g and to try and point out
the difference between functionality and stability - quite important where
filesystems are concerned.

>     Dave asked me for my opinion, and I said that we shouldn't ship
> >     something that's not recommended by one of its authors, and has no
> >     real maintenance upstream:
> >
> >     http://ntfs-3g.org/about.html

It would probably benefit from having any post-fork detail removed. As it
currently stands it might be interpreted that the reason for the fork was
the the kernel driver was not going to be released until 2008. I'm still at
a loss as to why you forked but then I was not privy to conversations that
went on behind the scenes perhaps.

> who spat the dummy and went off and created ntfs-3g when he could have
> > merged it with ntfsprogs.

My apologies, this was rude.

Here is my original announcement:
>
>
> http://sourceforge.net/mailarchive/message.php?msg_id=Pine.LNX.4.21.0607141859080.31588-100000%40mlf.linux.rulez.org
>
> I did the work as a long time Linux-NTFS project member. There wasn't
> __anything__ to merge. The work itself was Linux-NTFS, so in fact I
> __did__
> merge it when I published it. The code could have been just used without
> any change. I was the only one working on write support and there wasn't
> really anything to merge with because they were already included.
>
> After two-three months later the project still wasn't going the way it
> should have hereby the fork was made.

The announcement came without warning - this is my issue. It would've been
nice to have seen a "I'm thinking of forking because of a, b, c etc. Can
anything be done?". So yeah, I'm a little sad that the project split and now
confusion reigns.

> It actually has nothing to do with the kernel driver.
>
> As I wrote, it has quite a lot, in fact.
>

Please stop editing the posts like this; it is really bad form. NTFS-3g is
separate and distinct from the kernel driver. One is not reliant on the
other but perhaps you misunderstood me.

Please don't take this as criticism of ntfs-3g - I think it was a long time
(too long) in coming and enables lots of interesting things to happen. Keep
up the excellent work - I'm all in favour of choice which is what the
original argument was all about.

Cheers
Chris

-- 
http://www.chruz.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071011/f0104acf/attachment.htm>