Why the DOS has many ntfs read and write driver,but the linux can't for a long time

Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Boxer Gnome]

and the dos ntfs driver was not released by the MS offical.So,what' wrong?

Somebody who can explain this ?

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Erik Andersen]

On Mon Jan 09, 2006 at 03:54:24PM +0800, Boxer Gnome wrote:
> and the dos ntfs driver was not released by the MS offical.So,what' wrong?
> 
> Somebody who can explain this ?

Sure, thats easy.  You havn't paid Anton and Richard to quit
their jobs to work full time on finishing full linux ntfs
support.  It is really quite amazing how many "linux can't do foo"
type problems could be quickly solved by sending large amounts of
money to the right people.

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Boxer Gnome]

2006/1/9, Erik Andersen <andersen@codepoet.org>:
> On Mon Jan 09, 2006 at 03:54:24PM +0800, Boxer Gnome wrote:
> > and the dos ntfs driver was not released by the MS offical.So,what' wrong?
> >
> > Somebody who can explain this ?
>
> Sure, thats easy.  You havn't paid Anton and Richard to quit
> their jobs to work full time on finishing full linux ntfs
> support.  It is really quite amazing how many "linux can't do foo"
> type problems could be quickly solved by sending large amounts of
> money to the right people.
>
>  -Erik
>
> --
> Erik B. Andersen             http://codepoet-consulting.com/
> --This message was written using 73% post-consumer electrons--
>
But the dos' ntfs drive was free software,no ne need pay.

I see, the ntfs' spec is not so hard to know.I always think it hard to
be supported before, for the ntfs' spec belongs to MS.

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Jim Crilly]

On 01/09/06 04:21:49PM +0800, Boxer Gnome wrote:
> 2006/1/9, Erik Andersen <andersen@codepoet.org>:
> > On Mon Jan 09, 2006 at 03:54:24PM +0800, Boxer Gnome wrote:
> > > and the dos ntfs driver was not released by the MS offical.So,what' wrong?
> > >
> > > Somebody who can explain this ?
> >
> > Sure, thats easy.  You havn't paid Anton and Richard to quit
> > their jobs to work full time on finishing full linux ntfs
> > support.  It is really quite amazing how many "linux can't do foo"
> > type problems could be quickly solved by sending large amounts of
> > money to the right people.
> >
> >  -Erik
> >
> > --
> > Erik B. Andersen             http://codepoet-consulting.com/
> > --This message was written using 73% post-consumer electrons--
> >
> But the dos' ntfs drive was free software,no ne need pay.

Only the read-only version is monetarily free.

> I see, the ntfs' spec is not so hard to know.I always think it hard to
> be supported before, for the ntfs' spec belongs to MS.

Do you mean NTFSDOS from SysInternals? If so, look at it again and you'll
see that it uses the NTFS.sys and NTOSKRNL.exe files from an NT
installation. They worked around the need to understand the filesystem by
just writing a wrapper for the NTFS driver that MS released. And if you
care to trust that sort of wrapper take a look at CaptiveNTFS and you'll
see the exact same thing for Linux, except you don't have to pay for write
support with CaptiveNTFS. You just have to pray that it works right.

Jim.

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Yaroslav Rastrigin]

Hi, Eric, 
On 9 January 2006 11:06, Erik Andersen wrote:
> On Mon Jan 09, 2006 at 03:54:24PM +0800, Boxer Gnome wrote:
> > and the dos ntfs driver was not released by the MS offical.So,what' wrong?
> > 
> > Somebody who can explain this ?
> 
> Sure, thats easy.  You havn't paid Anton and Richard to quit
> their jobs to work full time on finishing full linux ntfs
> support.  It is really quite amazing how many "linux can't do foo"
> type problems could be quickly solved by sending large amounts of
> money to the right people.
Could or would you be so kind to provide at least moderately complete pricelist ? Whom and how much should I pay to have correct support for
intel graphics chipset, 2200BG Wi-Fi, complete suspend-to-disk/suspend-to-ram and to get an overall performance boost ? 

-- 
Managing your Territory since the dawn of times ...

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Alistair John Strachan]

On Monday 09 January 2006 09:07, Yaroslav Rastrigin wrote:
> Hi, Eric,
>
> On 9 January 2006 11:06, Erik Andersen wrote:
> > On Mon Jan 09, 2006 at 03:54:24PM +0800, Boxer Gnome wrote:
> > > and the dos ntfs driver was not released by the MS offical.So,what'
> > > wrong?
> > >
> > > Somebody who can explain this ?
> >
> > Sure, thats easy.  You havn't paid Anton and Richard to quit
> > their jobs to work full time on finishing full linux ntfs
> > support.  It is really quite amazing how many "linux can't do foo"
> > type problems could be quickly solved by sending large amounts of
> > money to the right people.
>
> Could or would you be so kind to provide at least moderately complete
> pricelist ? Whom and how much should I pay to have correct support for
> intel graphics chipset, 2200BG Wi-Fi, complete
> suspend-to-disk/suspend-to-ram and to get an overall performance boost ?

Since these are all supported in 2.6.15, $0 would be my quote.

-- 
Cheers,
Alistair.

'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Yaroslav Rastrigin]

Hi, 
> > > money to the right people.
> >
> > Could or would you be so kind to provide at least moderately complete
> > pricelist ? Whom and how much should I pay to have correct support for
> > intel graphics chipset, 2200BG Wi-Fi, complete
> > suspend-to-disk/suspend-to-ram and to get an overall performance boost ?
> 
> Since these are all supported in 2.6.15, $0 would be my quote.
I've mentioned _correct_ support. Contrary to current rather sad state of things. 
855GM still has no support for non-VESA videomodes (1280x800 can be enabled only via VBIOS hacks, and is not always properly restored on resume) 
(and don't supported with intelfb) (which, AFAIK, has no support for dualhead)
2200BG sometimes starts to unacceptably lag and drop packets after going out of suspend (either STR or STD) and until reboot.
(And this is driver issue)
Suspend to ram works, more or less, but drains power like hungry cat drinks milk, and I just can't leave my laptop in STR for more than two days 
without worrying about my on-the-road availability. 
Suspend to disk has nasty tendency to ruin my whole hot live X session, since X can't properly restore VT on resume.
Overall performance isn't that bad, either, but I just can't understand, why KATE (Kde more or less advanced editor) takes twice as long to start 
as UltraEdit in _emulated_ (VMWare) Windows XP running on this same box.

So, the question remains the same - whom and how much I need to pay to solve abovementioned problems ?

-- 
Managing your Territory since the dawn of times ...

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[CaT]

On Mon, Jan 09, 2006 at 02:03:46PM +0300, Yaroslav Rastrigin wrote:
> Suspend to disk has nasty tendency to ruin my whole hot live X session, since X can't properly restore VT on resume.

Not necessarily a solution but have you thought of putting chvt in the
suspend/resume sequence? chvt to a terminal before suspending and chvt
to X after resume.

This was one of the things I used to do when I had BIOS suspend to disk
working (it was nice but then gateway *spit* decided to remove it in a
bios upgrade).

Still, the above might help you until you find someone to throw money
at. ;)

-- 
    "To the extent that we overreact, we proffer the terrorists the
    greatest tribute."
    	- High Court Judge Michael Kirby

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Yaroslav Rastrigin]

Hi, 
On 9 January 2006 15:45, CaT wrote:
> On Mon, Jan 09, 2006 at 02:03:46PM +0300, Yaroslav Rastrigin wrote:
> > Suspend to disk has nasty tendency to ruin my whole hot live X session, since X can't properly restore VT on resume.
> 
> Not necessarily a solution but have you thought of putting chvt in the
> suspend/resume sequence? chvt to a terminal before suspending and chvt
> to X after resume.
Yes, of course. I've spent countless hours trying to figure solution for this particular problem. Tried generic Linux suspend-to-disk and swsusp2, 
changing terminals before/after suspend, delay sleeps, vbetool and all that fuss and jazz. Looks like race condition somewhere between kernel and X driver.
> 
> Still, the above might help you until you find someone to throw money
> at. ;)
Ahhh. Sweet dream - to be able to offer money to fix extremely annoying bugs or to add missing features. 
Unfortunately, bounties doesn't work :-/ 
> 

-- 
Managing your Territory since the dawn of times ...

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Helge Hafting]

Yaroslav Rastrigin wrote:

>Ahhh. Sweet dream - to be able to offer money to fix extremely annoying bugs or to add missing features. 
>Unfortunately, bounties doesn't work :-/ 
>  
>
Depends on how much money you have to offer.  If you have the resources 
to hire
a programmer full-time until your favourite problem is solved - no 
problem I think.

If funding development alone is a bit much, consider starting with one
particular problem and try collecting money from other interested
people. 

Money can surely get the work done - but then you usually have to pay
enough that the programmer can make a living while working for you.
The cheap alternative is enthusiasts who will write a hardware driver if 
they get
the hw for free. 

Helge Hafting

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Randy.Dunlap]

On Tue, 10 Jan 2006, Helge Hafting wrote:

> Yaroslav Rastrigin wrote:
>
> >Ahhh. Sweet dream - to be able to offer money to fix extremely annoying bugs or to add missing features.
> >Unfortunately, bounties doesn't work :-/
> >
> >
> Depends on how much money you have to offer.  If you have the resources
> to hire
> a programmer full-time until your favourite problem is solved - no
> problem I think.

Well, some docs would usually be very helpful.  Reverse engineering
is usually too slow IMO.

> If funding development alone is a bit much, consider starting with one
> particular problem and try collecting money from other interested
> people.
>
> Money can surely get the work done - but then you usually have to pay
> enough that the programmer can make a living while working for you.
> The cheap alternative is enthusiasts who will write a hardware driver if
> they get
> the hw for free.

-- 
~Randy

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[David Nicol]

On 1/9/06, Yaroslav Rastrigin <yarick@it-territory.ru> wrote:

> Unfortunately, bounties doesn't work :-/


No?  Bounties seems to work fine for Asterisk.  Is the problem, still no central
linux kernel bounty system?


--
David L Nicol
high on complexity

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Lee Revell]

On Tue, 2006-01-10 at 20:29 -0600, David Nicol wrote:
> On 1/9/06, Yaroslav Rastrigin <yarick@it-territory.ru> wrote:
> 
> > Unfortunately, bounties doesn't work :-/
> 
> 
> No?  Bounties seems to work fine for Asterisk.  Is the problem, still no central
> linux kernel bounty system?


Many bounties don't work because they are too low, too vague or both.
For example several months ago Ubuntu offered $500 to "fix all remaining
ALSA issues for PowerMac hardware".  HA!  That's like 5 or 6 diffent
drivers which ranged from not working at all, to sound works but no
system beeps, etc...

Lee

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[David Nicol]

On 1/10/06, Lee Revell <rlrevell@joe-job.com> wrote:
> On Tue, 2006-01-10 at 20:29 -0600, David Nicol wrote:
> > On 1/9/06, Yaroslav Rastrigin <yarick@it-territory.ru> wrote:
> >
> > > Unfortunately, bounties doesn't work :-/
> >
> >
> > No?  Bounties seems to work fine for Asterisk.  Is the problem, still no central
> > linux kernel bounty system?
>
>
> Many bounties don't work because they are too low, too vague or both.
> For example several months ago Ubuntu offered $500 to "fix all remaining
> ALSA issues for PowerMac hardware".  HA!  That's like 5 or 6 diffent
> drivers which ranged from not working at all, to sound works but no
> system beeps, etc...
>
> Lee


