|
|
Linux and Open Source News for 27th August 2006
|
Linux Today News Service
|
|
Source: Linux Today In today's world of handheld gadgets, the Nokia 770 is an unusual device, far different from the slim, multi-purpose items we're used to seeing
Source: Linux Today In this tip, Becker explains the process of configuring your Linux distribution for clusters and offers a helpful hint for using the top or ps programs to determine the process identification on a server
Source: Linux Today Recently, I did some benchmarking using Intel Pentium D processors and gigabit Ethernet. The data are pretty impressive
Source: Linux Today Receiving vast criticism for some time now has been NVIDIA's Linux department with their questionable release cycle, and with that NVIDIA has finally come to the table with their newest Linux display drivers
|
|
The O'Reilly Network ONLamp Articles and Weblogs
|
|
Source: ONLamp.com This is a final blog in a series that began with Part 1
and Part 2. In this series I’m presenting the results
of a research project to measure the effectiveness of two mailing
lists, which will be the start of what I hope to be a larger study.
How much noise is on the lists?
Figure 1 shows the breakdown of messages into the four categories I
defined in the Part 1. The precise breakdown is:
Category
Number of messages
Percent of total
Helpful
118
57
Irrelevant
54
26
New
28
14
Unhelpful
6
3
Figure 1. Categorization of messages by helpfulness
The low number of unhelpful messages is encouraging. But the high
number of irrelevant messages (even though some irrelevant messages
have value for list members in ways that don’t directly pertain to
solving technical problems) shows that participation in the list has
high overhead. And indeed, the volume of irrelevant messages forms a
common complaint among users of mailing lists.
Most lists contain off-topic threads, as well long threads about
non-technical issues such as upcoming conferences. As I indicated,
non-technical messages may be valuable for reasons of their own, and
if their subject lines are clear (not always the case) they can be
avoided be people who are uninterested in them.
But many technical threads also contain irrelevant messages. As one
example, a new user posted a question about hardware and was receiving
useful feedback when someone complained that he hadn’t asked the
question the right way. This led to a long series of messages about
the right way to ask the question, dragging along more and more
acrimonious accusations that the complainer was not being nice to
newbies. This exchange, involving a lot of correspondents, created so
many irrelevant messages on the thread that I had to be careful in
interpreting results to avoid letting it skew them.
There is no doubt that the exchange was distracting and wasteful. The
person who posted the original message took up time reading the
exchange; I know this because he threw in his own opinions a few times
and tried to justify the way he had asked his question.
Incidentally, this was one of the resolved threads—that is,
despite the noise on the thread, the answer to the technical question
eventually came. I thought the original correspondent would be scared
away forever, but in fact he was back the very next day with another
question. In one sense this is good: he stuck with Linux and with the
list. But in another sense it’s a bad result, because it shows he had
not learned enough about his system to solve his problems by
himself. I will explore the question of reader education in the
conclusion to this article.
How many references were offered to external sources of information?
A key goal of any mailing list should be to wean users from the
list. New users need help to find information, and even experts are
sometimes stumped, but every user should find himself or herself using
the list sparingly and should strive to become adept zt solving
problems without help. Another way to state this is that users should
evolve from questioners to respondents. This philosophy highlights
the value of pointing list members to outside sources of information.
Most of the 28 questions I recorded were specific and detailed enough
to show that questioners had worked quite a bit before resorting to
the list, and had made good-faith efforts to find information on their
own. Even so, one assumes that many questions are answered in release
notes, bug reports, project web pages, and other places that may be
hard to find. Therefore, one would expect answers to point to outside
documentation.
A simple check for references to URLs, as well as to books and to
traditional Unix documentation such as manpages and info pages, shows
that a modest amount of referencing occurs:
References to web pages or other URLs: 23
This is a decent number of references for a sample of 28 threads.
References to man or info pages: 6
These are traditionally found on the computer system along with the
software they document. The disparity between references to URLs and
references to this offline documentation shows that documentation is
moving online, where it can be updated dynamically. As evidence of
this trend, manpages and info pages can usually now be found online as
well as on the local computer system.
References to printed books: 0
This result gave me pause as a book editor in the Linux space. I was
not surprised by it, though, because in several years of sampling the
Linux-related lists I have never seen anyone recommend a book. Once or
twice a questioner explicitly requested advice on what book to get,
and received one or two replies. But there seems to be a macho
attitude in the Linux community toward solving problems through
experimentation and consultation of quick-reference material. On other
lists, I’ve seen many more recommendations for books.
The mere presence of references does not mean that the references are
useful. But they show that mailing lists are part of a larger learning
environment, and to some extent the members recognize that. However,
interaction with external references is very limited. People who post
references do not generally help the readers understand what to look
for in the documents or how they apply. I will expand on this point in
the conclusion.
Conclusion: the role of mailing lists
Mailing lists can be expeditious sources of information and can build
community. But the research behind this article suggests that mailing
lists fall short sometimes, and involve some inherent inefficiencies
even when they succeed in providing answers.
When someone comes to a mailing list, there are three possible
causes—three types of information failure:
The information has not been written anywhere. This is a common
problem, despite the vast amount of written computer
documentation. There are many subtleties in complex software that have
gone unexplained. Information may also be missing for bugs or quirks
in newly released software.
The information has been written, but it cannot be found. This
happens because web searches are not perfect, and few projects provide
well-organized collections of pointers to the relevant information
stored in idiosyncratic places.
The information has been written and can be found, but the user does
not know how to find it. This is part of the larger education problem
I have been discussing.
In the common case where someone is entering a command with the wrong
options, and someone provides the right ones, one might classify this
as the third type of information failure. After all, the questioner
had access to the documentation but misinterpreted it.
I’d like to reframe the viewpoint, though. If someone misinterpreted
documentation, he lacked the background knowledge to understand it. I
think this is a failure of the first type. What he needs is
documentation that helps him place the command and options in the
context of his needs. He needs background documentation. This is the
hardest type of documentation to produce, because mere academic
descriptions of systems offer little to most users.
The need for background is hard to explain to computer users, and hard
to define as a goal. My greatest concern is that mailing lists provide
answers too quickly and too easily. The questioner
may be guided toward a broader and deeper understanding of her system,
but often she is just told what to do to solve her problem with no
breadth or depth. She has been given a fish for today, but tomorrow
she may find herself marooned without a sinker attached to her hook.
On the other hand, the solution should not involve requiring every
user to read thousands of pages of background documentation before
touching the system. We need to find a path that combines John Dewey’s
classic doctrine of “learning by doing” with techniques for building
mental models that guide users to solving their problems. Community
support through mailing lists and IRC channels can certainly play a
role. But we don’t yet know how this works, and it probably works
differently for every individual. I think mailing lists could do a lot
more.
First, list members could work harder to investigate the questioner’s
problem. Certainly, this is hard to do when they are at remote
locations. It would be interesting to experiment with the use of
remote login to let experts look at a malfunctioning computer
system. Trust would have to be pretty high for this to work, though. A
more feasible solution that is often seen on mailing lists is for
experts to suggest commands to enter and symptoms to look for. If this
could be formalized into a troubleshooting procedure linked to common
symptoms, future users could benefit.
Furthermore, experts could give new users not only pointers to
documentation, but guidelines for what to look for. Reading technical
documents is a skill that grows with technical knowledge
So a mailing list can play a role in filling a gap between the
documentation and the user’s understanding. But list members should
understand the importance of providing this bridge. Mailing lists must
be seen as part of an information ecosystem in which they are one of
the most supple and fastest-moving creatures.
The data for this study is available in the form of the original mail messages (a gzipped tar file) and results of database queries.
Source: ONLamp.com Documentation and download are available at http://lejos.sourceforge.net/links.html. leJOS is the popular Java-based firmware for the first generation Lego Mindstorms RCX brick. This will be the final release of the firmware, and no surprise considering the recent release of the Lego Mindstorms NXT. So far as I tested, it is now compatible with Java 5.0. leJOS has been a blessing for me over the years. It was a part of my senior design project in college. I know many academics institutions still use it in programming and robotics classes. My thanks to the group’s work over the years.
|
|
The O'Reilly Network's Python DevCenter Articles and Weblogs
|
|
Source: Python DevCenter This week on the Perl 6 mailing lists
“My school’s punch card machines were in the same room
as the TRS-80 Model I (”THE COMPUTER ROOM”). These kids today with
their hula hoops and fax machines and intarwebs…”
– Chip Salzenberg, arguing in favor of lines in excess of
80-characters.
perl6-language
multi-line comments, C macros, & Pod abuse
Last week’s summary covered this thread, which discussed easily commenting
out a large chunk of code.
This week the discussion continued slightly in to the realm of meta-programming and
programming environments, but not much meat was added.
clarify: does "Dog is Mammal" load Mammal for you?
Mark Stosberg asked for clarification on S12 on whether class Dog is
Mammal requires Mammal to be loaded in advance. The current version
of Pugs needs an explicit use Mammal.
Darren Duncan believed an implicit use Mammal should only occur
conditionally, if a Mammal had been declared, but was concerned about
potential bugs. Jonathan Scott Duff had the impression that preloading
would not be required, and wondered if class Dog is Mammal-4.5 would
be valid. Trey Harris referenced S11 to claim that Jonathan’s questionable
syntax is valid. Andrew Suffield also tackled the question of versioned
libraries.
Heredoc issue in pugs.
Yiyi Hu wanted to know the correct syntax for heredocs, as S02 and Pugs
seem to be at odds. Larry Wall clarified that both are allowed.
Luke Palmer expressed concern about the false duality of :to and
:from. Larry noted that is why :from doesn’t actually exist.
Pair of lists = list of pairs?
Mark J. Reed asked how one would idiomatically write
my %h; @h{@keys} = @h{@values} in Perl 6. Gaal Yahas suggested using ¥, the
zip operator: my %h = @keys ¥ @values. Larry Wall suggested using a hyper
pair: my %h = @keys »=« @values.
clarifying the spec for 'ref'
Mark Stosberg wanted Perl 6 to retain the Perl 5 responses to ref or justify
the change in the documentation. Larry Wall explained that ref will not
exist in Perl 6; instead, it will be something like .what, which will return
the type itself, rather than a string.
The thread then moved on to subclassing, after Luke Palmer suggested that
Array would be a subtype of Array::Const, after Larry had stated the
reverse. This led to a lengthy discussion on the subject.
My first functional perl6 program
Mark J. Reed posted a simple program he wrote in Perl 6 for educational
purposes, asking for critique.
This lead to a discussion on the semantics of hyperoperators in relation
to finite/infinite sequences.
perl6-internals
[perl #40162] [PATCH] parrot/trunk/docs/art/pp001-intro.pod - spelling
Last week,
in ticket [perl #40162], Amir E . Aharoni sent a patch to correct
some spelling errors.
It was applied as r14297.
[REPATCH] Parrot::Embed Take Two
Previously,
chromatic submitted a patch for the build file to try to resolve
pkg_config issues with various platforms. He had some questions about
installing from outside the Parrot tree on Windows. Leopold Toetsch
offered a suggestion.
This week, François
Perrard explained how to solve the Windows issue.
[perl #40204] line numbers of runtime errors are one too low
Chip Salzenberg created ticket [perl #40204] because runtime
errors are off by one line. Leopold Toetsch thought this was the
same error reported in [perl #38594], but Will Coleda disagreed.
There was some discussion on when new tickets should be created.
SKIPs Are Now a Code Smell
chromatic made two commits to unskip some valid tests. He was
concerned about the large number of tests which are being skipped
in Parrot. He suggested unskipping all tests which might pass,
and use TODO or deletion depending upon the relevance of the test.
This was added as a Cage Cleaner’s task.
[perl #40207] [PATCH] tools/dev/install_files.pl - replace tabs with spaces
Amir E . Aharoni created the ticket, [perl #40207], in which he supplied a
patch that corrects the indentation of tools/dev/install_files.pl.
[perl #40209] [TODO] convert t/compilers/pge/p6regex/01-regex.t to PIR
Will Coleda wanted the tests in PIR instead of Perl to make make test
faster and to give a template for other test conversions. See
ticket [perl #40209].
[perl #40210] [TODO] Provide a way for PGE's dump to go to string
In ticket [perl #40210],
Will Coleda noted that it would be useful to get a string when dumping,
for testing. Patrick R. Michaud created the dump_str method in r14306.
End the Hollerith Tyranny? (linelength.t)
Chip Salzenberg asked if anyone has any reservations from making the parrot’s
source code repository follow a wrapping convention of over 80 columns. Some
people said they were old enough to have used terminals that couldn’t
physically support that, at which point Chip showed them he was actually
older.
It seems that the general consensus is to try to aim for 80 columns, but that
a hard limit of 100 will be set for when that doesn’t work well.
[svn:parrot-pdd] r14308 - in trunk: . cage docs docs/art docs/dev docs/imcc docs/pdds docs/pdds/clip docs/stm languages languages/tcl/docs lib/Pod/Simple t/distro
Joshua Hoblitt replied to a commit with a reminder that there is a
utility for formatting Parrot’s Pod.
#ParrotSketch Meeting 22AUG06
Will Coleda posted the URL of the 22 August
#ParrotSketch log.
[perl #40217] Parrot_autoload_class() knows about Python and Tcl
Chip Salzenberg wanted hardcoded language names in Parrot removed.
This came up in ticket [perl #40217].
LLVM and HLVM
John Siracusa wondered if anyone had looked at LLVM recently and wondered
if Parrot might be able to target LLVM bytecode and let it do further
optimization for OS X. Peter Baylies responded that he’d looked at it,
and was currently waiting for an x86-64 build. Peter was not sure
there were benefits in targeting LLVM. Aaron Sherman added that the extra
layers would probably not make up for any optimization gains.
[perl #40218] [BUG] - get_*_global opcodes throw exceptions
In ticket [perl #40218], Matt Diephouse noted that the documentation
of get*hll says “If the global doesn’t exist, $1 is set to null” but
currently it throws an exception.
[perl #40219] [TODO] - Steal Perl5's sprintf tests
Matt Diephouse created ticket [perl #40219]. He suggested using
Perl 5’s sprintf tests instead of writing new ones.
[perl #40225] Making Makefiles…
Will Coleda created ticket [perl #40225] to address the new
features he’d like in genfile() when generating makefiles.
Leopold Toetsch thought that instead of inventing custom make extensions,
there should be a few needed gmake extensions. Will agreed with stealing
gmake syntax. Joshua Hoblitt disagreed with the proposal. Will responded.
Announcing the Perl 6 and Parrot wiki workspaces
Andy Lester announced the
Perl 6 and
Parrot wikis.
[perl #40231] [PATCH] t/compilers/pge/06-grammar.t written in PIR
Nuno Carvalho rewrote t/compilers/pge/06-grammar.t in PIR and put
it in ticket [perl #40231].
Dumb Configure.pl question
Mark J. Reed was running in to problems with linking when
building Parrot on OS X.
Will Coleda listed some arguments that can be used in
configuration to support linking.
Find out in program code, if a PMC-property is set?
Gerd Pokorra had issues extracting a PMC property when that property
has not been explicitly set, and wondered how one could go about
introspecting the PMC to determine whether or not a property is set.
Bob Rogers advised checking PMC_IS_NULL.
String.to_int() vs. opcode
Chip Salzenberg posted in response to Leopold Toetsch’s addition of
to_int() to String. Chip suggested making it a common subroutine in
the C source. Will Coleda disagreed on the grounds that it is a method,
not an opcode, and that not everything needs to be a PMC. Jerry Gay
agreed with Chip. Chip also replied.
[perl #40210] [TODO] Provide a way for PGE's dump to go to string
Will Coleda created a ticket asking for PGE’s dump to be able to go to a
string, and not just output, for testing purposes. Patrick R. Michaud added a
dump_str method in r14306, and then closed the ticket.
perl6-users
junctions and autothreading
Amir E. Aharoni wanted to know what the status of ‘autothreading’ was,
after seeing some tantalizing references to it. Conrad Schneiker
didn’t know, but suggested that looking at the
#perl IRC log search
as another document resource.
a practical question
Richard Nabil Hainsworth wanted to know how he could write an application
in Perl 6 which works with GUI toolkits such as WxWidgets.
Conrad Schneiker had a similar interest, although he focused on
XPCOM, XUL and other Mozilla GUI technologies.
Steffen Schwigon suggested some experimentation with using Perl 5
libraries, and requested that Richard document his experiences.
Latest $1,000 Wiki for Perl 6 proposal/offer.
Conrad Schneiker brought up the long-running subject of the Perl 6 wiki
bounty (refer to summaries for July and June for more information on the
history of this topic). He hoped that TPF could determine the conditions
of the contest. Andy Lester replied that he was in the process of
setting up a wiki for Perl documentation. Conrad asked a few questions
about Andy’s plans.
Meanwhile, Paul Fenwick asked how PerlNet could improve to meet the
needs of the Perl community. Conrad and Amir E. Aharoni responded.
Same-named arguments
Michael Snoyman wanted to know what would happen if there was a
parameter list which included variables of a different type but the
same name. He included the results he got when trying it. Juerd
said he felt it should cause a compile time failure or a warning.
Michael reposted the message to the language mailing list:
Same-named arguments.
IO::Socket, or any IO
Michael Snoyman wanted to know what the Pugs version of IO::Socket
is.
perl6-compiler
Integrating the Pugs test suite into the Synopses
Agent Zhang announced that the test snippets in the Pugs test suite
have now been included in the Synopses, thanks to
smartlinks.
Ponie has been put out to pasture
Jesse Vincent announced the end of the Ponie project. Making
Perl 5 code run seamlessly alongside Perl 6 in Parrot is still
a goal, but it is being addressed in other ways.
pugs: rw block parameters
Mark J. Reed wanted to know if rw parameters for blocks had been
implemented. Larry Wall agreed that it was not currently working.
Audrey Tang made clarification in r12675. Tests (37 and 38)
were added to for.t for the situation Mark described, as r12968.
Pugs bugs
Mark J. Reed wondered if Pugs bugs were stored somewhere, so that he
could avoid mentioning known bugs. He included some questions.
Larry Wall replied that in Pugs,
a bug is represented by a failing test. He also answered questions.
Acknowlegements
Yuval Kogman once again contributed summaries for some of the threads.
This summary was prepared using
Mail::Summary::Tools,
now available on CPAN.
If you appreciate Perl, consider contributing to the Perl
Foundation to help support the
development of Perl.
Thank you to everyone who has pointed out mistakes and offered
suggestions for improving this series. Comments on this summary can be
sent to Ann Barcomb, kudra@domaintje.com.
Distribution
This summary can be found in the following places:
use.perl.org
The pugs blog
The perl6-announce mailing list
ONLamp
See Also
Perl Foundation activities
Perl 6 Development
Planet Perl Six
|
|
