Maybe not, but your support staff can most certainly use lynx to browse the site. Then they see exactly what the customer using the braille reader is seeing. You don't need to be blind to verify that a site is unusable in lynx. And don't most browsers allow for viewing without loading images?
Seems to be a lot less trouble and effort than installing ramps and stalls to me. Last I checked, browsers with images turned off are far far cheaper.
Yeah, they were bought (stock swap if memory serves) by Caldera. Caldera now owns the UNIX trademark. It is now Caldera stock that Microsoft owns. Microsoft still owns shares in the company that owns the UNIX trademark.
On the contrary, I did in fact know that Novell bought the UNIX trademark and original source from AT&T. And a lot of companies' roadmaps are different today from what was planned several years ago. If you really want to take a trip down memory lane, remember that Microsoft made a port of UNIX called XENIX. It was on XENIX that a lot of their internal development was done in the early days. The division that developed XENIX was sold to SCO, a company in which Microsoft still owns stock to this day. Novell later sold their UNIX holdings to SCO. So when you really think about it, Microsoft owns a fair share of the UNIX trademark. Kinda makes you proud doesn't it?
NetWare has been a file/print box, but services can and have been written for it. I know. I worked for a software company that has a NLM version of their flagship product. Truth be told, the NLM version came out before the NT port (mostly because NT hadn't been released yet when they started on the server product). It could have been better, but then so can writing Windows device drivers and nice UNIX GUIs. But people do it. People still use NetWare. People still pay to have NetWare services rendered. It's not going anywhere anytime soon. It is in fact too well supported in many organizations for it to simply disappear. Interest > 0.
As for Perl/Win32, much of the work was done by ActiveState, but a sizeable chunk was done by the community. These two Win32 ports were merged a while back, but to say that the community had nothing to do with it is an overstatement to say the least. Also, Microsoft didn't pitch in the funds until after ActiveState had done quite a bit of work already. Microsoft currently helps fund the port. They most certainly didn't pay for it to be made.
Information has to be held somewhere; why not a database? The common misconception is that Btrieve and MySQL (or other relational databases) are equivalents. They are not. Btrieve is closer in concept to BerkeleyDB and variants.
Apples and oranges. And the network data has to be stored somewhere.
This has always been the case for compiling programs for Novell: a DOS/Windows box with compilers. This is nothing new or special with regard to Perl.
Just to share blame, why not address the issue that a large portion of Perl modules that use native code aren't portable outside of UNIX (and even then...).
Perl for NetWare is poorly supported, and does not support basic things such as fork(), chown, syscall, chroot, alarm, and about 20 other functions...
Ummm... Of course this is because NetWare itself doesn't have these functions. Current operating systems? UNIX is *how* old? NetWare by your metric IS the current operating system. As for network-wide security and administration, I'm sorry but Novell's offerings are superior and have been superior for years. NIS+? LDAP? Active Directory? Pshaw! NDS was already better than these years ago and eDirectory widens that margin.
Why does Novell need to update Perl? Because they bundle it? Why doesn't the Perl community maintain the port just like they do for every other operating system? Or is Novell special on your shitlist? It's not like Novell controls the Perl source.
And if they're not 100% sure, why are they touting it? For the same reason that commercial companies release before it's time: mindshare.
Yes, we know that an open beta from Apache is as good or better than an initial release from a commercial developer. We know that the stable releases from Apache are akin to the third (or so) patch release for a commercial product.
What's the difference? Quality? Not necessarily. The difference is in semantics. Some open source entities produce bad code (have you looked around on Freshmeat lately?) and some commercial software houses produce good code.
How can we tell which is better? Cutting the crap and testing the products in question. If having the source available is important to you, obviously the open source software will win out every time. If only package functionality matters to you, waving a banner won't determine the best choice.
As far as "gold" code, you're wrong. "Gold" code simply means that it's going to be released. It designates that a particular snapshot of the codebase is being burned onto CDs and put into a shrinkwrapped package. "Gold" refers to a baseline, not the quality of the baseline. If you replaced "gold" with "good", I'd agree with you.
And by that time, PostgreSQL 7.3 will be out of beta. Maybe even Linux kernel version 3.0!
If all goes as planned, MySQL 5 will be stable by 2007.
*sigh*
What would this world be like if software reviewers reviewed actual, released software for a change instead of all of these developer wishlists that may (or most likely not) get released sometime in the future?
Makes sense. If PostgreSQL were standard, no one would bother with their SDK. On the other hand, this guarantees that folks will be developing for the lowest common denominator. Oh well...
Does the SDK cost anything? If not, I guess it works out. If it does, Novell just marginalized itself a bit more.
...and the fact that Chimera doesn't have all of the features of Mozilla has *nothing* to do with it.
By the way, where were you when the Moz developers were saying that 1.0 was supposed to be the stable API to work on? I applaud you for developing on Moz, but to state that you had no warning about an API changing from under you is foolish. I'm sorry for your pain, but you knew that you were holding a hot poker.
Because the book's not about web applications. Replace your statement with: "How is developing a web application which will run only on GTK+ different from doing an IE-only website?"
Exactly. Doesn't make sense. A Mozilla toolkit-based application doesn't necessarily talk to an HTTP socket. It could also be a database administration tool. Or a chat client. Or a presentation tool. More, much more, than just a web application framework.
As a matter of fact, I don't have a love affair with XML syntax per se. As for arcane tags, I mostly use Simplified DocBook which has such arcane tags as , ,
, , and . It's different from HTML, yes, but no more arcane (and I think rather less) than ,
,
, , and
. If you want to talk about arcane, at least call a spade a spade.
You have a solution and you seem to like it. My problem with it is the mixture of content and layout. Bold, italics, strikeout, and underline have no intrinsic meaning: they are visual cues for underlying themes. When they are the only model, you by definition lose the semantic background to the document. "What's the problem," you ask? For static HTML and PDF presentation, there is no problem for human readers. But it removes the possibility of automated, intelligent indexing and categorization.
...another option that will get the job done easier and quicker: HTMLDOC.
I retort with Yoda. "Is the dark side stronger?" "No! Quicker. Easier. More seductive.":)
Yes, this isn't documented well enough. (I'm not being sarcastic -- it actually took a bit of hunting to find this)
From http://xslt-process.sourceforge.net/docbook.php
A better solution is to create a local copy of the DocBook DTD files. To do this go to http://www.oasis-open.org/docbook/xml/4.1.2/ and download the ZIP file containing the DocBook DTD. Put it in an accesible place on your file system, for example in/usr/local/share/docbook-4.1.2. Then modify the DOCTYPE of your DocBook documents to be:
<!DOCTYPE book
PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
"file:/usr/local/share/docbook-4.1.2/docbookx.dtd" >
I also know that there's a way to specify it as a general resource and to have a catalog that keeps from having to hardcode each file to a path, but I don't remember the syntax or the steps offhand.
XML processed with XSLT and serialized through FOP. Where is LaTeX used? XSLT doesn't have anything to do with LaTeX and FOP has nothing to do with LaTeX. Where do they rely on LaTeX?
Oh! You were talking about the LaTeX converters that Norman Walsh made available. Sorry. There's the confusion. If you use the FO stylesheets and FOP or iText for the PDF serialization, things are much much simpler. LaTeX shouldn't come into play unless you really want to use LaTeX.
And you are right that it is quite possible to make layout-free LaTeX. My statement was only that it does not enforce the separation of content and layout. This is the same as saying that there is nothing stopping a programming team from making clean, readable C with uniform indentation of code blocks, but Python doesn't allow the choice: clean, uniform indentation is an intrinsic piece.
It was not my intention to say that LaTeX made it impossible or even unduly difficult. Sorry for the confusion.
Why in the hell don't we have decent document writing tools when everyone is always screaming about the lack of documentation in the OpenSource world?
Because good editors are hard to write and a vast majority of the sufficiently talented coders who could do it still don't grasp the concept of content being separate from layout. You can't code what you don't understand.
That coupled with -- what other have touched on -- users who can't accept that what they edit is not necessarily what it will ultimately look like.
"I want to put this in italics." "Why?" "Because the image captions should all be in italics here." "So put the text in a <caption> tag." "But it's not in italics in my editor." "It will be in italics when it's published." "But it's not in italics in my editor." *sigh*
etc. This is because the editor is strictly following the DocBook schema. Chances are that the editor authors wanted their editor to be schema-agnostic. If your comment is saying that editors should be better, I wholeheartedly agree.
As for wanting to know what the underlying XML is, "why!?!" For something like Word, where only formatting information is saved, I could see your concern. This is like the HTML output of Frontpage and Dreamweaver. But DocBook is a semantic construct with no formatting information. What you see in a GUI should be far less variable in the output data below.
With DocBook, you already know what code snippets it is generating without even looking at your editor; it's rigidly defined in the DTD. Your XSLT should be written to the DTD, not to a document.
don't tell him to use the SGML version. New development around DocBook is definitely centered around the XML variant of DocBook. As for RTF, I recommend using stylesheets that convert to XSL:FO and serializing them to RTF with something like jfor.
In my opinion, XSLT should not be used to generate something like RTF directly. XSLT was made to transform one XML schema to another. Period. Anything else is like trying to put the square peg in the round hole.
But then I limited myself to Free Software, whereas someone willing to use non-Free software might easily find an off-the-shelf package to get around the PS/PDF hurdle.
Check out Apache Cocoon and Norman Walsh's DocBook stylesheets at Sourceforge. It sounds very much like what you are looking for both for batch processing of documents (using command-line mode) and for online dynamic presentation. There is even a serializer to PCL5 in case you ever wanted to send directly to HP-compatible printers.
You've obviously use LaTeX quite a bit already. That's hardly a fair comparison. You compare something with which you are already comfortable with something you haven't used at all before.
As far as markup goes, one of the reasons for using the open/close tag pair in XML was because so many people have written HTML and are used to that model.
As for complicated markup, there is a Simplified DocBook that reduces the amount of elements you have to know and keep track of while still remaining 100% DocBook compatible. Write a little now, and as your experience and comfort grows, so can your markup choice. Simplified DocBook now, full DocBook when the volume of documentation requires it later (By that time, more editors will have come out hopefully).
DocBook to PDF is handled by converting to XSL:FO (not to be confused with XSLT) syntax and serializing with something like FOP. LaTeX is actually closer to XSL:FO than to DocBook. If you're trying to convert to PDF by hand, you're expending more effort than you needed to. You can find premade stylesheets for HTML and FO and documentation about how to use them without reinventing the wheel. The advantage of going to XSL:FO instead of a direct DocBook-to-PDF is that there are serializers out there to output FO syntax to PDF, PostScript, PCL5, and RTF. It would be a shame to just make a one trick pony.
As for emacs, there are emacs extensions written for DocBook that help you with tag choices and automatically close the tags for you. Isn't that one of the main complaints you had about the syntax? And you're comfortable with emacs, right?
Note that you are using LaTeX to drive the layout. This is not how to use DocBook. In fact, DocBook goes out of its way to avoid any layout information in the file. Say you want to search for all documents with a section title that contains "apple". Anyone with a document parser can implement this no matter who wrote the DocBook file at any organization. LaTeX you could do this as long as everyone agreed upon the element identifiers -- which doesn't happen at every company. DocBook is content, HTML and PDF are layout, and never the twain shall meet...except during the transformation step.
If you prefer LaTeX, peace be with you. But they cannot really be compared as LaTeX -- while possible in implementation -- does not enforce a disctinction between semantic content and layout presentation. DocBook does. This adds some complexity for the initial startup sometimes, but it pays off when you actually have to organize and index those documents in an archive. You should talk to the folks at the Linux Documentation Project for more insight on this.
There is also a Simplified DocBook DTD. We used it at my last job. It is a small but useful subset of DocBook that can get you started.
All Simplified DocBook files are also completely valid DocBook documents. But there are far fewer elements and constructs to keep in your head. It's also geared toward smaller items such as articles instead of complete books. At my company, we made a couple of template documents and then just had people fill in the blanks. People ended up working faster once we got them to stop worrying about formatting and styling (non-trivial).
Start writing in SD and as the collection of documents grows, you can look into combining them into a cohesive DocBook collection as time permits and your experience level grows.
1) So have compiler updates, libc updates, kernel updates, etc. Yes, with the symlinks in place, it will be more cluttered. Let's look at the options: do nothing and have cryptic names, have it be cluttered now and after a couple of years of transition, remove the old names, or drop the old names and just use the new ones. You are for option one. I am for option two. Option three just seems far too painful.
2) Users on a server are not supposed to look in system folders. If it is on the desktop and there is only one or two people who use the machine, why in the hell shouldn't they be able to poke around? Breaking things is part of the learning process. Behind every good hardware guy, there is a very large smouldering pile of (now) useless junk. Behind every good software guy, there is a long history of core dumps, data loss, and off-by-one errors.
Encouraging someone to take a look is precisely how a large group of people get into an industry -- any industry whether it has to do with computers or not. And with the files in/etc, many of them are well commented and easily browsed. There is a wealth of knowledge already available. I'm only advocating a more obvious place to start looking.
A "average" user does not need to know the filesystem structure. All he needs to know is how to use the applications menu and the structure of his home folder. Making the rest of the filesystem folders "easier to understand" doesn't change a thing, the files within the folders are still just as mysterious.
Be careful. This sounds a little too close to Microsoft's reasoning as to why source code doesn't need to be made available. After all, most users -- even the programmers -- never really look at the kernel or library sources. And many of those programmers wouldn't understand what was going on anyway; it would be just as mysterious.
On the contrary, if ATMs were designed with accessibility guidelines in mind in the first place, it would have been very much easier to roll them out and replacement would not have been quite so much of a big deal. The point is that without the ADA, people with sight would simply ignore people with disabilities outright with no thoughts about accessibility. As more and more of these cases come through, use by the blind (and other disabilities) will go into the requirements for products and services instead of a courtroom.
Sight is not a prerequisite for normal function in society. It is only a prerequisite for normal function when society makes no effort. There are quite a few blind people in the world that live alone, go to work, go to the supermarket, take the bus, wash their clothes, cook dinner, pay their bills, talk on the phone, and other trappings of "normal function." Your statement has the distinct odor of eugenics on it. Let's try something else: if blind people cannot function normally, what about color-blind people? I know I use color differentiation on a regular basis. What about smell? What about a sense of touch on your hands and feet? Are deaf people screwed? What if you suffer from sciatica?
An ATM with a braille pad on it does not cost so much more than one without. It only costs so much more when you have to replace an ATM that didn't have one. On the same token, a web page can be made with established accessibility guidelines in mind and it costs about the same as one without. Replacing one that doesn't follow those guidelines is expensive. Companies operating in the United States are bound by the conditions of the ADA which has been in effect for some time now. It didn't sneak up on anyone. People who run the businesses (who most likely are not blind) simply didn't care. Now because of ADA lawsuits, they are beginning to care and many people will be the better for it.
If you take the minimal effort to set aside an extra bin for recycled goods, it takes minimal effort when throwing things away to keep them separate. If you throw it all into one bin, separating out the recyclables is a daunting and naseating task.
People with disabilities ought to realize that they can't participate fully in society, and accept that.
I'm happy to see that you feel that you would hold the same opinion of the situation if you were to become blind. That's all well and good, but it's irrelevant. The ADA is not about you and hypotheticals, it's about many peoples' fact -- people who are perfectly capable of living their own lives with minimal effort on the part of society at large. They are not willing to sit back and hope that society comes to their rescue. If these minimal efforts won't be made on their behalf, what hope is there with a full-blown repeal of the ADA where they can't work, can't travel, and can't live by themselves?
You are advocating a slippery slope. On the one hand, you have more web sites with up to date accessibility conformance. On the other, you have a large group of permanent dependents. Which do you think is greater drain on the time and resources of your society?
Some call it compassion. I call it "in your best interests" when you look at the bottom line.
No, it's not their choice. Without the ADA, disabled people most likely would not be able to fly on a plane at all as it would not be seen as economically viable to put in ramps and other such services at airports. There is nothing intrinsic to air travel that should preclude access to blind people; they're not flying the plane.
"The State" does indeed have the right to force compliance. "The State" felt that it was worth passing the Americans with Disabilities Act because of serious neglect for the basic living needs of people with disabilities. "The State" enacted it through the federal legislature of which one representative and two senators belong to you. Don't give that cookie-cutter, libertarian crap. If you don't like the law, work to get it repealed. If more people disagree with you than agree, that's democracy in action.
As for "the principle is that no-one has the right to force a person to trade with someone [with] whom that person doesn't want to trade," this is truly sad. This means that you would be okay with institutionalized racism ("I don't want to have to sell to them zipperheads!"), sexism ("I don't feel like selling to those stupid bitches!"), etc.
In addition, to quell your obviously libertarian tendencies, airlines function across state lines. This is federal jurisdiction subject to federal laws and regulations. States could not effectively manage something like the ADA and in my mind it is no different than the federal legislation that nullified the Jim Crow laws in the south.
Slashdot Mirror
Browsers with images turned off are far far cheaper than ramps and bathroom stalls.
Maybe not, but your support staff can most certainly use lynx to browse the site. Then they see exactly what the customer using the braille reader is seeing. You don't need to be blind to verify that a site is unusable in lynx. And don't most browsers allow for viewing without loading images?
Seems to be a lot less trouble and effort than installing ramps and stalls to me. Last I checked, browsers with images turned off are far far cheaper.
Yeah, they were bought (stock swap if memory serves) by Caldera. Caldera now owns the UNIX trademark. It is now Caldera stock that Microsoft owns. Microsoft still owns shares in the company that owns the UNIX trademark.
On the contrary, I did in fact know that Novell bought the UNIX trademark and original source from AT&T. And a lot of companies' roadmaps are different today from what was planned several years ago. If you really want to take a trip down memory lane, remember that Microsoft made a port of UNIX called XENIX. It was on XENIX that a lot of their internal development was done in the early days. The division that developed XENIX was sold to SCO, a company in which Microsoft still owns stock to this day. Novell later sold their UNIX holdings to SCO. So when you really think about it, Microsoft owns a fair share of the UNIX trademark. Kinda makes you proud doesn't it?
NetWare has been a file/print box, but services can and have been written for it. I know. I worked for a software company that has a NLM version of their flagship product. Truth be told, the NLM version came out before the NT port (mostly because NT hadn't been released yet when they started on the server product). It could have been better, but then so can writing Windows device drivers and nice UNIX GUIs. But people do it. People still use NetWare. People still pay to have NetWare services rendered. It's not going anywhere anytime soon. It is in fact too well supported in many organizations for it to simply disappear. Interest > 0.
As for Perl/Win32, much of the work was done by ActiveState, but a sizeable chunk was done by the community. These two Win32 ports were merged a while back, but to say that the community had nothing to do with it is an overstatement to say the least. Also, Microsoft didn't pitch in the funds until after ActiveState had done quite a bit of work already. Microsoft currently helps fund the port. They most certainly didn't pay for it to be made.
Information has to be held somewhere; why not a database? The common misconception is that Btrieve and MySQL (or other relational databases) are equivalents. They are not. Btrieve is closer in concept to BerkeleyDB and variants.
Apples and oranges. And the network data has to be stored somewhere.
Just to share blame, why not address the issue that a large portion of Perl modules that use native code aren't portable outside of UNIX (and even then...).
Ummm... Of course this is because NetWare itself doesn't have these functions. Current operating systems? UNIX is *how* old? NetWare by your metric IS the current operating system. As for network-wide security and administration, I'm sorry but Novell's offerings are superior and have been superior for years. NIS+? LDAP? Active Directory? Pshaw! NDS was already better than these years ago and eDirectory widens that margin.
Why does Novell need to update Perl? Because they bundle it? Why doesn't the Perl community maintain the port just like they do for every other operating system ? Or is Novell special on your shitlist? It's not like Novell controls the Perl source.
And if they're not 100% sure, why are they touting it? For the same reason that commercial companies release before it's time: mindshare.
Yes, we know that an open beta from Apache is as good or better than an initial release from a commercial developer. We know that the stable releases from Apache are akin to the third (or so) patch release for a commercial product.
What's the difference? Quality? Not necessarily. The difference is in semantics. Some open source entities produce bad code (have you looked around on Freshmeat lately?) and some commercial software houses produce good code.
How can we tell which is better? Cutting the crap and testing the products in question. If having the source available is important to you, obviously the open source software will win out every time. If only package functionality matters to you, waving a banner won't determine the best choice.
As far as "gold" code, you're wrong. "Gold" code simply means that it's going to be released. It designates that a particular snapshot of the codebase is being burned onto CDs and put into a shrinkwrapped package. "Gold" refers to a baseline, not the quality of the baseline. If you replaced "gold" with "good", I'd agree with you.
And by that time, PostgreSQL 7.3 will be out of beta. Maybe even Linux kernel version 3.0!
If all goes as planned, MySQL 5 will be stable by 2007.
*sigh*
What would this world be like if software reviewers reviewed actual, released software for a change instead of all of these developer wishlists that may (or most likely not) get released sometime in the future?
Makes sense. If PostgreSQL were standard, no one would bother with their SDK. On the other hand, this guarantees that folks will be developing for the lowest common denominator. Oh well...
Does the SDK cost anything? If not, I guess it works out. If it does, Novell just marginalized itself a bit more.
...and the fact that Chimera doesn't have all of the features of Mozilla has *nothing* to do with it.
By the way, where were you when the Moz developers were saying that 1.0 was supposed to be the stable API to work on? I applaud you for developing on Moz, but to state that you had no warning about an API changing from under you is foolish. I'm sorry for your pain, but you knew that you were holding a hot poker.
Because the book's not about web applications. Replace your statement with: "How is developing a web application which will run only on GTK+ different from doing an IE-only website?"
Exactly. Doesn't make sense. A Mozilla toolkit-based application doesn't necessarily talk to an HTTP socket. It could also be a database administration tool. Or a chat client. Or a presentation tool. More, much more, than just a web application framework.
,- ,
, , and
. If you want to talk about arcane, at least call a spade a spade.
:)
You have a solution and you seem to like it. My problem with it is the mixture of content and layout. Bold, italics, strikeout, and underline have no intrinsic meaning: they are visual cues for underlying themes. When they are the only model, you by definition lose the semantic background to the document. "What's the problem," you ask? For static HTML and PDF presentation, there is no problem for human readers. But it removes the possibility of automated, intelligent indexing and categorization.
I retort with Yoda. "Is the dark side stronger?" "No! Quicker. Easier. More seductive."
From http://xslt-process.sourceforge.net/docbook.php
I also know that there's a way to specify it as a general resource and to have a catalog that keeps from having to hardcode each file to a path, but I don't remember the syntax or the steps offhand.
Hope this helps with your laptop problem.
DocBook -> XSL:FO -> PDF
XML processed with XSLT and serialized through FOP. Where is LaTeX used? XSLT doesn't have anything to do with LaTeX and FOP has nothing to do with LaTeX. Where do they rely on LaTeX?
Oh! You were talking about the LaTeX converters that Norman Walsh made available. Sorry. There's the confusion. If you use the FO stylesheets and FOP or iText for the PDF serialization, things are much much simpler. LaTeX shouldn't come into play unless you really want to use LaTeX.
And you are right that it is quite possible to make layout-free LaTeX. My statement was only that it does not enforce the separation of content and layout. This is the same as saying that there is nothing stopping a programming team from making clean, readable C with uniform indentation of code blocks, but Python doesn't allow the choice: clean, uniform indentation is an intrinsic piece.
It was not my intention to say that LaTeX made it impossible or even unduly difficult. Sorry for the confusion.
Because good editors are hard to write and a vast majority of the sufficiently talented coders who could do it still don't grasp the concept of content being separate from layout. You can't code what you don't understand.
That coupled with -- what other have touched on -- users who can't accept that what they edit is not necessarily what it will ultimately look like.
"I want to put this in italics."
"Why?"
"Because the image captions should all be in italics here."
"So put the text in a <caption> tag."
"But it's not in italics in my editor."
"It will be in italics when it's published."
"But it's not in italics in my editor."
*sigh*
You're right, we need better editors.
As for wanting to know what the underlying XML is, "why!?!" For something like Word, where only formatting information is saved, I could see your concern. This is like the HTML output of Frontpage and Dreamweaver. But DocBook is a semantic construct with no formatting information. What you see in a GUI should be far less variable in the output data below.
With DocBook, you already know what code snippets it is generating without even looking at your editor; it's rigidly defined in the DTD. Your XSLT should be written to the DTD, not to a document.
don't tell him to use the SGML version. New development around DocBook is definitely centered around the XML variant of DocBook. As for RTF, I recommend using stylesheets that convert to XSL:FO and serializing them to RTF with something like jfor.
In my opinion, XSLT should not be used to generate something like RTF directly. XSLT was made to transform one XML schema to another. Period. Anything else is like trying to put the square peg in the round hole.
Check out Apache Cocoon and Norman Walsh's DocBook stylesheets at Sourceforge. It sounds very much like what you are looking for both for batch processing of documents (using command-line mode) and for online dynamic presentation. There is even a serializer to PCL5 in case you ever wanted to send directly to HP-compatible printers.
You've obviously use LaTeX quite a bit already. That's hardly a fair comparison. You compare something with which you are already comfortable with something you haven't used at all before.
As far as markup goes, one of the reasons for using the open/close tag pair in XML was because so many people have written HTML and are used to that model.
As for complicated markup, there is a Simplified DocBook that reduces the amount of elements you have to know and keep track of while still remaining 100% DocBook compatible. Write a little now, and as your experience and comfort grows, so can your markup choice. Simplified DocBook now, full DocBook when the volume of documentation requires it later (By that time, more editors will have come out hopefully).
DocBook to PDF is handled by converting to XSL:FO (not to be confused with XSLT) syntax and serializing with something like FOP. LaTeX is actually closer to XSL:FO than to DocBook. If you're trying to convert to PDF by hand, you're expending more effort than you needed to. You can find premade stylesheets for HTML and FO and documentation about how to use them without reinventing the wheel. The advantage of going to XSL:FO instead of a direct DocBook-to-PDF is that there are serializers out there to output FO syntax to PDF, PostScript, PCL5, and RTF. It would be a shame to just make a one trick pony.
As for emacs, there are emacs extensions written for DocBook that help you with tag choices and automatically close the tags for you. Isn't that one of the main complaints you had about the syntax? And you're comfortable with emacs, right?
Note that you are using LaTeX to drive the layout. This is not how to use DocBook. In fact, DocBook goes out of its way to avoid any layout information in the file. Say you want to search for all documents with a section title that contains "apple". Anyone with a document parser can implement this no matter who wrote the DocBook file at any organization. LaTeX you could do this as long as everyone agreed upon the element identifiers -- which doesn't happen at every company. DocBook is content, HTML and PDF are layout, and never the twain shall meet...except during the transformation step.
If you prefer LaTeX, peace be with you. But they cannot really be compared as LaTeX -- while possible in implementation -- does not enforce a disctinction between semantic content and layout presentation. DocBook does. This adds some complexity for the initial startup sometimes, but it pays off when you actually have to organize and index those documents in an archive. You should talk to the folks at the Linux Documentation Project for more insight on this.
There is also a Simplified DocBook DTD. We used it at my last job. It is a small but useful subset of DocBook that can get you started.
All Simplified DocBook files are also completely valid DocBook documents. But there are far fewer elements and constructs to keep in your head. It's also geared toward smaller items such as articles instead of complete books. At my company, we made a couple of template documents and then just had people fill in the blanks. People ended up working faster once we got them to stop worrying about formatting and styling (non-trivial).
Start writing in SD and as the collection of documents grows, you can look into combining them into a cohesive DocBook collection as time permits and your experience level grows.
cd /se<tab>
get over it
2) Users on a server are not supposed to look in system folders. If it is on the desktop and there is only one or two people who use the machine, why in the hell shouldn't they be able to poke around? Breaking things is part of the learning process. Behind every good hardware guy, there is a very large smouldering pile of (now) useless junk. Behind every good software guy, there is a long history of core dumps, data loss, and off-by-one errors.
Encouraging someone to take a look is precisely how a large group of people get into an industry -- any industry whether it has to do with computers or not. And with the files in
Be careful. This sounds a little too close to Microsoft's reasoning as to why source code doesn't need to be made available. After all, most users -- even the programmers -- never really look at the kernel or library sources. And many of those programmers wouldn't understand what was going on anyway; it would be just as mysterious.
Sight is not a prerequisite for normal function in society. It is only a prerequisite for normal function when society makes no effort. There are quite a few blind people in the world that live alone, go to work, go to the supermarket, take the bus, wash their clothes, cook dinner, pay their bills, talk on the phone, and other trappings of "normal function." Your statement has the distinct odor of eugenics on it. Let's try something else: if blind people cannot function normally, what about color-blind people? I know I use color differentiation on a regular basis. What about smell? What about a sense of touch on your hands and feet? Are deaf people screwed? What if you suffer from sciatica?
An ATM with a braille pad on it does not cost so much more than one without. It only costs so much more when you have to replace an ATM that didn't have one. On the same token, a web page can be made with established accessibility guidelines in mind and it costs about the same as one without. Replacing one that doesn't follow those guidelines is expensive. Companies operating in the United States are bound by the conditions of the ADA which has been in effect for some time now. It didn't sneak up on anyone. People who run the businesses (who most likely are not blind) simply didn't care. Now because of ADA lawsuits, they are beginning to care and many people will be the better for it.
If you take the minimal effort to set aside an extra bin for recycled goods, it takes minimal effort when throwing things away to keep them separate. If you throw it all into one bin, separating out the recyclables is a daunting and naseating task.
I'm happy to see that you feel that you would hold the same opinion of the situation if you were to become blind. That's all well and good, but it's irrelevant. The ADA is not about you and hypotheticals, it's about many peoples' fact -- people who are perfectly capable of living their own lives with minimal effort on the part of society at large. They are not willing to sit back and hope that society comes to their rescue. If these minimal efforts won't be made on their behalf, what hope is there with a full-blown repeal of the ADA where they can't work, can't travel, and can't live by themselves?
You are advocating a slippery slope. On the one hand, you have more web sites with up to date accessibility conformance. On the other, you have a large group of permanent dependents. Which do you think is greater drain on the time and resources of your society?
Some call it compassion. I call it "in your best interests" when you look at the bottom line.
You don't, but the folks for whom you voted (assuming you vote) certainly do. That's what laws do. They're the ones who make the laws.
No, it's not their choice. Without the ADA, disabled people most likely would not be able to fly on a plane at all as it would not be seen as economically viable to put in ramps and other such services at airports. There is nothing intrinsic to air travel that should preclude access to blind people; they're not flying the plane.
"The State" does indeed have the right to force compliance. "The State" felt that it was worth passing the Americans with Disabilities Act because of serious neglect for the basic living needs of people with disabilities. "The State" enacted it through the federal legislature of which one representative and two senators belong to you. Don't give that cookie-cutter, libertarian crap. If you don't like the law, work to get it repealed. If more people disagree with you than agree, that's democracy in action.
As for "the principle is that no-one has the right to force a person to trade with someone [with] whom that person doesn't want to trade," this is truly sad. This means that you would be okay with institutionalized racism ("I don't want to have to sell to them zipperheads!"), sexism ("I don't feel like selling to those stupid bitches!"), etc.
In addition, to quell your obviously libertarian tendencies, airlines function across state lines. This is federal jurisdiction subject to federal laws and regulations. States could not effectively manage something like the ADA and in my mind it is no different than the federal legislation that nullified the Jim Crow laws in the south.
There is such a thing as tyranny of the majority.