How did they offer this bounty?  Through the ubuntu announcements channels?

Like if, say, Linux International was to partner with TipJar.com to create
and maintain an organized open bounty system where stakeholders wanting
to see something could contribute to the pot for the feature and the first
implementor who passes the tests (including code readability!) gets the pot.

Write me off-list to become involved in this project or to direct me to
an already existing project so I don't waste more time on wheel reinvention?

David "tipjar" Nicol


--
David L Nicol
awrsagfagoijneaghnjhda

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Lee Revell]

On Thu, 2006-01-12 at 12:53 -0600, David Nicol wrote:
> On 1/10/06, Lee Revell <rlrevell@joe-job.com> wrote:
> > On Tue, 2006-01-10 at 20:29 -0600, David Nicol wrote:
> > > On 1/9/06, Yaroslav Rastrigin <yarick@it-territory.ru> wrote:
> > >
> > > > Unfortunately, bounties doesn't work :-/
> > >
> > >
> > > No?  Bounties seems to work fine for Asterisk.  Is the problem, still no central
> > > linux kernel bounty system?
> >
> >
> > Many bounties don't work because they are too low, too vague or both.
> > For example several months ago Ubuntu offered $500 to "fix all remaining
> > ALSA issues for PowerMac hardware".  HA!  That's like 5 or 6 diffent
> > drivers which ranged from not working at all, to sound works but no
> > system beeps, etc...
> >
> > Lee
> 
> 
> How did they offer this bounty?  Through the ubuntu announcements channels?
> 
> Like if, say, Linux International was to partner with TipJar.com to create
> and maintain an organized open bounty system where stakeholders wanting
> to see something could contribute to the pot for the feature and the first
> implementor who passes the tests (including code readability!) gets the pot.
> 
> Write me off-list to become involved in this project or to direct me to
> an already existing project so I don't waste more time on wheel reinvention?

Heh, I only found out about it when some Ubuntu user mentioned it in an
ALSA bug report.  I guess they just expect people to find them somehow.
So yes, there needs to be a single, central resource for OSS bounties.

I think a lot of these problems with the PPC drivers were later solved.
But my point was really that $500 was not nearly enough for the amount
of work that would have been required.  It's a nice bonus for someone
who would have done it for free anyway but I was under the impression
that bounties were created to solve problems too tricky or unrewarding
or uninteresting for someone to do for free.

Lee

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Kasper Sandberg]

On Mon, 2006-01-09 at 14:03 +0300, Yaroslav Rastrigin wrote:
> Hi, 
> > > > money to the right people.
> > >
> > > Could or would you be so kind to provide at least moderately complete
> > > pricelist ? Whom and how much should I pay to have correct support for
> > > intel graphics chipset, 2200BG Wi-Fi, complete
> > > suspend-to-disk/suspend-to-ram and to get an overall performance boost ?
> > 
> > Since these are all supported in 2.6.15, $0 would be my quote.
> I've mentioned _correct_ support. Contrary to current rather sad state of things. 
> 855GM still has no support for non-VESA videomodes (1280x800 can be enabled only via VBIOS hacks, and is not always properly restored on resume) 
> (and don't supported with intelfb) (which, AFAIK, has no support for dualhead)
> 2200BG sometimes starts to unacceptably lag and drop packets after going out of suspend (either STR or STD) and until reboot.
> (And this is driver issue)
> Suspend to ram works, more or less, but drains power like hungry cat drinks milk, and I just can't leave my laptop in STR for more than two days 
> 
> without worrying about my on-the-road availability. 
> Suspend to disk has nasty tendency to ruin my whole hot live X session, since X can't properly restore VT on resume.
> Overall performance isn't that bad, either, but I just can't understand, why KATE (Kde more or less advanced editor) takes twice as long to start 
> as UltraEdit in _emulated_ (VMWare) Windows XP running on this same box.
i can not take this seriously.. on both my laptop and workstation, the
kate window is up in less than a second after i either run kate from a
terminal, or select it in the kde menu..

unless ofcourse you are not using kde, and kate is the first kde
application you start, then it will need to load much more than simply
kate, at which point you cant really say what you are doing, since it
would be somewhat like comparing half of windows's startup time +
ultraedit startup time to kate startup time...

> 
> So, the question remains the same - whom and how much I need to pay to solve abovementioned problems ?
> 

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Yaroslav Rastrigin]

Hi, Kasper,
> > without worrying about my on-the-road availability. 
> > Suspend to disk has nasty tendency to ruin my whole hot live X session, since X can't properly restore VT on resume.
> > Overall performance isn't that bad, either, but I just can't understand, why KATE (Kde more or less advanced editor) takes twice as long to start 
> > as UltraEdit in _emulated_ (VMWare) Windows XP running on this same box.
> i can not take this seriously.. on both my laptop and workstation, the
> kate window is up in less than a second after i either run kate from a
> terminal, or select it in the kde menu..
Well, I could find more or less reasonable explanation of this behaviour - different VM policies of two OSes and 
strangely strong and persistent belief "Free RAM is a wasted RAM" among kernel devs. Free RAM is not a wasted RAM, its a memory waiting to be used ! 
Whenever it is needed by apps I'm launching or working with. 
> 
> unless ofcourse you are not using kde, and kate is the first kde
> application you start, then it will need to load much more than simply
> kate, at which point you cant really say what you are doing, since it
> would be somewhat like comparing half of windows's startup time +
> ultraedit startup time to kate startup time...
No. Fully loaded KDE session (without kdesktop and kwin, since I don't use first and using my own WM instead of second).
So almost all necessary libraries are hot and loaded, and all what's missing is a dozen of Window's and Pixmap's to allocate and two threads to 
handle events. And it takes seconds, not tens of a second, as in UltraEdit case 
> 
> > 
> > So, the question remains the same - whom and how much I need to pay to solve abovementioned problems ?
> > 
> 
> 

-- 
Managing your Territory since the dawn of times ...

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Alan Cox]

On Llu, 2006-01-09 at 16:56 +0300, Yaroslav Rastrigin wrote:
> No. Fully loaded KDE session (without kdesktop and kwin, since I don't
> use first and using my own WM instead of second).
> So almost all necessary libraries are hot and loaded, and all what's
> missing is a dozen of Window's and Pixmap's to allocate and two
> threads to 
> handle events. And it takes seconds, not tens of a second, as in
> UltraEdit case 


Currently Linux performance loading large binaries is at least
perceptually worse than Windows (some of that is perceptual tricks
windows apps pull, some of it real). There is an openoffice.org related
analysis project currently under way to sort that out.

A second problem is the popularity of some very inefficiently written
desktops which badly need a good optimise, a diet and/or stuffing where
the sun doesn't shine. The kernel can only do so much of the work and
comparing xfce4 with gnome/kde shows that the kernel isn't the only
party involved in this....

Alan

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Lee Revell]

On Mon, 2006-01-09 at 16:07 +0000, Alan Cox wrote:
> Currently Linux performance loading large binaries is at least
> perceptually worse than Windows (some of that is perceptual tricks
> windows apps pull, some of it real). 

Would you care to elaborate on this statement?  It's not clear to me how
perception could differ from reality in this case.  If it seems faster
doesn't that mean it is faster?

Lee

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Alan Cox]

On Llu, 2006-01-09 at 11:15 -0500, Lee Revell wrote:
> Would you care to elaborate on this statement?  It's not clear to me how
> perception could differ from reality in this case.  If it seems faster
> doesn't that mean it is faster?

Depends who is measuring and what is being measured. 

If you want to understand how to make the kernel faster you care about
real speed changes. Application authors may well want to look at
perceptual tricks (like splash screens, opening windows early before you
have the code even loaded to do much else etc)

Alan

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Olivier Galibert]

On Mon, Jan 09, 2006 at 11:15:12AM -0500, Lee Revell wrote:
> On Mon, 2006-01-09 at 16:07 +0000, Alan Cox wrote:
> > Currently Linux performance loading large binaries is at least
> > perceptually worse than Windows (some of that is perceptual tricks
> > windows apps pull, some of it real). 
> 
> Would you care to elaborate on this statement?  It's not clear to me how
> perception could differ from reality in this case.  If it seems faster
> doesn't that mean it is faster?

You can have a window opened without being ready to accept input yet
for instance.  XEmacs does that[1] when it opens its window before
parsing the user's configuration which can load a number of things and
hence take a while to run.  "Ok I'm going to open your application"
animations allow to win some perceptual time too.

Humans are fundamentally easy to fool for 1-2 seconds as long as they
have feedback.  Longer gets harder :-)

  OG.

[1] For technical reasons, not perceptual.

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Diego Calleja]

El Mon, 09 Jan 2006 16:07:07 +0000,
Alan Cox <alan@lxorguk.ukuu.org.uk> escribió:

> Currently Linux performance loading large binaries is at least
> perceptually worse than Windows (some of that is perceptual tricks
> windows apps pull, some of it real). There is an openoffice.org related
> analysis project currently under way to sort that out.

Desktop performance has become a such hot topic that I wonder if
it would be worth to setup a dedicated mailing list somewhere
where all the parts involved (kernel, kde/gnome, x.org, libc) can
analyze what are the real problems are.

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Lee Revell]

On Mon, 2006-01-09 at 20:24 +0100, Diego Calleja wrote:
> El Mon, 09 Jan 2006 16:07:07 +0000,
> Alan Cox <alan@lxorguk.ukuu.org.uk> escribió:
> 
> > Currently Linux performance loading large binaries is at least
> > perceptually worse than Windows (some of that is perceptual tricks
> > windows apps pull, some of it real). There is an openoffice.org related
> > analysis project currently under way to sort that out.
> 
> Desktop performance has become a such hot topic that I wonder if
> it would be worth to setup a dedicated mailing list somewhere
> where all the parts involved (kernel, kde/gnome, x.org, libc) can
> analyze what are the real problems are.

There already is one:

http://lists.osdl.org/pipermail/desktop_architects/2005-December/thread.html#522

Lee

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Lee Revell]

On Mon, 2006-01-09 at 14:03 +0300, Yaroslav Rastrigin wrote:
> Hi, 
> > > > money to the right people.
> > >
> > > Could or would you be so kind to provide at least moderately complete
> > > pricelist ? Whom and how much should I pay to have correct support for
> > > intel graphics chipset, 2200BG Wi-Fi, complete
> > > suspend-to-disk/suspend-to-ram and to get an overall performance boost ?
> > 
> > Since these are all supported in 2.6.15, $0 would be my quote.
> I've mentioned _correct_ support. Contrary to current rather sad state of things. 
> 855GM still has no support for non-VESA videomodes (1280x800 can be enabled only via VBIOS hacks, and is not always properly restored on resume) 
> (and don't supported with intelfb) (which, AFAIK, has no support for dualhead)
> 2200BG sometimes starts to unacceptably lag and drop packets after going out of suspend (either STR or STD) and until reboot.
> (And this is driver issue)
> Suspend to ram works, more or less, but drains power like hungry cat drinks milk, and I just can't leave my laptop in STR for more than two days 
> without worrying about my on-the-road availability. 
> Suspend to disk has nasty tendency to ruin my whole hot live X session, since X can't properly restore VT on resume.
> Overall performance isn't that bad, either, but I just can't understand, why KATE (Kde more or less advanced editor) takes twice as long to start 
> as UltraEdit in _emulated_ (VMWare) Windows XP running on this same box.
> 
> So, the question remains the same - whom and how much I need to pay to solve abovementioned problems ?
> 

Where are the bug reports?  You didn't expect these to just fix
themselves did you?

Lee

[OT?] Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Yaroslav Rastrigin]

