> The Linux Documentation Project... full of duplication and stale information.
Sounds like a Wiki to me! Seriously, have you ever seen a Wiki that didn't contain off-topic, duplicate, or contradictory information?
In order for technical documentation to be usable, it must be clear, complete, correct, and current. The Wiki zealots *want* incomplete and unclear entries to encourage participation. IMHO, this reduces Wiki's usefulness for technical documentation.
Aren't all *recorded* versions of music still under copyright? Also, did you know that the sheet music for a public domain song can still be copyrighted? That's right, publishers can churn out new "arrangements" ad infinitum.
AFAIK, what *is* public domain is sheet music published before 1923. So you have to go back to the original sources. I've had good luck looking at the Library of Congress's site, American Memory.
IMHO, most students would be unfamiliar with (and quickly bored by) classical music anyway. They would probably be more familiar with folk songs and Christmas carols like "Silent Night". Why not teach them what they like and are familiar with?
> For starters, the train was at least 15 minutes late arriving at the station (in Kirkwood).
Only 15 minutes late! That must be a record! Of course, the train from Chicago *to* St. Louis is usually on-time (sometimes early).
> The downtown St. Louis Amtrak station is a disgrace. It looks like an old tin shack. Ever since our original station (Union Station) was decomissioned and turned into a shopping mall
LOL! It's so funny because it's true. I've made several trips from Chicago to St. Louis. Chicago's Union Station is a real train station and St. Louis has a hobo shack.
Why not move the St. Louis station back to the mall? Is this an Amtrak decision or a St. Louis decision?
> Then, our train stopped out in the middle of nowhere for at least 30 minutes, waiting for the track to clear up ahead.
That happens every time. Sometimes they explain they are waiting on freight train, switching crews, refueling, etc.
> felt like driving would have been the superior experience.
ROTFL! Typical St. Louisian! Probably suffering from separation anxiety from your car... There really should be a 12-step program or something.
From the article: "The kid down the street now has the capability of making a CD that sounds as good as one from Warner Music."
While DAW (Digital Audio Workstation) hardware and software prices are affordable, I don't think the kid down the street is yet capable of making a CD that sounds as good as one from Warner Music. With the exception of music created entirely with soft-synths, the kid still needs a good acoustic environment and quality microphones. Don't forget about the crucial mixing and mastering steps either.
The kid down the street can make a CD that's good enough. In the Pre-Web era, I remember listening to bands recorded on cassette 4-tracks. While the music was better than commercial radio at the time, the production left a lot to be desired. While recording with cheap Chinese-factory audio gear and a computer is an improvement over those days, I wouldn't say such a CD sounds "as good as one from Warner Music".
*Uggh* I did and I don't. You assume that all people who try to use Python have an undying love for it. Let me tell you that is definitely not the case!
I shudder at the thought of a large codebase like GC written in Python with everyone having different tab-stops or spacing. At least with C/C++, I can use the 'indent' utility to reformat someone else's code the way I like it.
> From the article: Quickly implement a Wiki or similar system... This will allow us to have an effective place to point users on gnucash-users and #gnucash instead of writing the same answers over and over again. It will also allow us to document bugs/workarounds for specific versions.
Wikis are not a good substitute for centrally-maintained user documentation! Wikis are based on the infamous "sandbox" model where everyone drops off their crap and the readers have to sort through the mess. Wikis usually contain unclear, incomplete, incorrect, duplicate, off-topic, and contradictory information.
Please don't do this, your users deserve better. Please use volunteers who centrally maintain the documentation, like you do with the code.
Agreed. Most Open Source documentation is unusable because it is either unclear, incomplete, incorrect, or out-of-date. But the second part of the question is: "How would you like to change that?" So here are some thoughts from a documentation volunteer on the front-lines...
First of all, name some famous Open Source programmers. Now name some famous documentation writers who aren't also famous programmers. See how hard that was? Documentation volunteers deserve more peer recognition in the Open Source community.
Next, Wikis suck for technical documentation so please don't use them. The problem isn't technical (which is what programmers focus on) but practical. Wikis are a "sandbox" model where everyone drops off their crap and readers have to sift through the mess to find useful information. You end up with unclear, incomplete, incorrect, duplicate, and contradictory entries. Use the time-tested "central maintainer" (a person or a team) model instead.
Lastly, if a documentation volunteer comes forward to help your project then treat them as part of your team. This includes treating them with respect. Don't assume all documentation volunteers are doing so because they can't code.
User Documentation: Most wanted... manuals that are readable off-line! Wikis suck! Don't give me the old excuse: "No one reads the manual..." Just because *you* don't read the manual doesn't mean others don't. Change this by giving documentation volunteers the same props as coders!
Packaging: This means easy installation *and* configuration. Sorry, XML or LISP-based config files are inscrutable for non-programmers. Release RPMS along with tarballs and stick to simple config files (or maybe an easy-to-use wizard front-end).
Usability: Have your non-programmer friends and family try to do common tasks. It can be enlightening.
Testing: How many times has the implementation of a new feature broken existing code? Consider implementing a regression testing suite. Don't accept new code or patches without an accompanying unit test.
Why use IM? The different protocols are incompatible with each other. While I suppose one could use a "swiss army knife" like Jabbber that includes them all, how about using the more open IRC protocol instead? That way, one has a choice of clients.
Also, one could more easily create a log of an IRC session that includes all participants. I imagine a log like this would help the lecturer to see what kinds of questions or comments his audience has. With this information, he could figure out which parts of his lecture were unclear or need more detail.
> knowing that 12 textbooks will cost you close to $1200, how are YOU going to decide what to buy?
As others have suggested, try before you buy. If you live in the United States, your public library will let you borrow a book from another library by filling out an Interlibrary Loan Request form. The ILRs that I've used didn't require a fee but some might. (Still be cheaper than buying the books.) The books came in a week or two after I filed the ILR.
> From the article: "QNX has been the only company so far to commercialize a microkernel OS..."
Doesn't the Mac OS X operating system use the Mach micro-kernel? Doesn't Apple sell the Mac OS X operating system? Therefore, QNX isn't the only company to commercialize a microkernel OS.
> Nobody these days makes a living manufacturing vacuum tubes
Ever hear of Sovtek tubes? They are used in guitar amps and effects pedals. Some people insist that tubes make audio signals sound "warmer" than the same signals routed through solid-state circuitry.
> Our company swears by Lotus Notes which means most documents are pored over by huge teams of people, everyone submits a comment or two which must be incorporated, and you end up with something truly collaborative that often doesn't make a whole lot of sense.
This is the same reason why Wikis don't work for technical documentation. It's the "litterbox" model where everyone just drops off their crap. The reader is left to sift through the resulting mess for something useful.
A better model is still the "central maintainer" model, where an accountable person or team reviews changes and tries to incorporate the good ones in a cohesive way. It's scalable if you use hierarchies of reviewers. Most large Open Source projects handle their source code in this manner.
> Really, at some point Linux needs to leave its fascination with SGML/DocBook behind. I hate it for so many reasons. It really sucks. A custom solution I think could do what DocBook does better, faster and with less hassle.
No, DocBook/SGML is entirely appropriate because it is a standard. As a documentation volunteer, I find no joy in having to relearn a DTD because the project maintainer wants to roll his own. I appreciate that once I learn the DocBook DTD, I can help other projects without re-learning anything.
Where Docbook needs improvement is better tools. So programmers like yourself should be helping documentation volunteers build these tools instead of re-inventing the (documentation standards) wheel!
It doesn't make sense for audio professionals to suddenly switch to Linux just to use a digital audio multi-track program. They're either locked into proprietary hardware (ProTools) or proprietary software (VST plug-ins).
A free digital audio multi-track program makes better sense for price-sensitive users like songwriters, unsigned bands, churches, high school drama departments, college radio stations, etc. However, the ardour project has been hostile to such users in the past by insisting that they use an expensive soundcard like the Hammerfall. So we'll see what happens.
Wikis are a lousy way to maintain technical documentation!
In order for technical documentation to be useful, it must be clear, complete, correct, and up-to-date. Wikis do nothing to insure these qualities. In fact, the best model for insuring them is a central maintainer (a person or a team). A central maintainer can also insure another quality missing from Wikis: consistency!
Slashdot Mirror
> The Linux Documentation Project... full of duplication and stale information.
Sounds like a Wiki to me! Seriously, have you ever seen a Wiki that didn't contain off-topic, duplicate, or contradictory information?
In order for technical documentation to be usable, it must be clear, complete, correct, and current. The Wiki zealots *want* incomplete and unclear entries to encourage participation. IMHO, this reduces Wiki's usefulness for technical documentation.
> Moby, Fatboy Slim, Massive Attack/Tricky, Joe Satriani ... drowned out by the crap that gets over-marketed to ensure high sales figures.
Yeah, it's not like you hear Moby, Fatboy, and Satriani on television commercials or anything... Oh, wait.
IANAL and I don't play one on tv either...
Aren't all *recorded* versions of music still under copyright? Also, did you know that the sheet music for a public domain song can still be copyrighted? That's right, publishers can churn out new "arrangements" ad infinitum.
AFAIK, what *is* public domain is sheet music published before 1923. So you have to go back to the original sources. I've had good luck looking at the Library of Congress's site, American Memory.
IMHO, most students would be unfamiliar with (and quickly bored by) classical music anyway. They would probably be more familiar with folk songs and Christmas carols like "Silent Night". Why not teach them what they like and are familiar with?
The last time I used gopher was in 1996 for The Well.
> For starters, the train was at least 15 minutes late arriving at the station (in Kirkwood).
Only 15 minutes late! That must be a record! Of course, the train from Chicago *to* St. Louis is usually on-time (sometimes early).
> The downtown St. Louis Amtrak station is a disgrace. It looks like an old tin shack. Ever since our original station (Union Station) was decomissioned and turned into a shopping mall
LOL! It's so funny because it's true. I've made several trips from Chicago to St. Louis. Chicago's Union Station is a real train station and St. Louis has a hobo shack.
Why not move the St. Louis station back to the mall? Is this an Amtrak decision or a St. Louis decision?
> Then, our train stopped out in the middle of nowhere for at least 30 minutes, waiting for the track to clear up ahead.
That happens every time. Sometimes they explain they are waiting on freight train, switching crews, refueling, etc.
> felt like driving would have been the superior experience.
ROTFL! Typical St. Louisian! Probably suffering from separation anxiety from your car... There really should be a 12-step program or something.
> Odds of actually achieving a useful, properly updated, set of data aren't actually zero, but they're pretty damn close.
Sounds like a Wiki!
What if the bad guys own a HERF gun?
Canon's Website has driver downloads for Windows XP and Mac OS X. But what about Linux?
From the article: "The kid down the street now has the capability of making a CD that sounds as good as one from Warner Music."
While DAW (Digital Audio Workstation) hardware and software prices are affordable, I don't think the kid down the street is yet capable of making a CD that sounds as good as one from Warner Music. With the exception of music created entirely with soft-synths, the kid still needs a good acoustic environment and quality microphones. Don't forget about the crucial mixing and mastering steps either.
The kid down the street can make a CD that's good enough. In the Pre-Web era, I remember listening to bands recorded on cassette 4-tracks. While the music was better than commercial radio at the time, the production left a lot to be desired. While recording with cheap Chinese-factory audio gear and a computer is an improvement over those days, I wouldn't say such a CD sounds "as good as one from Warner Music".
> Try it [Python], you'll like it.
*Uggh* I did and I don't. You assume that all people who try to use Python have an undying love for it. Let me tell you that is definitely not the case!
I shudder at the thought of a large codebase like GC written in Python with everyone having different tab-stops or spacing. At least with C/C++, I can use the 'indent' utility to reformat someone else's code the way I like it.
> Seriously, can anyone name ONE SINGLE advantage that C (or even C++) has over Python for this type of app?
YES!!! No semantically significant whitespace!
> From the article: Quickly implement a Wiki or similar system... This will allow us to have an effective place to point users on gnucash-users and #gnucash instead of writing the same answers over and over again. It will also allow us to document bugs/workarounds for specific versions.
Wikis are not a good substitute for centrally-maintained user documentation! Wikis are based on the infamous "sandbox" model where everyone drops off their crap and the readers have to sort through the mess. Wikis usually contain unclear, incomplete, incorrect, duplicate, off-topic, and contradictory information.
Please don't do this, your users deserve better. Please use volunteers who centrally maintain the documentation, like you do with the code.
> inaccurate or insufficient documentation.
Agreed. Most Open Source documentation is unusable because it is either unclear, incomplete, incorrect, or out-of-date. But the second part of the question is: "How would you like to change that?" So here are some thoughts from a documentation volunteer on the front-lines...
First of all, name some famous Open Source programmers. Now name some famous documentation writers who aren't also famous programmers. See how hard that was? Documentation volunteers deserve more peer recognition in the Open Source community.
Next, Wikis suck for technical documentation so please don't use them. The problem isn't technical (which is what programmers focus on) but practical. Wikis are a "sandbox" model where everyone drops off their crap and readers have to sift through the mess to find useful information. You end up with unclear, incomplete, incorrect, duplicate, and contradictory entries. Use the time-tested "central maintainer" (a person or a team) model instead.
Lastly, if a documentation volunteer comes forward to help your project then treat them as part of your team. This includes treating them with respect. Don't assume all documentation volunteers are doing so because they can't code.
Why use IM? The different protocols are incompatible with each other. While I suppose one could use a "swiss army knife" like Jabbber that includes them all, how about using the more open IRC protocol instead? That way, one has a choice of clients.
Also, one could more easily create a log of an IRC session that includes all participants. I imagine a log like this would help the lecturer to see what kinds of questions or comments his audience has. With this information, he could figure out which parts of his lecture were unclear or need more detail.
When did DVD players start generating TeX output?
> knowing that 12 textbooks will cost you close to $1200, how are YOU going to decide what to buy?
As others have suggested, try before you buy. If you live in the United States, your public library will let you borrow a book from another library by filling out an Interlibrary Loan Request form. The ILRs that I've used didn't require a fee but some might. (Still be cheaper than buying the books.) The books came in a week or two after I filed the ILR.
>Say, what's the fastest way to rename 1,000 files according to some regular expression on your Windows box?
Either use a current version of VBScript with the RegExp and FileSystemObject objects or use ActiveState's ActivePerl.
> They're planning to flood file sharing networks with Metallica "named" John Denver tunes to trick users.
Doesn't this violate John Denver's copyrights? I hope his estate drags them into court.
> From the article: "QNX has been the only company so far to commercialize a microkernel OS..."
Doesn't the Mac OS X operating system use the Mach micro-kernel? Doesn't Apple sell the Mac OS X operating system? Therefore, QNX isn't the only company to commercialize a microkernel OS.
> Nobody these days makes a living manufacturing vacuum tubes
Ever hear of Sovtek tubes? They are used in guitar amps and effects pedals. Some people insist that tubes make audio signals sound "warmer" than the same signals routed through solid-state circuitry.
> Our company swears by Lotus Notes which means most documents are pored over by huge teams of people, everyone submits a comment or two which must be incorporated, and you end up with something truly collaborative that often doesn't make a whole lot of sense.
This is the same reason why Wikis don't work for technical documentation. It's the "litterbox" model where everyone just drops off their crap. The reader is left to sift through the resulting mess for something useful.
A better model is still the "central maintainer" model, where an accountable person or team reviews changes and tries to incorporate the good ones in a cohesive way. It's scalable if you use hierarchies of reviewers. Most large Open Source projects handle their source code in this manner.
> Really, at some point Linux needs to leave its fascination with SGML/DocBook behind. I hate it for so many reasons. It really sucks. A custom solution I think could do what DocBook does better, faster and with less hassle.
No, DocBook/SGML is entirely appropriate because it is a standard. As a documentation volunteer, I find no joy in having to relearn a DTD because the project maintainer wants to roll his own. I appreciate that once I learn the DocBook DTD, I can help other projects without re-learning anything.
Where Docbook needs improvement is better tools. So programmers like yourself should be helping documentation volunteers build these tools instead of re-inventing the (documentation standards) wheel!
It doesn't make sense for audio professionals to suddenly switch to Linux just to use a digital audio multi-track program. They're either locked into proprietary hardware (ProTools) or proprietary software (VST plug-ins).
A free digital audio multi-track program makes better sense for price-sensitive users like songwriters, unsigned bands, churches, high school drama departments, college radio stations, etc. However, the ardour project has been hostile to such users in the past by insisting that they use an expensive soundcard like the Hammerfall. So we'll see what happens.
Wikis are a lousy way to maintain technical documentation!
In order for technical documentation to be useful, it must be clear, complete, correct, and up-to-date. Wikis do nothing to insure these qualities. In fact, the best model for insuring them is a central maintainer (a person or a team). A central maintainer can also insure another quality missing from Wikis: consistency!