Following on the theme of the Long and Short Term Techniques mantra, an oft-touted advantage of Linux is freedom from vendor lock-in. But is this really true? ...
Following on the theme of the Long and Short Term Techniques mantra, an oft-touted advantage of Linux is freedom from vendor lock-in. But is this really true? ...
I was reading the latest DH Brown Associates report on migrating to Linux servers, an excellent paper that deserves space in every advocate's arsenal, when I encountered this statement among the selling points of Linux:
...choice of technical support and service provider, avoiding vendor lock-in, ...
Flashback to yesterday, while doing some evals of small and portable mini-squidlike web proxies to use with my Intranet Amplification project, I was knee-deep in performance problems with otherwise promising SmartCache when I discovered their online docs were deleted save one page; no problem, I thought, the source archive includes the SGML sources!
Except for one small detail:
<!doctype debiandoc public "-//DebianDoc//DTD DebianDoc//EN">
DebianDoc? DebianDoc?! I thought the Debian people were smarter than that! What is this other than vendor lock-in, even if it is accidental? I don't mean to blame anyone here, with free software you take what you get or do it yourself, but I just wanted to put out an alert: LSB is not the only way to ensure we retain the Freedom of Choice in what we do.
Given that you can download the Debian DTD regardless of what system you're using.
If you're going to choose an example, a better one would be training all your sysadmins to use the non-free YaST2 or something.
Besides, DebianDoc is almost certainly a transparent format, which means you can force your way through and view it as a plain text file, if you so wish. So where's the problem?
I probably wasn't totally clear and yes, those examples were just what prompted my posting, not held out as paragons of illustration. My only real point here is that, instead of developing parallel methods (like DebianDoc when LinuxDoc or even DocBook-lite are perfectly sufficient) we should make a conscious effort to work together more, to make the LSB guidelines happen. You can download the DTD, but if you run sgml2html, it fails (that util only works on the obsolete LinuxDoc) so the person is faced with a hunt, and it's needless; the problem is avoided by checking for standards first.
Sometimes it backfires: Yesterday I discovered by accident that the strange date format used by the SportsNetwork newswire is in fact RFC822's date format, whereas Java is not prepared (by default) for this format. You not only should pick a standard, but pick a winning standard ;)
DebianDoc is pretty old, actually.
If I remember correctly, DebianDoc was created by Ian Jackson at a time when Debian needed a reasonably good markup language, with working tools to convert it to on-line and hardcopy formats. The need was pressing, there was not time to wait for others to develop formats and tools. It was much quicker to do it yourself.
Of the available options you mentioned, LinuxDoc was pretty messy (might have improved since) and DocBook was unknown and badly supported by tools (still is, alas). Texinfo didn't have a reasonable converter for HTML, I think.
(I've been part of both LDP, who developed LinuxDoc, and Debian, and now use DocBook much of my markup, having converted my book to use it. I'd guess I'm pretty impartial on the issue.)
That, however, only challenges your example. I'm not particularly happy with your point, either. I don't think writing your own tools to do things is vendor lock-in, as long as your tools are freely available. (Nor do I think it is bad to do things yourself, even if there are existing options, assuming you can do a better job.)
I freely admit that sticking to standard tools often makes things simpler. Using some non-standard tools doesn't raise the barrier for switching to something else high enough, I claim, that it warrants being called lock-in.
there is indeed some lock-in in open source, namely when it takes a non-
trivial effort to get data out of one system and import it into
another. for all practical purposes this is a form of lock-in, whether
intended or not. witness the paucity of interop between open source
projects due to "choice" for the end user. "everything MUST be
configurable". yeah right.
i would love to see more standardized configuration formats and more interop in open source land.
DebianDoc? DebianDoc?! I thought the Debian people were smarter than that! What is this other than vendor lock-in, even if it is accidental?
Linux can have custom file formats without creating vendor-lock in.
Vendor lock-in means by using the system your data is stored or dependant upon a proprietary format, preventing you from getting it out.
In the case of the SGML source file, well, you didn't write that, so it isn't your data (just like it wouldn't be vendor lock-in if they chose to write their man pages using pure nroff or postscript instead of using SGML) -- they conciously chose to put it in that format, there are publicly available tools you can use to get their data out of that format (though that isn't important).
Vendor lockin isn't when the documentation to software is in a format that's coupled with it's distribution, it's when a vendor erects a strong barrier against you switching to a competing product without starting all over.
New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!