Hi, Lee,
On 9 January 2006 16:54, you wrote:
> > 
> 
> Where are the bug reports?  You didn't expect these to just fix
> themselves did you?
Been there, done that. Bugreport about malfunctioning (due to ACPI) 3c556 in IBM ThinkPad T20 was looked at once in a few months without any progress, 
and I've finally lost track of it after changing hardware. In more than a year this problem wasn't solved, so I'm assuming bugreports aren't so effective.
2200BG ping and packet loss problem was reported in ipw2200-devel mailing list recently (by another user), and the only answer was 
"Switch to version 1.0.0" (which is tooo old and missing needed features and bugfixes, so recommentation was unacceptable). So I'm assuming addressing 
developers directly is not too effective either. 
Two other options I see are to debug/fix it by myself and try to stimulate others monetarily. First option isn't really affordable for me , 
so I'm trying to research second. 
-- 
Managing your Territory since the dawn of times ...

Re: [OT?] Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Lee Revell]

On Mon, 2006-01-09 at 17:51 +0300, Yaroslav Rastrigin wrote:
> Hi, Lee,
> On 9 January 2006 16:54, you wrote:
> > > 
> > 
> > Where are the bug reports?  You didn't expect these to just fix
> > themselves did you?
> Been there, done that. Bugreport about malfunctioning (due to ACPI) 3c556 in IBM ThinkPad T20 was looked at once in a few months without any progress, 
> and I've finally lost track of it after changing hardware. In more than a year this problem wasn't solved, so I'm assuming bugreports aren't so effective.
> 2200BG ping and packet loss problem was reported in ipw2200-devel mailing list recently (by another user), and the only answer was 
> "Switch to version 1.0.0" (which is tooo old and missing needed features and bugfixes, so recommentation was unacceptable). So I'm assuming addressing 
> developers directly is not too effective either. 
> Two other options I see are to debug/fix it by myself and try to stimulate others monetarily. First option isn't really affordable for me , 
> so I'm trying to research second. 

Bug reports certainly are effective, but if no one else can reproduce
your problem then obviously it can't be fixed.

A bug report that gets no responses is a good sign that you need to
provide more information or work a little harder to debug it yourself.

Lee

Re: [OT?] Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Randy.Dunlap]

On Mon, 9 Jan 2006, Lee Revell wrote:

> On Mon, 2006-01-09 at 17:51 +0300, Yaroslav Rastrigin wrote:
> > Hi, Lee,
> > On 9 January 2006 16:54, you wrote:
> > > >
> > >
> > > Where are the bug reports?  You didn't expect these to just fix
> > > themselves did you?
> > Been there, done that. Bugreport about malfunctioning (due to ACPI) 3c556 in IBM ThinkPad T20 was looked at once in a few months without any progress,
> > and I've finally lost track of it after changing hardware. In more than a year this problem wasn't solved, so I'm assuming bugreports aren't so effective.
> > 2200BG ping and packet loss problem was reported in ipw2200-devel mailing list recently (by another user), and the only answer was
> > "Switch to version 1.0.0" (which is tooo old and missing needed features and bugfixes, so recommentation was unacceptable). So I'm assuming addressing
> > developers directly is not too effective either.
> > Two other options I see are to debug/fix it by myself and try to stimulate others monetarily. First option isn't really affordable for me ,
> > so I'm trying to research second.
>
> Bug reports certainly are effective, but if no one else can reproduce
> your problem then obviously it can't be fixed.

That's not a good attitude IMO.  I'd bet that Linus and Andrew have fixed
lots of bugs that they couldn't reproduce.

> A bug report that gets no responses is a good sign that you need to
> provide more information or work a little harder to debug it yourself.

-- 
~Randy

Re: [OT?] Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Pavel Machek]

On Mon 09-01-06 07:36:37, Randy.Dunlap wrote:
> On Mon, 9 Jan 2006, Lee Revell wrote:
> 
> > On Mon, 2006-01-09 at 17:51 +0300, Yaroslav Rastrigin wrote:
> > > Hi, Lee,
> > > On 9 January 2006 16:54, you wrote:
> > > > >
> > > >
> > > > Where are the bug reports?  You didn't expect these to just fix
> > > > themselves did you?
> > > Been there, done that. Bugreport about malfunctioning (due to ACPI) 3c556 in IBM ThinkPad T20 was looked at once in a few months without any progress,
> > > and I've finally lost track of it after changing hardware. In more than a year this problem wasn't solved, so I'm assuming bugreports aren't so effective.
> > > 2200BG ping and packet loss problem was reported in ipw2200-devel mailing list recently (by another user), and the only answer was
> > > "Switch to version 1.0.0" (which is tooo old and missing needed features and bugfixes, so recommentation was unacceptable). So I'm assuming addressing
> > > developers directly is not too effective either.
> > > Two other options I see are to debug/fix it by myself and try to stimulate others monetarily. First option isn't really affordable for me ,
> > > so I'm trying to research second.
> >
> > Bug reports certainly are effective, but if no one else can reproduce
> > your problem then obviously it can't be fixed.
> 
> That's not a good attitude IMO.  I'd bet that Linus and Andrew have fixed
> lots of bugs that they couldn't reproduce.

It makes sense for not-yet-mature stuff like ipw....

-- 
Thanks, Sharp!

Re: [OT?] Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Pekka Enberg]

Hi,

On 1/9/06, Yaroslav Rastrigin <yarick@it-territory.ru> wrote:
> Been there, done that. Bugreport about malfunctioning (due to ACPI)
> 3c556 in IBM ThinkPad T20 was looked at once in a few months
> without any progress, and I've finally lost track of it after changing
> hardware. In more than a year this problem wasn't solved, so I'm
> assuming bugreports aren't so effective.

Unfortunately bug reports are sometimes lost in the noise. How many
times did you resend the bug report? Did you report all the required
information? Were you able to isolate the failing subsystem? Was there
a working kernel version? Did you try to isolate the changeset that
introduced the bug? Sometimes you have to complain many times and do a
bit of investigative work yourself. There are plenty of bug reports on
LKML which are being ignored because the original reported fails to
follow up on the problem.

On 1/9/06, Yaroslav Rastrigin <yarick@it-territory.ru> wrote:
> 2200BG ping and packet loss problem was reported in ipw2200-devel
> mailing list recently (by another user), and the only answer was
> "Switch to version 1.0.0" (which is tooo old and missing needed features
> and bugfixes, so recommentation was unacceptable). So I'm assuming
> addressing developers directly is not too effective either.

IPW2200 hardware documentation is closed which narrows down the amount
of people who can help you out, sorry. Perhaps you could complain to
your vendor?

                                    Pekka

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Bernd Petrovitsch]

On Mon, 2006-01-09 at 14:03 +0300, Yaroslav Rastrigin wrote:
> Hi, 
> > > > money to the right people.
> > >
> > > Could or would you be so kind to provide at least moderately complete
> > > pricelist ? Whom and how much should I pay to have correct support for
> > > intel graphics chipset, 2200BG Wi-Fi, complete
> > > suspend-to-disk/suspend-to-ram and to get an overall performance boost ?
> > 
> > Since these are all supported in 2.6.15, $0 would be my quote.
> I've mentioned _correct_ support. Contrary to current rather sad state of things. 
> 855GM still has no support for non-VESA videomodes (1280x800 can be enabled only via VBIOS hacks, and is not always properly restored on resume) 
> (and don't supported with intelfb) (which, AFAIK, has no support for dualhead)
> 2200BG sometimes starts to unacceptably lag and drop packets after going out of suspend (either STR or STD) and until reboot.
> (And this is driver issue)
> Suspend to ram works, more or less, but drains power like hungry cat drinks milk, and I just can't leave my laptop in STR for more than two days 
> without worrying about my on-the-road availability. 
> Suspend to disk has nasty tendency to ruin my whole hot live X session, since X can't properly restore VT on resume.
> Overall performance isn't that bad, either, but I just can't understand, why KATE (Kde more or less advanced editor) takes twice as long to start 
> as UltraEdit in _emulated_ (VMWare) Windows XP running on this same box.
> 
> So, the question remains the same - whom and how much I need to pay to solve abovementioned problems ?

The best place to ask this question is IMHO the respective development
lists and/or maintainers. If both of this does not exist, find recent
patch submitters (who provided patches for more than whitespace and
similar cleanups) and ask them.

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Denis Vlasenko]

On Monday 09 January 2006 13:03, Yaroslav Rastrigin wrote:
> Hi, 
> > > > money to the right people.
> > >
> > > Could or would you be so kind to provide at least moderately complete
> > > pricelist ? Whom and how much should I pay to have correct support for
> > > intel graphics chipset, 2200BG Wi-Fi, complete
> > > suspend-to-disk/suspend-to-ram and to get an overall performance boost ?
> > 
> > Since these are all supported in 2.6.15, $0 would be my quote.
>
> I've mentioned _correct_ support. Contrary to current rather sad state of things. 
> 855GM still has no support for non-VESA videomodes (1280x800 can be enabled
> only via VBIOS hacks, and is not always properly restored on resume)  
> (and don't supported with intelfb) (which, AFAIK, has no support for dualhead)
> 2200BG sometimes starts to unacceptably lag and drop packets after going out
> of suspend (either STR or STD) and until reboot. 
> (And this is driver issue)

> Suspend to ram works, more or less, but drains power like hungry cat drinks milk,
> and I just can't leave my laptop in STR for more than two days  
> without worrying about my on-the-road availability. 
> Suspend to disk has nasty tendency to ruin my whole hot live X session,
> since X can't properly restore VT on resume. 

> Overall performance isn't that bad, either, but I just can't understand,
> why KATE (Kde more or less advanced editor) takes twice as long to start  
> as UltraEdit in _emulated_ (VMWare) Windows XP running on this same box.

stracing kate with -t, -tt, -ttt and/or -T options may help. man strace.
(Do you have such tool in Windows?)
 
> So, the question remains the same - whom and how much I need to pay
> to solve abovementioned problems? 

Maybe RedHat, or Suse, or some other commercial distro.
--
vda

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Diego Calleja]

El Mon, 9 Jan 2006 14:03:46 +0300,
Yaroslav Rastrigin <yarick@it-territory.ru> escribió:


> Overall performance isn't that bad, either, but I just can't understand, why KATE (Kde more or less advanced editor) takes twice as long to start 
> as UltraEdit in _emulated_ (VMWare) Windows XP running on this same box.
> 
> So, the question remains the same - whom and how much I need to pay to solve abovementioned problems ?


X.org and related freedesktop projects would be a good start. There's
a _lot_ of things that need to be done for X.org and nobody is doing
them, and they benefit all the desktops not just KDE. Fontconfig eats
1/3 of the time it takes to start a kde app (with warm caches), for
example.

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Dave Airlie]

