One problem with man pages is that you have to know what you're looking for with a certain degree of accuracy.
To take your example, let's have a brief search for what happens at startup:
$ man startup
No manual entry for startup
$ man -k startup
vga_disabledriverreport (3) - makes svgalib not emit any startup messages
$ man boot
No manual entry for boot
$ man -k boot
[Yields 10 entries, the most useful of which is the scary bootparams page...]
$ man -k initialization
[Yields 38 entries, almost all about Tcl/Tk or curses...]
The problem with man is no so much that the information is not there, it's more that there's just a single page for all levels and types of reader, and it's damn difficult to find out which page you want to read anyway.
Disclaimer: I don't really have any up-to-date info on this subject, I'm just interested too.
I think that the advanced aspects of theming, and the integration of widget themes, colour schemes, window decorations etc. all missed the cut-off date for KDE 2.0.
It's probable that the people who would be interested in getting theming moving for KDE2 are waiting for this code to be completed and rolled into an official release before they start any real work on themes.
Also, IIRC, mosfet had a tool for the creation of widget themes, but he's been head-down working on the widget code for for months now, so I think the tool has lapsed out of date.
I expect that themes won't be pushed as a selling point of KDE until at least 2.1...
Should I infer from this that there is a ++C language, which does not call the C language copy constructor - yielding an improved version of C without the (almost) complete backward compatibility?
While I find the flexibility and power of C++ to make it the best overall tool for my programming, I often find that when I get something wrong, the error is almost impossible to find.
What could be done to reduce the incidence of errors and improve the debuggability of C++ code, either through changes to the language, restricting the developer's freedoms, or by improvement of available tools.
Context: I have moved to Linux development from NT, and *really* miss BoundsChecker!
I doubt that simply ignoring objectionable posts will ever cause the people responsible for those posts to ever go away completely. OK, it probably does perpetuate the problem to get into conversation with these people, but if they persist in posting irrespective of the amount of activity they cause, then we have gained nothing by ignoring them. We have certainly lost something, however - anyone reading the message will see unworthy material going uncontested, and will think they we, the/. community, condone (or at least accept) these posts. This thread does demonstrate the basic effectiveness of moderation; reading with the threshold at 1, didn't see any of the material causing the furore.
Slashdot Mirror
One problem with man pages is that you have to know what you're looking for with a certain degree of accuracy.
To take your example, let's have a brief search for what happens at startup:
$ man startup
No manual entry for startup
$ man -k startup
vga_disabledriverreport (3) - makes svgalib not emit any startup messages
$ man boot
No manual entry for boot
$ man -k boot
[Yields 10 entries, the most useful of which is the scary bootparams page...]
$ man -k initialization
[Yields 38 entries, almost all about Tcl/Tk or curses...]
The problem with man is no so much that the information is not there, it's more that there's just a single page for all levels and types of reader, and it's damn difficult to find out which page you want to read anyway.
Disclaimer: I don't really have any up-to-date info on this subject, I'm just interested too.
I think that the advanced aspects of theming, and the integration of widget themes, colour schemes, window decorations etc. all missed the cut-off date for KDE 2.0.
It's probable that the people who would be interested in getting theming moving for KDE2 are waiting for this code to be completed and rolled into an official release before they start any real work on themes.
Also, IIRC, mosfet had a tool for the creation of widget themes, but he's been head-down working on the widget code for for months now, so I think the tool has lapsed out of date.
I expect that themes won't be pushed as a selling point of KDE until at least 2.1...
Matt.
Should I infer from this that there is a ++C language, which does not call the C language copy constructor - yielding an improved version of C without the (almost) complete backward compatibility?
:)
Send me the URL!
While I find the flexibility and power of C++ to make it the best overall tool for my programming, I often find that when I get something wrong, the error is almost impossible to find.
What could be done to reduce the incidence of errors and improve the debuggability of C++ code, either through changes to the language, restricting the developer's freedoms, or by improvement of available tools.
Context: I have moved to Linux development from NT, and *really* miss BoundsChecker!
I doubt that simply ignoring objectionable posts will ever cause the people responsible for those posts to ever go away completely. /. community, condone (or at least accept) these posts.
OK, it probably does perpetuate the problem to get into conversation with these people, but if they persist in posting irrespective of the amount of activity they cause, then we have gained nothing by ignoring them. We have certainly lost something, however - anyone reading the message will see unworthy material going uncontested, and will think they we, the
This thread does demonstrate the basic effectiveness of moderation; reading with the threshold at 1, didn't see any of the material causing the furore.