I wrote OProfile, and I currently use DTrace daily, and I can assure you that you are wrong when you claim they do the same thing.
OProfile is useful for measuring system-wide resource consumers (for example, you can see what pieces of code are causing cache misses in the kernel when your apache process is in the kernel etc, or which user processes take up the most CPU time).
DTrace can also do something similar (though it needs a little more work yet). But DTrace does a LOT more than this. Imagine a system-wide (kernel, binaries, libraries) 'strace', where you can trivially choose what to print out, and what parts to strace, and under what circumstances. DTrace does even more than that.
OProfile can't tell you exactly why your system call is returning EINVAL. OProfile can't tell you why your application is causing cross-calls. OProfile can't tell you what processes are writing to what files, in real time. OProfile can't debug race conditions.
OProfile is a profiler: it does its job and nothing more. DTrace is, essentially, an instrumentation suite; one of its abilities is to function as a simple profiler.
You won't really get a notion of why DTrace is so useful until you try it.
There's nothing unique or special in Linux kernel programming as compared to hacking on, say, Mono, or KDE.
You get into the projects in exactly the same way: start off doing some small useful things (docs, janitor work, UI design, whatever) and then sooner
or later you'll inevitably find yourself maintaining a driver or whatever. Next thing you're making changes to sub system APIs, and you work from there.
There's no magic and there is no cabal.
If you're asking about specific organisations to help you on the way in, the other posters have
already mentioned kernel janitors and kernel newbies, both of which are good.
I became a kernel hacker through a rather unusual route: my M.Sc. supervisor spotted
missing functionality and suggested I had a crack at it.
Which is particularly odd, given that this is where usability is most important.
> ask yourself when it was the last time that one pixel away
Please google for "Fitt's Law".
> *Feeling* that something is clumsy is part of a UI review
"It's clumsy" is of zero use, except for satisfiability measurement. You need to know *why*.
> Isn't time that we change this?
Users do not want to, should not feel obliged to, and not generally able to give useful feedback.
If you read the article, it's not stating that proprietary software has generally better usability than free software at all. It is a reasonably balanced article looking at some of the reasons why open-source software tends to produce fast and stable applications, but does not do so well with usability.
> that won't improve its usability if you don't know what people think about it.
For starters, this is wrong. Several projects are in fact heavily-used by a range of user classes.
Secondly, this really doesn't help much. Talking to users is a notoriously poor way of improving usability. It is useful in concert with other methods, but on its own, it is not particularly useful, and can even be harmful.
Users do not generally have a really good grasp on the minutae of bad UI. They simply don't notice that, for example, KDE 2's task menu is one pixel away from the side of the screen. The feedback you tend to get is most useful for finding what features are used and where they go wrong.
A tiny minority of users will ever complain "hey, this option takes 1 second to respond". They will *feel* it (the application will feel sluggish and clumsy), but they are not generally able to review UI themselves. Only the most obvious stupidities get noticed.
Remember, for the typical project, only a small minority of users give feedback *AT ALL*. And of those who do, the vast majority are power users of the application. As a result, the feedback you get will be necessarily skewed towards the power user end of things - not good.
Asking users/really/ doesn't work.
What developers need to do is:
o give careful thought to every single patch that introduces or changes the UI
o review mercilessly
o apply heuristic guidelines
o listen to users (despite the above, it can still be valuable input)
o if possible, do actual tests in labs with users
This stuff is starting to happen now, but there is a long way to go. Like you say, developers need to learn to write good UI like they write good code - for *others* to read and use.
I notice you're quick to assume the reason must be some alleged grudge between Red Hat and the KDE people. From where do you derive this ?
To horribly paraphrase [disputed origin elided], you are too quick to attribute conditions to villainy that simply result from the fact nobody has actually done it yet.
It is (debatably) an improvement, but it is most definitely not "really cleared up".
It is simply not discoverable. Think about it - what possible reason would the user have for starting to drag the disk somewhere ? There is nowhere visible to drag it to !
Changing the icon when a drag has started is exactly when it is too late.
[My dad, btw, actually made himself an extra trashcan with an eject disk icon. That is - it was SO confusing, even a user capable of doing this preferred to have a separate always-visible widget that provided a clear dialogue.]
Re:Market for commercial programming tools for Lin
on
Valgrind 1.0.0 Released
·
· Score: 2, Informative
Here's some suggestions:
1) don't charge such an absurdly large price for software mostly built on free software (Mikael's perfctr)
2) accept that when you have competition that is free software, it's gonna beat you.
[Disclaimer: I am indeed the lead developer for your competition]
You miss the fact that more often that not, WYSIWYG/gets in the way/. I'm writing content, I expect and need LaTeX to handle the presentation. WYSIWYM is not an "excuse", it's a definite feature. In LyX, when I'm editing a document, I see what I need to see and nothing more. Where page breaks happen, thanks to LaTeX, is irrelevant for 99% of the editing I do. I don't want to be distracted by that.
The benefit of using LyX is that it can do both LaTeX and DocBook
output. That means it can basically export to any
useful format you might need (although MS-Word
.doc output might be a little awkward).
Don't discount DocBook just because it's a pig to
install and set up, it is a professional and pretty
well-designed documentation solution. Talk to the
LinuxDoc people if you don't believe me (who,
incidentally, are still considering making LyX the semi-official
application for editing their HOWTOs).
Jeremy's description was misleading, it is nothing
like top. Think more of a gprof that can profile
anything, for various different events of interest.
Slashdot Mirror
I wrote OProfile, and I currently use DTrace daily, and I can assure you that you are wrong when you claim they do the same thing.
OProfile is useful for measuring system-wide resource consumers (for example, you can see what pieces of code are causing cache misses in the kernel when your apache process is in the kernel etc, or which user processes take up the most CPU time).
DTrace can also do something similar (though it needs a little more work yet). But DTrace does a LOT more than this. Imagine a system-wide (kernel, binaries, libraries) 'strace', where you can trivially choose what to print out, and what parts to strace, and under what circumstances. DTrace does even more than that.
OProfile can't tell you exactly why your system call is returning EINVAL. OProfile can't tell you why your application is causing cross-calls. OProfile can't tell you what processes are writing to what files, in real time. OProfile can't debug race conditions.
OProfile is a profiler: it does its job and nothing more. DTrace is, essentially, an instrumentation suite; one of its abilities is to function as a simple profiler.
You won't really get a notion of why DTrace is so useful until you try it.
You get into the projects in exactly the same way: start off doing some small useful things (docs, janitor work, UI design, whatever) and then sooner or later you'll inevitably find yourself maintaining a driver or whatever. Next thing you're making changes to sub system APIs, and you work from there.
There's no magic and there is no cabal.
If you're asking about specific organisations to help you on the way in, the other posters have already mentioned kernel janitors and kernel newbies, both of which are good.
I became a kernel hacker through a rather unusual route: my M.Sc. supervisor spotted missing functionality and suggested I had a crack at it.
> I won't talk about the desktop enviroment.
Which is particularly odd, given that this is where usability is most important.
> ask yourself when it was the last time that one pixel away
Please google for "Fitt's Law".
> *Feeling* that something is clumsy is part of a UI review
"It's clumsy" is of zero use, except for satisfiability measurement. You need to know *why*.
> Isn't time that we change this?
Users do not want to, should not feel obliged to,
and not generally able to give useful feedback.
If you read the article, it's not stating that
proprietary software has generally better usability than free software at all. It is a reasonably balanced article looking at some of
the reasons why open-source software tends to
produce fast and stable applications, but does
not do so well with usability.
> that won't improve its usability if you don't know what people think about it.
I don't know how you came to that conclusion.
> BECAUSE NOBODY USES IT
/really/ doesn't work.
:
For starters, this is wrong. Several projects
are in fact heavily-used by a range of user classes.
Secondly, this really doesn't help much. Talking
to users is a notoriously poor way of improving
usability. It is useful in concert with other
methods, but on its own, it is not particularly
useful, and can even be harmful.
Users do not generally have a really good grasp
on the minutae of bad UI. They simply don't notice that, for example, KDE 2's task menu is one pixel away from the side of the screen. The feedback you tend to get is most useful for finding what features are used and where they go wrong.
A tiny minority of users will ever complain "hey,
this option takes 1 second to respond". They will
*feel* it (the application will feel sluggish and clumsy), but they are not generally able to review UI themselves. Only the most obvious stupidities get noticed.
Remember, for the typical project, only a small minority of users give feedback *AT ALL*. And of those who do, the vast majority are power users of the application. As a result, the feedback you get will be necessarily skewed towards the power user end of things - not good.
Asking users
What developers need to do is
o give careful thought to every single patch that
introduces or changes the UI
o review mercilessly
o apply heuristic guidelines
o listen to users (despite the above, it can still be valuable input)
o if possible, do actual tests in labs with users
This stuff is starting to happen now, but there is
a long way to go. Like you say, developers need to learn to write good UI like they write good code - for *others* to read and use.
> it's simply juvenile note releasing
I notice you're quick to assume the reason must
be some alleged grudge between Red Hat and the
KDE people. From where do you derive this ?
To horribly paraphrase [disputed origin elided],
you are too quick to attribute conditions to villainy
that simply result from the fact nobody
has actually done it yet.
Wrong.
It is (debatably) an improvement, but it is
most definitely not "really cleared up".
It is simply not discoverable. Think about it -
what possible reason would the user have for
starting to drag the disk somewhere ? There is
nowhere visible to drag it to !
Changing the icon when a drag has started is
exactly when it is too late.
[My dad, btw, actually made himself an extra
trashcan with an eject disk icon. That is -
it was SO confusing, even a user capable of
doing this preferred to have a separate always-visible widget that provided a clear
dialogue.]
Here's some suggestions :
1) don't charge such an absurdly large price
for software mostly built on free software
(Mikael's perfctr)
2) accept that when you have competition that
is free software, it's gonna beat you.
[Disclaimer: I am indeed the lead developer for
your competition]
You miss the fact that more often that not, /gets in the way/. I'm writing content,
WYSIWYG
I expect and need LaTeX to handle the
presentation. WYSIWYM is not an "excuse", it's a
definite feature. In LyX, when I'm editing
a document, I see what I need to see and
nothing more. Where page breaks happen, thanks
to LaTeX, is irrelevant for 99% of the editing
I do. I don't want to be distracted by that.
LyX is equally customisable too.
The benefit of using
LyX is that it can do both LaTeX and DocBook
output. That means it can basically export to any
useful format you might need (although MS-Word
.doc output might be a little awkward).
Don't discount DocBook just because it's a pig to
install and set up, it is a professional and pretty
well-designed documentation solution. Talk to the
LinuxDoc people if you don't believe me (who,
incidentally, are still considering making LyX the semi-official
application for editing their HOWTOs).
But then, I'm biased.
--
> I prefer 'top'.
Jeremy's description was misleading, it is nothing
like top. Think more of a gprof that can profile
anything, for various different events of interest.
FascDot, have you heard of meta-moderation ?