On 1/9/06, Yaroslav Rastrigin <yarick@it-territory.ru> wrote:
> Hi,
> > > > money to the right people.
> > >
> > > Could or would you be so kind to provide at least moderately complete
> > > pricelist ? Whom and how much should I pay to have correct support for
> > > intel graphics chipset, 2200BG Wi-Fi, complete
> > > suspend-to-disk/suspend-to-ram and to get an overall performance boost ?
> >
> > Since these are all supported in 2.6.15, $0 would be my quote.
> I've mentioned _correct_ support. Contrary to current rather sad state of things.
> 855GM still has no support for non-VESA videomodes (1280x800 can be enabled only via VBIOS hacks, and is not always properly restored on resume)
> (and don't supported with intelfb) (which, AFAIK, has no support for dualhead)

This can be fixed with money, send me lots of it and I'd swear I'd fix
it, however I'm lacking the other thing which is time, I'm nearly sure
I've gotten enough information to start working on some basic
modesetting for some of the external parts for these chips, however
TMDS controllers for laptop screen is probably the one area which is
going to be more difficult and at that stage it usually involves
cracking open the laptop and looking inside, or doing some "looking"
at the BIOS.

The thing is Intel could do this work as well, but they probably don't
want to release source code to drive other vendors chips (the external
chips are never from Intel) as they may not have the proper NDAs in
place, however a company like Intel could also just bully the smaller
vendors into supplying them with such NDAs, and pull the finger out.

Also the fact that the OEMs just put whatever chip onto the board they
can, and fix the Win32 drivers to use them, means Intel don't know in
a lot of cases what has been stuck to the end of the i855 chipset to
drive the internal flat panel or DVI connectors.

Dave.

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Pavel Machek]

Hi!

> > > > money to the right people.
> > >
> > > Could or would you be so kind to provide at least moderately complete
> > > pricelist ? Whom and how much should I pay to have correct support for
> > > intel graphics chipset, 2200BG Wi-Fi, complete
> > > suspend-to-disk/suspend-to-ram and to get an overall performance boost ?
> > 
> > Since these are all supported in 2.6.15, $0 would be my quote.
> I've mentioned _correct_ support. Contrary to current rather sad state of things. 
> 855GM still has no support for non-VESA videomodes (1280x800 can be enabled only via VBIOS hacks, and is not always properly restored on resume) 
> (and don't supported with intelfb) (which, AFAIK, has no support for dualhead)
> 2200BG sometimes starts to unacceptably lag and drop packets after going out of suspend (either STR or STD) and until reboot.
> (And this is driver issue)
> Suspend to ram works, more or less, but drains power like hungry cat drinks milk, and I just can't leave my laptop in STR for more than two days 
> without worrying about my on-the-road availability. 
> Suspend to disk has nasty tendency to ruin my whole hot live X session, since X can't properly restore VT on resume.
> Overall performance isn't that bad, either, but I just can't understand, why KATE (Kde more or less advanced editor) takes twice as long to start 
> as UltraEdit in _emulated_ (VMWare) Windows XP running on this same box.
> 
> So, the question remains the same - whom and how much I need to pay to solve abovementioned problems ?

Buy SLES with support contract. We should be able to help with
s-t-disk and ipw2200... 2 days in s-t-ram sounds quite ok, why
do you think anytink is wrong there?
						Pavel
-- 
Thanks, Sharp!

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Lee Revell]

On Mon, 2006-01-09 at 12:07 +0300, Yaroslav Rastrigin wrote:
> Hi, Eric, 
> On 9 January 2006 11:06, Erik Andersen wrote:
> > On Mon Jan 09, 2006 at 03:54:24PM +0800, Boxer Gnome wrote:
> > > and the dos ntfs driver was not released by the MS offical.So,what' wrong?
> > > 
> > > Somebody who can explain this ?
> > 
> > Sure, thats easy.  You havn't paid Anton and Richard to quit
> > their jobs to work full time on finishing full linux ntfs
> > support.  It is really quite amazing how many "linux can't do foo"
> > type problems could be quickly solved by sending large amounts of
> > money to the right people.
> Could or would you be so kind to provide at least moderately complete pricelist ? Whom and how much should I pay to have correct support for
> intel graphics chipset, 2200BG Wi-Fi, complete suspend-to-disk/suspend-to-ram and to get an overall performance boost ? 
> 

You do understand that most of these types of problem are due to
incomplete hardware specs, and that no amount of money thrown at the
developers can help - you need to talk to the vendors.

Lee

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Andrew Morton]

Yaroslav Rastrigin <yarick@it-territory.ru> wrote:
>
> Hi, Eric, 
> On 9 January 2006 11:06, Erik Andersen wrote:
> > On Mon Jan 09, 2006 at 03:54:24PM +0800, Boxer Gnome wrote:
> > > and the dos ntfs driver was not released by the MS offical.So,what' wrong?
> > > 
> > > Somebody who can explain this ?
> > 
> > Sure, thats easy.  You havn't paid Anton and Richard to quit
> > their jobs to work full time on finishing full linux ntfs
> > support.  It is really quite amazing how many "linux can't do foo"
> > type problems could be quickly solved by sending large amounts of
> > money to the right people.
> Could or would you be so kind to provide at least moderately complete pricelist ? Whom and how much should I pay to have correct support for
> intel graphics chipset, 2200BG Wi-Fi, complete suspend-to-disk/suspend-to-ram and to get an overall performance boost ? 
> 

A quick grep indicates that you reported zero bugs to this mailing list in
2005.

Please preapre quality bug reports (preferably in less-than-80-column
emails) and direct them to the relevant maintainers and be prepared to work
with those maintainers in the resolution of the bugs.

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Denis Vlasenko]

On Tuesday 10 January 2006 09:13, Andrew Morton wrote:
> Yaroslav Rastrigin <yarick@it-territory.ru> wrote:
> > On 9 January 2006 11:06, Erik Andersen wrote:
> > > On Mon Jan 09, 2006 at 03:54:24PM +0800, Boxer Gnome wrote:
> > > > and the dos ntfs driver was not released by the MS offical.So,what' wrong?
> > > > 
> > > > Somebody who can explain this ?
> > > 
> > > Sure, thats easy.  You havn't paid Anton and Richard to quit
> > > their jobs to work full time on finishing full linux ntfs
> > > support.  It is really quite amazing how many "linux can't do foo"
> > > type problems could be quickly solved by sending large amounts of
> > > money to the right people.
> > Could or would you be so kind to provide at least moderately complete pricelist ? Whom and how much should I pay to have correct support for
> > intel graphics chipset, 2200BG Wi-Fi, complete suspend-to-disk/suspend-to-ram and to get an overall performance boost ? 
> 
> A quick grep indicates that you reported zero bugs to this mailing list in
> 2005.
> 
> Please preapre quality bug reports (preferably in less-than-80-column
> emails) and direct them to the relevant maintainers and be prepared to work
> with those maintainers in the resolution of the bugs.

Andrew, I think this is a rare (on lkml at least) case when guy
does not want to participate in development in a Linux way
but wants to just pay for development instead:
"I want this <hardware> to work good under Linux. I want to pay
up to <sum> to whoever will agree to do that. Anybody?"

Do not dismiss him lightly. There are LOTS of people which aren't
hackish at all. An order of magniture more than 'us' computer geeks.
M$ is successful because it uses this resource.
We may want to think how can we use it too.

No, I don't think you, or someone else on this list can efficiently
use it, but distros, being more commercially oriented, maybe can.
--
vda

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[D. Hazelton]

On Tuesday 10 January 2006 02:33, Denis Vlasenko wrote:
<snip>
> Andrew, I think this is a rare (on lkml at least) case when guy
> does not want to participate in development in a Linux way
> but wants to just pay for development instead:
> "I want this <hardware> to work good under Linux. I want to pay
> up to <sum> to whoever will agree to do that. Anybody?"
>
> Do not dismiss him lightly. There are LOTS of people which aren't
> hackish at all. An order of magniture more than 'us' computer geeks.
> M$ is successful because it uses this resource.
> We may want to think how can we use it too.
>
> No, I don't think you, or someone else on this list can efficiently
> use it, but distros, being more commercially oriented, maybe can.

This is true. The types of bounties I have seen in OS development do not 
usually reach much beyond $500. If distro's were to get behind this and start 
offering bounties of large sums for _working_ code for hardware there might 
be a response. As you've said, M$ is successful because it can throw money at 
the problems. Sadly, another reason why M$ is successful are their NDA's and 
the terms of any number of the contracts they offer hardware vendors and the 
like. (And yet another reason is the fact that they got their foot in the doo 
at just the right time. However, IMHO (and I have seen this recently), Now is 
the time for Linux to start really stepping up to bat. I have had any number 
of freinds and relatives ask me if there is an alternative to Windows and how 
it takes so much work to keep running (I teach them basic windows maintenance 
so I don't have to spend weekends going from house to house fixing problems) 
- sadly I've had to tell them they are stuck with Windows for various 
reasons. (Nothing to do with the Kernel, but the state of the available 
software))

But if the larger distro vendors would start offering bounties, all the 
various small kernel problems that would stymie them would probably 
disappear. Then the only problem is the market penetration and the 
availability of software many people have come to depend on. (I have two 
relatives who rely on the newest Yahoo IM clients voice chat and web-cam 
abilities. Yahoo has not, and apparently will not, update their "Official" 
client for Linux to have these capabilities and none of the alternative 
clients have them.) When (I'm quite hopeful) Linux begins to get more market 
penetration these problems of software should start to disappear.

_That_ is a goal Linux is (hopefully) aiming towards. This one persons offer 
of money isn't enough - but more than likely larger offered sums will lure 
more of the "Less Hackish" developers to start doing work for Linux. The 
other problem is one of the legality of binary-only modules. I, personally, 
have seen _very_ few with any "binary only" code that directly accesses 
kernel facilities - those interfaces are always released openly. (I cannot 
verify this for the two binary only modules I have had to deal with recently 
- if just because I don't actually have the time to disassemble the object 
files they ship to check for kernel function use. (Which would mean inclusion 
of portions of the Kernel Headers. Which, I'm afraid, to me would signify 
them being derivative works and therefore in violation of the GPL.)

I've wasted enough bandwidth here. Note that all flames will be read and 
laughed at :)

D. Hazelton

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Diego Calleja]

El Tue, 10 Jan 2006 03:33:56 -0500,
"D. Hazelton" <dhazelton@enter.net> escribió:

> This is true. The types of bounties I have seen in OS development do not 
> usually reach much beyond $500. If distro's were to get behind this and start 

Well - just pay for redhat/suse/whatever license, you can ask them to 
fix the problem. That's why they exist in first place.

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Denis Vlasenko]

On Tuesday 10 January 2006 10:33, D. Hazelton wrote:
> On Tuesday 10 January 2006 02:33, Denis Vlasenko wrote:
> <snip>
> > Andrew, I think this is a rare (on lkml at least) case when guy
> > does not want to participate in development in a Linux way
> > but wants to just pay for development instead:
> > "I want this <hardware> to work good under Linux. I want to pay
> > up to <sum> to whoever will agree to do that. Anybody?"
> >
> > Do not dismiss him lightly. There are LOTS of people which aren't
> > hackish at all. An order of magniture more than 'us' computer geeks.
> > M$ is successful because it uses this resource.
> > We may want to think how can we use it too.
> >
> > No, I don't think you, or someone else on this list can efficiently
> > use it, but distros, being more commercially oriented, maybe can.
> 
> This is true. The types of bounties I have seen in OS development do not 
> usually reach much beyond $500. If distro's were to get behind this and start 
> offering bounties of large sums for _working_ code for hardware there might 
> be a response.

I meant a different thing. Distro is a commercial entity.
Users can buy services from businesses. "Write (or fix) me a driver"
is a service.

People inclined to just pay for code instead of helping with coding
may have greater success talking to distros.

Of course, distros then will hire someone from lkml crowd to actually do it.

If there will be enough of cash flow from such requests, this can
becode somebody's full time job.
--
vda

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[D. Hazelton]

On Tuesday 10 January 2006 08:26, Denis Vlasenko wrote:
> On Tuesday 10 January 2006 10:33, D. Hazelton wrote:
> > On Tuesday 10 January 2006 02:33, Denis Vlasenko wrote:
> > <snip>
> >
> > > Andrew, I think this is a rare (on lkml at least) case when guy
> > > does not want to participate in development in a Linux way
> > > but wants to just pay for development instead:
> > > "I want this <hardware> to work good under Linux. I want to pay
> > > up to <sum> to whoever will agree to do that. Anybody?"
> > >
> > > Do not dismiss him lightly. There are LOTS of people which aren't
> > > hackish at all. An order of magniture more than 'us' computer geeks.
> > > M$ is successful because it uses this resource.
> > > We may want to think how can we use it too.
> > >
> > > No, I don't think you, or someone else on this list can efficiently
> > > use it, but distros, being more commercially oriented, maybe can.
> >
> > This is true. The types of bounties I have seen in OS development do not
> > usually reach much beyond $500. If distro's were to get behind this and
> > start offering bounties of large sums for _working_ code for hardware
> > there might be a response.
>
> I meant a different thing. Distro is a commercial entity.
> Users can buy services from businesses. "Write (or fix) me a driver"
> is a service.
>
> People inclined to just pay for code instead of helping with coding
> may have greater success talking to distros.
>
> Of course, distros then will hire someone from lkml crowd to actually do
> it.
>
> If there will be enough of cash flow from such requests, this can
> becode somebody's full time job.

Almost exactly what I meant. Truth is, though, that I mentioned the "bounty" 
system because its flexible enough that the distro's wouldn't have to hire 
someone full-time. However, I can see that it would make a difference in 
several respects. Statement withdrawn.

D. Hazelton

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Yaroslav Rastrigin]

Hi, Denis,
> 
> Andrew, I think this is a rare (on lkml at least) case when guy
> does not want to participate in development in a Linux way
> but wants to just pay for development instead:
> "I want this <hardware> to work good under Linux. I want to pay
> up to <sum> to whoever will agree to do that. Anybody?"
Well, yes. I want my hardware to work properly. And, given amount of problems with my current setup and _knowing_ 
how much time it will take for me to debug them by myself , I'm deciding that in the end run it will be faster and more efficent to
pay relevant people to fix bugs in subsystems they write/maintain than to participate in (sometimes) never ending bugfix mode.

> 
> Do not dismiss him lightly. There are LOTS of people which aren't
> hackish at all. An order of magniture more than 'us' computer geeks.
> M$ is successful because it uses this resource.
> We may want to think how can we use it too.
Well. Regarding myself, your assumptions are totally wrong. 
My Linux experience started in 1995, as an admin/coder, and since 2000 I'm Linux-only almost 100% 
And up to some point I was fixing bugs that were critical for me in kernels I was using. 
But now, given amount of other tasks before me (my regular daily/nightly job) , to spend a few weeks to
understand why my WiFi starts to drop packets after resume is more than I could afford.

-- 
Managing your Territory since the dawn of times ...

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Yaroslav Rastrigin]

Hi, Andrew, 
On 10 January 2006 10:13, Andrew Morton wrote:
> 
> A quick grep indicates that you reported zero bugs to this mailing list in
> 2005.
> 
> Please preapre quality bug reports (preferably in less-than-80-column
> emails) and direct them to the relevant maintainers and be prepared to work
> with those maintainers in the resolution of the bugs.
Bug #1188 . See for yourself about quality of reported data, relevant maintainers and my prepareness to work with them to resolve.
(P.S. Two fscking years.)

-- 
Managing your Territory since the dawn of times ...

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Diego Calleja]

El Tue, 10 Jan 2006 12:20:03 +0300,
Yaroslav Rastrigin <yarick@it-territory.ru> escribió:


> Bug #1188 . See for yourself about quality of reported data, relevant maintainers and my prepareness to work with them to resolve.
> (P.S. Two fscking years.)


I see 44 comentaries there. It's not that people haven't tried to
help you (several of them don't get any money for helping to
fix stuff). In fact they've been following the bug for two years,
which proves how good bugzilla maintainers the intel acpi guys are.
You've indeed helped people to debug the problem, but there're some
bugs that just are hard to fix (and hardware manufacturers not
collaborating to make their hardware work in linux doesn't makes
it easier).

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Bernd Petrovitsch]

On Mon, 2006-01-09 at 15:54 +0800, Boxer Gnome wrote:
> and the dos ntfs driver was not released by the MS offical.So,what' wrong?
> 
> Somebody who can explain this ?

The NTFS vendor is identical to the DOS vendor. Therefore it has access
to current, correct and complete documentation and can control and test
changes on dedicated test systems before bugs hits users seriously.
In case of filesystems (like here), "hitting the user seriously" means
"loosing the whole filesystem. Go and look for a recent backup.".

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Robert Hancock]

Yaroslav Rastrigin wrote:
> Well, I could find more or less reasonable explanation of this behaviour - different VM policies of two OSes and 
> strangely strong and persistent belief "Free RAM is a wasted RAM" among kernel devs. Free RAM is not a wasted RAM, its a memory waiting to be used ! 
> Whenever it is needed by apps I'm launching or working with. 

There is no different VM policy here, Windows behaves quite similarly. 
It does not leave memory around unused, it uses it for disk cache.

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Oliver Neukum]

Am Montag, 9. Januar 2006 15:18 schrieb Robert Hancock:
> Yaroslav Rastrigin wrote:
> > Well, I could find more or less reasonable explanation of this behaviour - different VM policies of two OSes and 
> > strangely strong and persistent belief "Free RAM is a wasted RAM" among kernel devs. Free RAM is not a wasted RAM, its a memory waiting to be used ! 
> > Whenever it is needed by apps I'm launching or working with. 
> 
> There is no different VM policy here, Windows behaves quite similarly. 
> It does not leave memory around unused, it uses it for disk cache.

That doesn't mean that the rate of eviction is the same.
Is it possible that read-ahead is not aggressive enough?

	Regards
		Oliver

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Lee Revell]

On Mon, 2006-01-09 at 15:28 +0100, Oliver Neukum wrote:
> Am Montag, 9. Januar 2006 15:18 schrieb Robert Hancock:
> > Yaroslav Rastrigin wrote:
> > > Well, I could find more or less reasonable explanation of this behaviour - different VM policies of two OSes and 
> > > strangely strong and persistent belief "Free RAM is a wasted RAM" among kernel devs. Free RAM is not a wasted RAM, its a memory waiting to be used ! 
> > > Whenever it is needed by apps I'm launching or working with. 
> > 
> > There is no different VM policy here, Windows behaves quite similarly. 
> > It does not leave memory around unused, it uses it for disk cache.
> 
> That doesn't mean that the rate of eviction is the same.
> Is it possible that read-ahead is not aggressive enough?

Enough for what?  What is the exact problem you are trying to solve?

Lee

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Oliver Neukum]

Am Montag, 9. Januar 2006 16:15 schrieb Lee Revell:
> On Mon, 2006-01-09 at 15:28 +0100, Oliver Neukum wrote:
> > Am Montag, 9. Januar 2006 15:18 schrieb Robert Hancock:
> > > Yaroslav Rastrigin wrote:
> > > > Well, I could find more or less reasonable explanation of this behaviour - different VM policies of two OSes and 
> > > > strangely strong and persistent belief "Free RAM is a wasted RAM" among kernel devs. Free RAM is not a wasted RAM, its a memory waiting to be used ! 
> > > > Whenever it is needed by apps I'm launching or working with. 
> > > 
> > > There is no different VM policy here, Windows behaves quite similarly. 
> > > It does not leave memory around unused, it uses it for disk cache.
> > 
> > That doesn't mean that the rate of eviction is the same.
> > Is it possible that read-ahead is not aggressive enough?
> 
> Enough for what?  What is the exact problem you are trying to solve?

Quicker application startup.

	Regards
		Oliver

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Lee Revell]

On Mon, 2006-01-09 at 17:02 +0100, Oliver Neukum wrote:
> Am Montag, 9. Januar 2006 16:15 schrieb Lee Revell:
> > On Mon, 2006-01-09 at 15:28 +0100, Oliver Neukum wrote:
> > > Am Montag, 9. Januar 2006 15:18 schrieb Robert Hancock:
> > > > Yaroslav Rastrigin wrote:
> > > > > Well, I could find more or less reasonable explanation of this behaviour - different VM policies of two OSes and 
> > > > > strangely strong and persistent belief "Free RAM is a wasted RAM" among kernel devs. Free RAM is not a wasted RAM, its a memory waiting to be used ! 
> > > > > Whenever it is needed by apps I'm launching or working with. 
> > > > 
> > > > There is no different VM policy here, Windows behaves quite similarly. 
> > > > It does not leave memory around unused, it uses it for disk cache.
> > > 
> > > That doesn't mean that the rate of eviction is the same.
> > > Is it possible that read-ahead is not aggressive enough?
> > 
> > Enough for what?  What is the exact problem you are trying to solve?
> 
> Quicker application startup.

Why do you look to the kernel first?  The obvious explanation is that
Linux desktop apps are more bloated than their Windows counterparts.

Lee

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Oliver Neukum]

Am Montag, 9. Januar 2006 17:04 schrieb Lee Revell:
> On Mon, 2006-01-09 at 17:02 +0100, Oliver Neukum wrote:
> > Am Montag, 9. Januar 2006 16:15 schrieb Lee Revell:
> > > On Mon, 2006-01-09 at 15:28 +0100, Oliver Neukum wrote:
> > > > Am Montag, 9. Januar 2006 15:18 schrieb Robert Hancock:
> > > > > Yaroslav Rastrigin wrote:
> > > > > > Well, I could find more or less reasonable explanation of this behaviour - different VM policies of two OSes and 
> > > > > > strangely strong and persistent belief "Free RAM is a wasted RAM" among kernel devs. Free RAM is not a wasted RAM, its a memory waiting to be used ! 
> > > > > > Whenever it is needed by apps I'm launching or working with. 
> > > > > 
> > > > > There is no different VM policy here, Windows behaves quite similarly. 
> > > > > It does not leave memory around unused, it uses it for disk cache.
> > > > 
> > > > That doesn't mean that the rate of eviction is the same.
> > > > Is it possible that read-ahead is not aggressive enough?
> > > 
> > > Enough for what?  What is the exact problem you are trying to solve?
> > 
> > Quicker application startup.
> 
> Why do you look to the kernel first?  The obvious explanation is that
> Linux desktop apps are more bloated than their Windows counterparts.

It is the most efficient place. An improvement to the kernel will improve
all starting times.

	Regards
		Oliver

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Lee Revell]

On Mon, 2006-01-09 at 17:14 +0100, Oliver Neukum wrote:
> Am Montag, 9. Januar 2006 17:04 schrieb Lee Revell:
> > On Mon, 2006-01-09 at 17:02 +0100, Oliver Neukum wrote:
> > > Am Montag, 9. Januar 2006 16:15 schrieb Lee Revell:
> > > > On Mon, 2006-01-09 at 15:28 +0100, Oliver Neukum wrote:
> > > > > Am Montag, 9. Januar 2006 15:18 schrieb Robert Hancock:
> > > > > > Yaroslav Rastrigin wrote:
> > > > > > > Well, I could find more or less reasonable explanation of this behaviour - different VM policies of two OSes and 
> > > > > > > strangely strong and persistent belief "Free RAM is a wasted RAM" among kernel devs. Free RAM is not a wasted RAM, its a memory waiting to be used ! 
> > > > > > > Whenever it is needed by apps I'm launching or working with. 
> > > > > > 
> > > > > > There is no different VM policy here, Windows behaves quite similarly. 
> > > > > > It does not leave memory around unused, it uses it for disk cache.
> > > > > 
> > > > > That doesn't mean that the rate of eviction is the same.
> > > > > Is it possible that read-ahead is not aggressive enough?
> > > > 
> > > > Enough for what?  What is the exact problem you are trying to solve?
> > > 
> > > Quicker application startup.
> > 
> > Why do you look to the kernel first?  The obvious explanation is that
> > Linux desktop apps are more bloated than their Windows counterparts.
> 
> It is the most efficient place. An improvement to the kernel will improve
> all starting times.

I think you'll get at most a 10% or 20% speedup by improving the kernel,
while some of these apps (think Nautilus vs Windows Explorer) will need
to be 1000% faster to seem reasonable to a Windows user.

Lee


Lee

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Bernd Petrovitsch]

On Mon, 2006-01-09 at 11:19 -0500, Lee Revell wrote:
> On Mon, 2006-01-09 at 17:14 +0100, Oliver Neukum wrote:
> > Am Montag, 9. Januar 2006 17:04 schrieb Lee Revell:
> > > On Mon, 2006-01-09 at 17:02 +0100, Oliver Neukum wrote:
> > > > Am Montag, 9. Januar 2006 16:15 schrieb Lee Revell:
> > > > > On Mon, 2006-01-09 at 15:28 +0100, Oliver Neukum wrote:
> > > > > > Am Montag, 9. Januar 2006 15:18 schrieb Robert Hancock:
> > > > > > > Yaroslav Rastrigin wrote:
> > > > > > > > Well, I could find more or less reasonable explanation of this behaviour - different VM policies of two OSes and 
> > > > > > > > strangely strong and persistent belief "Free RAM is a wasted RAM" among kernel devs. Free RAM is not a wasted RAM, its a memory waiting to be used ! 
> > > > > > > > Whenever it is needed by apps I'm launching or working with. 
> > > > > > > 
> > > > > > > There is no different VM policy here, Windows behaves quite similarly. 
> > > > > > > It does not leave memory around unused, it uses it for disk cache.
> > > > > > 
> > > > > > That doesn't mean that the rate of eviction is the same.
> > > > > > Is it possible that read-ahead is not aggressive enough?
> > > > > 
> > > > > Enough for what?  What is the exact problem you are trying to solve?
> > > > 
> > > > Quicker application startup.
> > > 
> > > Why do you look to the kernel first?  The obvious explanation is that
> > > Linux desktop apps are more bloated than their Windows counterparts.
> > 
> > It is the most efficient place. An improvement to the kernel will improve
> > all starting times.
> 
> I think you'll get at most a 10% or 20% speedup by improving the kernel,
> while some of these apps (think Nautilus vs Windows Explorer) will need
> to be 1000% faster to seem reasonable to a Windows user.

That's easy: Just start nautilus, OOorg, Firefox, a java-vm and
GNOME/KDE infrastructure at login time in the background (*eg* and
mlockall() the more important ones so that the are surely in RAM) and
"starting the app" is only a small program connecting to the respective
process to get a fork() there (e.g. like the "-remote" parameter in the
Mozilla family).

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Lee Revell]

On Mon, 2006-01-09 at 17:29 +0100, Bernd Petrovitsch wrote:
> On Mon, 2006-01-09 at 11:19 -0500, Lee Revell wrote:
> > On Mon, 2006-01-09 at 17:14 +0100, Oliver Neukum wrote:
> > > Am Montag, 9. Januar 2006 17:04 schrieb Lee Revell:
> > > > On Mon, 2006-01-09 at 17:02 +0100, Oliver Neukum wrote:
> > > > > Am Montag, 9. Januar 2006 16:15 schrieb Lee Revell:
> > > > > > On Mon, 2006-01-09 at 15:28 +0100, Oliver Neukum wrote:
> > > > > > > Am Montag, 9. Januar 2006 15:18 schrieb Robert Hancock:
> > > > > > > > Yaroslav Rastrigin wrote:
> > > > > > > > > Well, I could find more or less reasonable explanation of this behaviour - different VM policies of two OSes and 
> > > > > > > > > strangely strong and persistent belief "Free RAM is a wasted RAM" among kernel devs. Free RAM is not a wasted RAM, its a memory waiting to be used ! 
> > > > > > > > > Whenever it is needed by apps I'm launching or working with. 
> > > > > > > > 
> > > > > > > > There is no different VM policy here, Windows behaves quite similarly. 
> > > > > > > > It does not leave memory around unused, it uses it for disk cache.
> > > > > > > 
> > > > > > > That doesn't mean that the rate of eviction is the same.
> > > > > > > Is it possible that read-ahead is not aggressive enough?
> > > > > > 
> > > > > > Enough for what?  What is the exact problem you are trying to solve?
> > > > > 
> > > > > Quicker application startup.
> > > > 
> > > > Why do you look to the kernel first?  The obvious explanation is that
> > > > Linux desktop apps are more bloated than their Windows counterparts.
> > > 
> > > It is the most efficient place. An improvement to the kernel will improve
> > > all starting times.
> > 
> > I think you'll get at most a 10% or 20% speedup by improving the kernel,
> > while some of these apps (think Nautilus vs Windows Explorer) will need
> > to be 1000% faster to seem reasonable to a Windows user.
> 
> That's easy: Just start nautilus, OOorg, Firefox, a java-vm and
> GNOME/KDE infrastructure at login time in the background (*eg* and
> mlockall() the more important ones so that the are surely in RAM) and
> "starting the app" is only a small program connecting to the respective
> process to get a fork() there (e.g. like the "-remote" parameter in the
> Mozilla family).

Have you tried this?  I suspect it still takes at least twice as long as
on windows.

For example on my system there was already a "nautilus" process but
"Places -> Home Folder" still took ~2 seconds to display anything, and
~8 seconds to completely render the window and icons.  On Windows this
takes much less than a second.

Lee

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Oliver Neukum]

Am Montag, 9. Januar 2006 17:41 schrieb Lee Revell:
> On Mon, 2006-01-09 at 17:29 +0100, Bernd Petrovitsch wrote:
> > On Mon, 2006-01-09 at 11:19 -0500, Lee Revell wrote:
> > > On Mon, 2006-01-09 at 17:14 +0100, Oliver Neukum wrote:
> > > > Am Montag, 9. Januar 2006 17:04 schrieb Lee Revell:
> > > > > On Mon, 2006-01-09 at 17:02 +0100, Oliver Neukum wrote:
> > > > > > Am Montag, 9. Januar 2006 16:15 schrieb Lee Revell:
> > > > > > > On Mon, 2006-01-09 at 15:28 +0100, Oliver Neukum wrote:
> > > > > > > > Am Montag, 9. Januar 2006 15:18 schrieb Robert Hancock:
> > > > > > > > > Yaroslav Rastrigin wrote:
> > > > > > > > > > Well, I could find more or less reasonable explanation of this behaviour - different VM policies of two OSes and 
> > > > > > > > > > strangely strong and persistent belief "Free RAM is a wasted RAM" among kernel devs. Free RAM is not a wasted RAM, its a memory waiting to be used ! 
> > > > > > > > > > Whenever it is needed by apps I'm launching or working with. 
> > > > > > > > > 
> > > > > > > > > There is no different VM policy here, Windows behaves quite similarly. 
> > > > > > > > > It does not leave memory around unused, it uses it for disk cache.
> > > > > > > > 
> > > > > > > > That doesn't mean that the rate of eviction is the same.
> > > > > > > > Is it possible that read-ahead is not aggressive enough?
> > > > > > > 
> > > > > > > Enough for what?  What is the exact problem you are trying to solve?
> > > > > > 
> > > > > > Quicker application startup.
> > > > > 
> > > > > Why do you look to the kernel first?  The obvious explanation is that
> > > > > Linux desktop apps are more bloated than their Windows counterparts.
> > > > 
> > > > It is the most efficient place. An improvement to the kernel will improve
> > > > all starting times.
> > > 
> > > I think you'll get at most a 10% or 20% speedup by improving the kernel,
> > > while some of these apps (think Nautilus vs Windows Explorer) will need
> > > to be 1000% faster to seem reasonable to a Windows user.
> > 
> > That's easy: Just start nautilus, OOorg, Firefox, a java-vm and
> > GNOME/KDE infrastructure at login time in the background (*eg* and
> > mlockall() the more important ones so that the are surely in RAM) and
> > "starting the app" is only a small program connecting to the respective
> > process to get a fork() there (e.g. like the "-remote" parameter in the
> > Mozilla family).
> 
> Have you tried this?  I suspect it still takes at least twice as long as
> on windows.
> 
> For example on my system there was already a "nautilus" process but
> "Places -> Home Folder" still took ~2 seconds to display anything, and
> ~8 seconds to completely render the window and icons.  On Windows this
> takes much less than a second.

Does the Windows Explorer draw icons based only on name and metadata?

	Regards
		Oliver

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Lee Revell]

On Mon, 2006-01-09 at 17:53 +0100, Oliver Neukum wrote:
> Am Montag, 9. Januar 2006 17:41 schrieb Lee Revell:
> > On Mon, 2006-01-09 at 17:29 +0100, Bernd Petrovitsch wrote:
> > > On Mon, 2006-01-09 at 11:19 -0500, Lee Revell wrote:
> > > > On Mon, 2006-01-09 at 17:14 +0100, Oliver Neukum wrote:
> > > > > Am Montag, 9. Januar 2006 17:04 schrieb Lee Revell:
> > > > > > On Mon, 2006-01-09 at 17:02 +0100, Oliver Neukum wrote:
> > > > > > > Am Montag, 9. Januar 2006 16:15 schrieb Lee Revell:
> > > > > > > > On Mon, 2006-01-09 at 15:28 +0100, Oliver Neukum wrote:
> > > > > > > > > Am Montag, 9. Januar 2006 15:18 schrieb Robert Hancock:
> > > > > > > > > > Yaroslav Rastrigin wrote:
> > > > > > > > > > > Well, I could find more or less reasonable explanation of this behaviour - different VM policies of two OSes and 
> > > > > > > > > > > strangely strong and persistent belief "Free RAM is a wasted RAM" among kernel devs. Free RAM is not a wasted RAM, its a memory waiting to be used ! 
> > > > > > > > > > > Whenever it is needed by apps I'm launching or working with. 
> > > > > > > > > > 
> > > > > > > > > > There is no different VM policy here, Windows behaves quite similarly. 
> > > > > > > > > > It does not leave memory around unused, it uses it for disk cache.
> > > > > > > > > 
> > > > > > > > > That doesn't mean that the rate of eviction is the same.
> > > > > > > > > Is it possible that read-ahead is not aggressive enough?
> > > > > > > > 
> > > > > > > > Enough for what?  What is the exact problem you are trying to solve?
> > > > > > > 
> > > > > > > Quicker application startup.
> > > > > > 
> > > > > > Why do you look to the kernel first?  The obvious explanation is that
> > > > > > Linux desktop apps are more bloated than their Windows counterparts.
> > > > > 
> > > > > It is the most efficient place. An improvement to the kernel will improve
> > > > > all starting times.
> > > > 
> > > > I think you'll get at most a 10% or 20% speedup by improving the kernel,
> > > > while some of these apps (think Nautilus vs Windows Explorer) will need
> > > > to be 1000% faster to seem reasonable to a Windows user.
> > > 
> > > That's easy: Just start nautilus, OOorg, Firefox, a java-vm and
> > > GNOME/KDE infrastructure at login time in the background (*eg* and
> > > mlockall() the more important ones so that the are surely in RAM) and
> > > "starting the app" is only a small program connecting to the respective
> > > process to get a fork() there (e.g. like the "-remote" parameter in the
> > > Mozilla family).
> > 
> > Have you tried this?  I suspect it still takes at least twice as long as
> > on windows.
> > 
> > For example on my system there was already a "nautilus" process but
> > "Places -> Home Folder" still took ~2 seconds to display anything, and
> > ~8 seconds to completely render the window and icons.  On Windows this
> > takes much less than a second.
> 
> Does the Windows Explorer draw icons based only on name and metadata?

No idea.  All i know is it's fast enough to be usable and Nautilus
isn't.

Lee

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Olivier Galibert]

On Mon, Jan 09, 2006 at 05:53:35PM +0100, Oliver Neukum wrote:
> Does the Windows Explorer draw icons based only on name and metadata?

>From what I can see it does icons on non-executable entirely based on
the extension and nothing else on the first pass.  Executables are
looked inside for an icon (and there seems to be cache effects at
times, especially visible on the desktop).  Then for images a second
pass generates icons depending on the contents (with, once again, a
cache hidden somewhere).

Not a bad strategy, too.  Doing a file(1) on everything can only be
slow given the random disk accesses it generates.  Maybe a file(1) as
a _second_ pass would work.

  OG.

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Lee Revell]

On Mon, 2006-01-09 at 18:14 +0100, Olivier Galibert wrote:
> On Mon, Jan 09, 2006 at 05:53:35PM +0100, Oliver Neukum wrote:
> > Does the Windows Explorer draw icons based only on name and metadata?
> 
> >From what I can see it does icons on non-executable entirely based on
> the extension and nothing else on the first pass.  Executables are
> looked inside for an icon (and there seems to be cache effects at
> times, especially visible on the desktop).  Then for images a second
> pass generates icons depending on the contents (with, once again, a
> cache hidden somewhere).
> 
> Not a bad strategy, too.  Doing a file(1) on everything can only be
> slow given the random disk accesses it generates.  Maybe a file(1) as
> a _second_ pass would work.

Gack, does Nautilus really do file(1) on everything?  That's unspeakably
awful.

Lee

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Anton Altaparmakov]

On Mon, 9 Jan 2006, Lee Revell wrote:
> On Mon, 2006-01-09 at 18:14 +0100, Olivier Galibert wrote:
> > On Mon, Jan 09, 2006 at 05:53:35PM +0100, Oliver Neukum wrote:
> > > Does the Windows Explorer draw icons based only on name and metadata?
> > 
> > >From what I can see it does icons on non-executable entirely based on
> > the extension and nothing else on the first pass.  Executables are
> > looked inside for an icon (and there seems to be cache effects at
> > times, especially visible on the desktop).  Then for images a second
> > pass generates icons depending on the contents (with, once again, a
> > cache hidden somewhere).
> > 
> > Not a bad strategy, too.  Doing a file(1) on everything can only be
> > slow given the random disk accesses it generates.  Maybe a file(1) as
> > a _second_ pass would work.
> 
> Gack, does Nautilus really do file(1) on everything?  That's unspeakably
> awful.

I believe it does a lot worse things.  It actually reads a picture file 
for example, then resizes the picture down to an icon sized one and then 
displays the icon, then on to the next file and for text files it 
displays the beginning of the text file in the icon, etc...  Totally 
unnecessary and brings total slowdown.  But of course as with Windows 
Explorer this is configurable and you can just use list view without 
icons...

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Bernd Petrovitsch]

On Mon, 2006-01-09 at 17:53 +0100, Oliver Neukum wrote:
> Am Montag, 9. Januar 2006 17:41 schrieb Lee Revell:
> > On Mon, 2006-01-09 at 17:29 +0100, Bernd Petrovitsch wrote:
> > > On Mon, 2006-01-09 at 11:19 -0500, Lee Revell wrote:
> > > > On Mon, 2006-01-09 at 17:14 +0100, Oliver Neukum wrote:
> > > > > Am Montag, 9. Januar 2006 17:04 schrieb Lee Revell:
> > > > > > On Mon, 2006-01-09 at 17:02 +0100, Oliver Neukum wrote:
> > > > > > > Am Montag, 9. Januar 2006 16:15 schrieb Lee Revell:
> > > > > > > > On Mon, 2006-01-09 at 15:28 +0100, Oliver Neukum wrote:
> > > > > > > > > Am Montag, 9. Januar 2006 15:18 schrieb Robert Hancock:
> > > > > > > > > > Yaroslav Rastrigin wrote:
> > > > > > > > > > > Well, I could find more or less reasonable explanation of this behaviour - different VM policies of two OSes and 
> > > > > > > > > > > strangely strong and persistent belief "Free RAM is a wasted RAM" among kernel devs. Free RAM is not a wasted RAM, its a memory waiting to be used ! 
> > > > > > > > > > > Whenever it is needed by apps I'm launching or working with. 
> > > > > > > > > > 
> > > > > > > > > > There is no different VM policy here, Windows behaves quite similarly. 
> > > > > > > > > > It does not leave memory around unused, it uses it for disk cache.
> > > > > > > > > 
> > > > > > > > > That doesn't mean that the rate of eviction is the same.
> > > > > > > > > Is it possible that read-ahead is not aggressive enough?
> > > > > > > > 
> > > > > > > > Enough for what?  What is the exact problem you are trying to solve?
> > > > > > > 
> > > > > > > Quicker application startup.
> > > > > > 
> > > > > > Why do you look to the kernel first?  The obvious explanation is that
> > > > > > Linux desktop apps are more bloated than their Windows counterparts.
> > > > > 
> > > > > It is the most efficient place. An improvement to the kernel will improve
> > > > > all starting times.
> > > > 
> > > > I think you'll get at most a 10% or 20% speedup by improving the kernel,
> > > > while some of these apps (think Nautilus vs Windows Explorer) will need
> > > > to be 1000% faster to seem reasonable to a Windows user.
> > > 
> > > That's easy: Just start nautilus, OOorg, Firefox, a java-vm and
> > > GNOME/KDE infrastructure at login time in the background (*eg* and
> > > mlockall() the more important ones so that the are surely in RAM) and
> > > "starting the app" is only a small program connecting to the respective
> > > process to get a fork() there (e.g. like the "-remote" parameter in the
> > > Mozilla family).
> > 
> > Have you tried this?  I suspect it still takes at least twice as long as
> > on windows.
> > 
> > For example on my system there was already a "nautilus" process but
> > "Places -> Home Folder" still took ~2 seconds to display anything, and
> > ~8 seconds to completely render the window and icons.  On Windows this
> > takes much less than a second.
> 
> Does the Windows Explorer draw icons based only on name and metadata?

Depends on the "View" of that directory and what you mean with
"metadata":
- There are view types that display such mini-icons and/or file details
  and/or contents for images.
- "Metadata" in the Windows-hell means "extension" which you get cheap
  with the filename anyways. There is no thing like "file" or a similar
  attempt to guess the type of contents automagically just for doing
  graphiocal "ls".

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Alan Cox]

On Llu, 2006-01-09 at 17:53 +0100, Oliver Neukum wrote:
> Does the Windows Explorer draw icons based only on name and metadata?

Sort of. It also plays tricks on the human by working out what icons are
visible and loading those first then filling in while the user thinks it
is ready

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Jeff V. Merkey]

Alan Cox wrote:

>On Llu, 2006-01-09 at 17:53 +0100, Oliver Neukum wrote:
>  
>
>>Does the Windows Explorer draw icons based only on name and metadata?
>>    
>>
>
>Sort of. It also plays tricks on the human by working out what icons are
>visible and loading those first then filling in while the user thinks it
>is ready
>
>  
>

And the mouse driver is biased to always get access to CPU cycles so the 
cursor will always be visible
and working even when the system is totally locked up.  NTFS performance 
is also totally abysimal
when volumes reach 2TB sizes due to fragmentation of the NTFS 
archtiecture.  A problem not shared
with EXT3 FS's.

J

>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>
>  
>

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Lee Revell]

On Mon, 2006-01-09 at 17:31 +0000, Alan Cox wrote:
> On Llu, 2006-01-09 at 17:53 +0100, Oliver Neukum wrote:
> > Does the Windows Explorer draw icons based only on name and metadata?
> 
> Sort of. It also plays tricks on the human by working out what icons are
> visible and loading those first then filling in while the user thinks it
> is ready
> 

See, I don't think that's a trick, isn't it just a form of demand
paging?  It seems silly to make the user wait to see the visible icons
until it's done rendering the hidden stuff.  Otherwise navigating the
file system speeds up and slows down based on how many files are in each
directory, even if the number of visible icons remains constant.

Do most Linux GUI apps really render everything without regard to what's
obscured and what's visible?

Lee

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Marcin Dalecki]

>
> Do most Linux GUI apps really render everything without regard to  
> what's
> obscured and what's visible?

Yes. Naive usage of backing store is right now pretty much the norm.  
However the
problem isn't the fact that the rendering occurs. The problem is that  
it occurs synchronously
and that composition is serializing with event handling.

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Oliver Neukum]

Am Montag, 9. Januar 2006 18:31 schrieb Alan Cox:
> On Llu, 2006-01-09 at 17:53 +0100, Oliver Neukum wrote:
> > Does the Windows Explorer draw icons based only on name and metadata?
> 
> Sort of. It also plays tricks on the human by working out what icons are
> visible and loading those first then filling in while the user thinks it
> is ready

That's lazy evaluation. Actually quite clever.

	Regards
		Oliver

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Bernd Petrovitsch]

On Mon, 2006-01-09 at 11:41 -0500, Lee Revell wrote:
> On Mon, 2006-01-09 at 17:29 +0100, Bernd Petrovitsch wrote:
> > On Mon, 2006-01-09 at 11:19 -0500, Lee Revell wrote:
[....]
> > > I think you'll get at most a 10% or 20% speedup by improving the kernel,
> > > while some of these apps (think Nautilus vs Windows Explorer) will need
> > > to be 1000% faster to seem reasonable to a Windows user.
> > 
> > That's easy: Just start nautilus, OOorg, Firefox, a java-vm and
> > GNOME/KDE infrastructure at login time in the background (*eg* and
> > mlockall() the more important ones so that the are surely in RAM) and
> > "starting the app" is only a small program connecting to the respective
> > process to get a fork() there (e.g. like the "-remote" parameter in the
> > Mozilla family).
> 
> Have you tried this?  I suspect it still takes at least twice as long as
> on windows.

No, I don't run all on them at once (only xemacs, firefox and the above
forgotten evolution on XFCE) and if, the hosts I'm usually working on
have probably not enough RAM for mlockall(MCL_CURRRENT).
And AFAIK there are no small starter programs and features - only for
Mozilla and cousins.

> For example on my system there was already a "nautilus" process but
> "Places -> Home Folder" still took ~2 seconds to display anything, and
> ~8 seconds to completely render the window and icons.  On Windows this
> takes much less than a second.

Hmm, what happens on the click:
- The click is transported via X, TCP/IP to the application.
- The app decides what to do and generates anew window and content.
- If swapped out, swap it in.
- Load the home directory and what else is needed for displaying it
  (Icons, etc.) from the disk.
- Load these images into the X server.

Id a completely new progrma is started, you must load it from disk, wait
for the shared linker, let it initialize everything and *then* it is
actually usable (and I hate that default OO.org feature that it puts the
window in foreground after startup  at least three times until the
document is loaded).

If you have a memory hog like firefox with a large page loaded then lots
of RAM are occupied anyways and no one except firefox can do anything
about it (without swapping out and this is also slow). And I have just
to switch tabs to hear my disk working.

Ths point is: You have to analyze *where* the apps spend that much time
(independent of being idle wehile waiting for disk I/O or busy moving MB
of graphic data around). It doesn't make that much sense to improve the
(e.g.) 2% in the kernel by 50% since that would bring next to nothing.

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Alistair John Strachan]

On Monday 09 January 2006 16:41, Lee Revell wrote:
> On Mon, 2006-01-09 at 17:29 +0100, Bernd Petrovitsch wrote:
> > On Mon, 2006-01-09 at 11:19 -0500, Lee Revell wrote:
> > > On Mon, 2006-01-09 at 17:14 +0100, Oliver Neukum wrote:
> > > > Am Montag, 9. Januar 2006 17:04 schrieb Lee Revell:
> > > > > On Mon, 2006-01-09 at 17:02 +0100, Oliver Neukum wrote:
> > > > > > Am Montag, 9. Januar 2006 16:15 schrieb Lee Revell:
> > > > > > > On Mon, 2006-01-09 at 15:28 +0100, Oliver Neukum wrote:
> > > > > > > > Am Montag, 9. Januar 2006 15:18 schrieb Robert Hancock:
> > > > > > > > > Yaroslav Rastrigin wrote:
> > > > > > > > > > Well, I could find more or less reasonable explanation of
> > > > > > > > > > this behaviour - different VM policies of two OSes and
> > > > > > > > > > strangely strong and persistent belief "Free RAM is a
> > > > > > > > > > wasted RAM" among kernel devs. Free RAM is not a wasted
> > > > > > > > > > RAM, its a memory waiting to be used ! Whenever it is
> > > > > > > > > > needed by apps I'm launching or working with.
> > > > > > > > >
> > > > > > > > > There is no different VM policy here, Windows behaves quite
> > > > > > > > > similarly. It does not leave memory around unused, it uses
> > > > > > > > > it for disk cache.
> > > > > > > >
> > > > > > > > That doesn't mean that the rate of eviction is the same.
> > > > > > > > Is it possible that read-ahead is not aggressive enough?
> > > > > > >
> > > > > > > Enough for what?  What is the exact problem you are trying to
> > > > > > > solve?
> > > > > >
> > > > > > Quicker application startup.
> > > > >
> > > > > Why do you look to the kernel first?  The obvious explanation is
> > > > > that Linux desktop apps are more bloated than their Windows
> > > > > counterparts.
> > > >
> > > > It is the most efficient place. An improvement to the kernel will
> > > > improve all starting times.
> > >
> > > I think you'll get at most a 10% or 20% speedup by improving the
> > > kernel, while some of these apps (think Nautilus vs Windows Explorer)
> > > will need to be 1000% faster to seem reasonable to a Windows user.
> >
> > That's easy: Just start nautilus, OOorg, Firefox, a java-vm and
> > GNOME/KDE infrastructure at login time in the background (*eg* and
> > mlockall() the more important ones so that the are surely in RAM) and
> > "starting the app" is only a small program connecting to the respective
> > process to get a fork() there (e.g. like the "-remote" parameter in the
> > Mozilla family).
>
> Have you tried this?  I suspect it still takes at least twice as long as
> on windows.
>
> For example on my system there was already a "nautilus" process but
> "Places -> Home Folder" still took ~2 seconds to display anything, and
> ~8 seconds to completely render the window and icons.  On Windows this
> takes much less than a second.

Sounds like a broken configuration to me. Of course the usual array of 
hardware specs, configuration, filesystem, free RAM, etc. all play into this, 
but no KDE application, including the originally cited Kate, takes longer 
than 1s to start on this machine (1.6GHz P-M, 2MB L2, 400MHz FSB, 1GB 
PC2700).

Hell kfm is probably a hell of a lot more bloated than Nautilus and it's 
pretty fast to start first time (1-2s), and cached it's pretty much 
instantaneous (I'd say less than 400ms). Fast enough, no?

Sounds like the kernel is plenty fast.

-- 
Cheers,
Alistair.

'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Lee Revell]

On Tue, 2006-01-10 at 01:44 +0000, Alistair John Strachan wrote:
> Sounds like a broken configuration to me. Of course the usual array of
> hardware specs, configuration, filesystem, free RAM, etc. all play
> into this, but no KDE application, including the originally cited
> Kate, takes longer than 1s to start on this machine (1.6GHz P-M, 2MB
> L2, 400MHz FSB, 1GB PC2700).
> 
> Hell kfm is probably a hell of a lot more bloated than Nautilus and
> it's pretty fast to start first time (1-2s), and cached it's pretty
> much instantaneous (I'd say less than 400ms). Fast enough, no?
> 

I don't think it's a broken configuration, just a slow machine (600MHz
VIA C3).  Windows XP screams compared to Linux on this thing.

Lee

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Jakob Oestergaard]

...
> > Hell kfm is probably a hell of a lot more bloated than Nautilus and
> > it's pretty fast to start first time (1-2s), and cached it's pretty
> > much instantaneous (I'd say less than 400ms). Fast enough, no?
> > 
> 
> I don't think it's a broken configuration, just a slow machine (600MHz
> VIA C3).  Windows XP screams compared to Linux on this thing.
> 

Guys... Apples and oranges and stuff.

My mother is running KDE on Linux now because (among other things)
windows explorer was unbearably slow for displaying folders with image
thumbnails  (very large images and lots of them).

Changing from an older 433MHz Celeron with too little memory to a 2.6
GHz P4 with a gig of memory was not enough. We tried quite a few things,
but I ended up giving KDE on Linux (Debian, not that it matters) a try.

I don't know Nautilus and I don't care - but I can say that there are
definitely situations in which KDE on Linux seriously and thoroughly
kicks MS butt both when it comes to simple usability and availability of
"good" software, and not least when it comes to the part of usability we
call "performance".  Getting the job done in time - and if something
takes a while to process, being able to do it in the background and
letting the user use the computer meanwhile.

This is not a kernel thing. There is proper desktop software out there -
go use it already  :)

My 0.02 Euro, for what it's worth,

-- 

 / jakob

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Jesper Juhl]

On 1/10/06, Jakob Oestergaard <jakob@unthought.net> wrote:
> ...
> > > Hell kfm is probably a hell of a lot more bloated than Nautilus and
> > > it's pretty fast to start first time (1-2s), and cached it's pretty
> > > much instantaneous (I'd say less than 400ms). Fast enough, no?
> > >
> >
> > I don't think it's a broken configuration, just a slow machine (600MHz
> > VIA C3).  Windows XP screams compared to Linux on this thing.
> >
>
> Guys... Apples and oranges and stuff.
>
> My mother is running KDE on Linux now because (among other things)
> windows explorer was unbearably slow for displaying folders with image
> thumbnails  (very large images and lots of them).
>
> Changing from an older 433MHz Celeron with too little memory to a 2.6
> GHz P4 with a gig of memory was not enough. We tried quite a few things,
> but I ended up giving KDE on Linux (Debian, not that it matters) a try.
>
> I don't know Nautilus and I don't care - but I can say that there are
> definitely situations in which KDE on Linux seriously and thoroughly
> kicks MS butt both when it comes to simple usability and availability of
> "good" software, and not least when it comes to the part of usability we
> call "performance".  Getting the job done in time - and if something
> takes a while to process, being able to do it in the background and
> letting the user use the computer meanwhile.
>
> This is not a kernel thing. There is proper desktop software out there -
> go use it already  :)
>
> My 0.02 Euro, for what it's worth,
>
I have been using an 800MHz VIA C3 based box (256MB RAM) at work a
while back, running Slackware Linux 10.2 with XFCE as the desktop and
it's very usable - quite snappy infact. Even KDE runs resonably well
on that box once you turn off some of the eyecandy. I have no idea how
the box would run Win XP, but it's certainly quite fine as a Linux
workstation IMHO.

--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Lukas Hejtmanek]

Hello,

On 9 January 2006 9:07, Yaroslav Rastrigin wrote:

> Whom and how much should I pay to have correct support for intel graphics
> chipset, 2200BG Wi-Fi, complete suspend-to-disk/suspend-to-ram and to get an 
> overall performance boost ? 

what kind of problems do you have with 2200BG? I think, that ip2200.sf.net
project is pretty good. For me, it works nicely (2915ABG).

For intel graphics - use your money and force Intel to release docs at least 
about setting graphics mode on 830-945 chipsets. I'm open to contribute code
then. (As I did some hacking into X driver without docs just guessing).
Or gain NDA and docs from local Intel authorize reseller.

I was asking local Intel representatives to sign NDA and receiving docs for i915
graphics to provide free closed source driver at least. But no success, they
told me, if Intel will not gain profit from it, no interest...

-- 
Lukáš Hejtmánek

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Lee Revell]

On Wed, 2006-01-11 at 00:48 +0100, Lukas Hejtmanek wrote:
> For intel graphics - use your money and force Intel to release docs at
> least about setting graphics mode on 830-945 chipsets. I'm open to
> contribute code then. (As I did some hacking into X driver without
> docs just guessing). Or gain NDA and docs from local Intel authorize
> reseller. 

Or spend your money on SoftICE for Windows and just reverse engineer it.

http://www.compuware.com/products/driverstudio/softice.htm

Lee

Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

[Lukas Hejtmanek]

On Tue, Jan 10, 2006 at 06:57:42PM -0500, Lee Revell wrote:
> On Wed, 2006-01-11 at 00:48 +0100, Lukas Hejtmanek wrote:
> > For intel graphics - use your money and force Intel to release docs at
> > least about setting graphics mode on 830-945 chipsets. I'm open to
> > contribute code then. (As I did some hacking into X driver without
> > docs just guessing). Or gain NDA and docs from local Intel authorize
> > reseller. 
> 
> Or spend your money on SoftICE for Windows and just reverse engineer it.
> 
> http://www.compuware.com/products/driverstudio/softice.htm

It would be easier to RE intel binary driver:
http://downloadfinder.intel.com/scripts-df-external/filter_results.aspx?strTypes=all&ProductID=2159&OSFullName=Linux*&lang=eng&strOSs=39&submit=Go%21

or VGA BIOS.

-- 
Lukáš Hejtmánek