Mr. Connell makes a number of questionable assumptions:
1. "People set up computers alone."
Actually, they seldom set up computers at all. They use preloads. If customers actually had to install Win98, let alone WinNT, on a blank hard drive, we would cease to hear these foolish, context-less complaints about Linux being "difficult to install".
2. Further, he assumes that consumers won't accept any other sort of setup regime. Never mind the fact that they already do (i.e., preloads): Why should we believe that OS setup/configuration cannot be a salable service, just because Connell can't imagine it?
3. "To address this reality, new computers with pre-installed Linux should work fully and completely the first time they are turned on."
The above appears to assume that such is not the case, which is a fearsome insult to the painstaking work of ASL, Tuxtops, Cosmos Engineering, Cobalt, PromoX, Rebel.com Inc., etc.
However, he goes on to (one assumes) clarify what he meant:
"When the user plugs in a standard option that they already own -- printer, network, external storage device, etc. -- those options should be recognized and configured automatically." By way of comparison, he cites MacOS running on Apple hardware.
But that begs the question: Isn't the ease of installing peripherals on MacOS made possible by the carefully controlled standards of Apple-compatible hardware?
If you'll pardon the expression, "Apples, meet oranges."
4. "Unfortunately, most people don't know a computer expert of any kind, much less a Linux expert. It is important for the Linux community to keep in mind that most users will be completely on their own when setting up or installing Linux systems and software."
Again, this assumes that the only way the world can run is the way Connell is familiar with.
5. "Learning new applications is hard.... Several Linux fans wrote to me stating that the 'application problem' is actually a 'user problem'. Users are incorrectly resistant to change, the argument goes, when they should be accepting something that is new and better. This is backward thinking."
More to the point, the entire dichotomy Connell poses, here, is a red herring: The general (proprietary-OS) computer population already learns new applications on a recurring basis -- every time their vendors' upgrade treadmills crank up another notch, and also often when a change of management (or of employer) means learning the new local "standard": If the management team du jour says you're going to use Groupwise instead of Exchange, you'll learn it. If the local standard is Microstation instead of AutoCAD, you'll learn that, too. And when the next revision of your cherished office bundle shuffles half of the functions around, you'll learn that, too.
The point is that, if you're already contemplating a forced upgrade to your proprietary-OS package (or between two such packages), maybe the real question isn't whether learning new applications is hard, but rather whether learning new applications on Linux is significantly harder than what you're already considering.
6. "It is not the job of the masses to adapt to your computer system. The history of business is carpeted with extinct companies that did not understand this."
This seems to assume that Linux is a business. Of course, there are businesses based on Linux, but Linux itself will not live or die according to market acceptance the way, say, OS/2 did. If every significant Linux-based firm were to close its doors tomorrow, the open-source developer community, the user base, the Internet-based community mechanisms that create and nourish them both, and all the $1.99 CD-ROMs would go on with barely a jitter.
Connell's spectre of "extinct companies" is a mirage.
7. "Consider focusing your immediate application efforts on the few key pieces of software that receive 90% of home and office use.... You might create a native Linux look-a-like for MS Word."
Connell's assumption, here, is that this is or should be a task for the Linux community at large (or at least for Linux developers collectively). Which begs the question: Why? Those who want such software will create it or pay for its creation, if they want it so badly.
It's surprising that Connell should raise this argument, since obviously he's been around Linux for quite some time. The community's tradition is well known, and eminently pragmatic: If you want a piece of software created, you're free to take out your copy of gcc and hammer it out -- or give someone else a personally compelling incentive to create it.
8. "The Linux community has been on a honeymoon as it has created the Linux software.... As Linux is embraced by more organizations, and used in more ways that are crucial, the demands upon you will increase."
The Linux community has ignored clueless demands before, and it no doubt will again. "Pressure" and "demands" from third-party companies are a no-op, per se. Of course, they can "pressure" and "demand" coders they pay adequate salaries to (if they can retain such), but that is a different subject.
The assumption, in any event, is that such "demands" are a problem. That is a claim without substance.
"Wealthy organizations, accustomed to getting their way, will demand impossible schedules from you, and then complain if the quality is not perfect."
Ditto.
9. "Some readers have suggested to me that the open source method of software development causes project management issues to evaporate; that the projects manage themselves. This is a fantasy."
It is also yet another red herring. Those who need and want legal accountability and fiduciary responsibility will hire (and otherwise pay) people who wish to agree to such relationships. But that occurs distinctly from the regular community-based open-source model.
10. "You will be managing a large public programming project with conflicting demands, tight schedules, and the need for high quality."
Connell fails to state what hypothetical assumptions would lead to this situation, but one gathers that he means something like what AOL/Netscape's project managers for Netscape 5.0. Indeed, Netscape might have a project-management problem -- but, if it decides it doesn't like limited social contracts, it can at any time have exactly as many programmers on staff as it's willing to pay for (thereby buying into an entirely different collection of problems).
Connell also begs the question of what constitutes "good project management". If community-based open-source projects can't always be counted on to meet milestones and deadlines, it's equally true that they're largely immune to shipping in bug-infested condition just because some butthead executive needs to doctor the end-of-quarter books.
11. "Humility is a virtue. If Linux succeeds in a significant portion of the computer world, and it looks like it might, your time in the limelight is short." Connell then tells the cautionary tale of his former career at Digital.
However, again, Linux is not hostage to corporate fortunes. Linux cannot "go out of business", or "take a nosedive".
Connell's suggestion that Digital's fate can befall Linux is thus illogical.
12. "The same thing will happen to you. The Linux killer is just around the corner. You don't know what it is, and you won't recognize it when you first see it."
The assumption here is that this would necessarily be a bad thing, and that we have some reason to cling to Linux in the face of this "killer". Suppose the "killer" is something better than Linux. Why would we not welcome it?
"The next generation of techies will understand it and will consider you old fogies for having your heads buried in the Linux sand."
Begs the question: Aren't we on Linux because we're early-adopter types who chose it for various technical advantages? If so, wouldn't we be the ones adopting and understanding this new thing, and looking back over our shoulders at the reactionaries?
And, lest we forget: Connell seems to assume throughout his essay (but here, particularly) that one uses just one operating system at a time. Yet, it should be obvious that diversity serves a purpose, and that no one OS fulfills all roles well.
Connell is obviously a talented writer. It would be good to see him cease arguing bogus positions resting on doubtful premises.
You're referring to Microsoft's NetShow Revision 2.00, Build 251 beta (aka Media Player), the very first Microsoft application for Linux, released in Oct. 1998. This is a stripped, statically linked x86 ELF binary. 2MB. http://linuxmafia.com/pub/linux/ apps/netshow_linux
The above is now the main distribution point for that software, since Microsoft removed it and all mention of it from its Web pages. It's not half bad, though I'm keeping it available mostly for historical reasons.
Indeed an amusing article (the ZDNet one). However, a couple of weeks ago, I happen to have written a piece that I think does comprehensively cover the question: http://linuxmafia.com/~rick/faq/#virus
I wrote that after I was ask about Linux virus-checkers once too often.
In my articles about this company for The Register and LinuxWorld Online, I raised questions about LinuxOne's fulfillment of its GPL obligation to provide access to source code. I'm happy to report that the company appears to have substantively corrected its omission, in this area: The on-line order form now includes a checkbox to request source code, at no extra charge.
That is a welcome development, and I applaud it.
Credit where due, folks: It's only fair.
As to the rest: As I mentioned in my (and Eileen Cohen's) LinuxWorld article, if LinuxOne can carry through on its ambitions to produce and distribute Chinese- and Japanese-language versions, I'll be the first to cheer them on.
And I won't be investing in this firm, for reasons amply described, but I nonetheless wish them luck.
Well, I was going to retrieve copies of these binary-RPM "driver" files, and see if these were from Dell or are copies of open-source software from elsewhere. (Why? Because if they're distributing binaries of other people's GPL-covered drivers, and not offering source, then they're violating the licence.)
But the site is suffering from Microsoft-induced damage:
error 'ASP 0115'
Unexpected error
/us/en/filelib/system.asp
A trappable error occurred in an external object. The script cannot continue running.
Afterthought: If the reason we're supposed to admire Dell is that they offer rather generic and poorly customised preloads of one (only) Linux distribution, then why are we supposed to be excited at binary-RPM drivers on a Web site? Does the preload come without drivers, or what?
I'll assume good intentions, here, but Dell definitely doesn't quite get it.
Where's the source code?
If Dell wants to be taken seriously on Linux, providing binary-only RPMs of x86 drivers is not the way to do it. Binary-only drivers are a security hazard, they don't benefit from peer review, they're not portable to other CPU architectures that use the chipsets they serve, and they're prone to breakage as the kernel develops. Giving us those, only, isn't even half a loaf. More like 1/10 of one.
If Dell Computer wants to get serious about this, it can start by providing chipset information on its so-called "system specifications" Web pages. Consider, for exmaple, the Inspiron 3500 system specifications page: What's the PCMCIA chipset? What's the sound chipset? What are the chipsets for the optional modem and ethernet cards? Is the CD-ROM a standard ATAPI one, or on a custom interface? Is the floppy drive on a standard floppy port, or is it USB?
And, then, once they really get serious, they can apply their influence to get full programming interface information and sample driver code for those chipsets released to the Linux developer community.
That would be genuine Linux support.
Meanwhile, it would probably be better for Linux users to patronise companies that at least seem to understand the issues, and are trying. Such as IBM with some of its ThinkPad models, for example.
Credit goes to Bay Area Linux activist Deirdre Saoirse for noticing that the plaintiff was getting away uncontested with claiming that DeCSS was a tool for copying DVDs (which it isn't) as opposed to playing them.
Deirdre got the attention of defence attorney Robin Gross, during a court recess, and made sure they understood the very vital point that DeCSS has nothing to do with DVD copying, which was possible (but uneconomical) before DeCSS was written using other tools entirely. The defence team then explained this to the judge, who was visibly surprised by the news.
The plaintiffs may well have lost the day, right there.
Brooks's Law is no longer applicable in the Internet environment.
That is not Raymond's allegation: He claims that debugging is parallelisable in open source. Brooks's famous observation was, of course, that development cannot be parallelised. Raymond nowhere challenged this latter assertion.
ugh.. that would kill off the possible explanation that the lawsuit did anything to 386BSD.
No, it wouldn't. 386BSD's code was potentially encumbered in exactly the same way that Berkeley's reference code was: If memory serves, the first release of 386BSD was essentially NET/2 code. That automatically implicated it in the lawsuit along with BSD OS.
But you're right that we're getting very far afield, at this point.
What point was the author trying to make by saying (remember him?) everytime RMS was mentioned?
It's a running gag I had with the Linuxcare sales staff. You're missing the context for this, but that's because nobody really explained where my essay originated:
While I was a manager at Linuxcare, we set up a mailing list called "Brown Bag" to try to answer technical, licencing, and similar questions from the sales force. I ended up sending to that mailing list a long series of essays like the current one, about different aspects of free software (e.g., what's the deal about the GPL being "infectious").
The sales force got to know RMS from hearing him speak to them at length, a month or two ago. Ever since then, when I've spoken to a salesman to answer a question and RMS's name comes up, I often said "Richard M. Stallman (remember him?)".
I left Linuxcare this past Friday, but sent in the "forking" essay for the Brown Bag list, to complete the series, and as a parting gift to the sales staff, who are all good people whom I enjoyed working with, greatly.
That statement I bolded is entirely incorrect. We know from the time-table that FreeBSD and NetBSD were derived from 386BSD, which came before the lawsuit.
I'm sorry, but your conclusion does not follow from your premise.
I nowhere stated that the lawsuit had an immediate cause-and-effect relationship to the fate of Jolix. I would not have done so, since, as a one-time 386BSD user myself, I know that the situation was quite a bit more complex.
We also know from Theo's archive that OpenBSD splitting from NetBSD had nothing to do with the lawsuit.
I'm sorry, but it's arguable that this latter split would not have happened had Bill Jolitz and his wife not, earlier, dropped out of sight, which in turn was a proximate effect of the lawsuit.
But, in any event, I didn't get into that at all. All I said was that the splits happened "under the stress of the lawsuit."
Now, I don't object to you reading into that a great deal more than I wrote. However, don't complain to me about what you then come up with.Where the camps had trouble, which I'll point you straight to SVLUG's history page, is that the lawsuit created tension.
Bingo. And that is what I said.
Also, the old tale is that AT&T sued because BSDI used 1-800-ITS-UNIX, and UCB was sued as a result.
That is yet another part of the story. The story I deliberately did not tell, because that would have been a different essay entirely.
I'm not sure if that's true, since its all 3rd or 4th hand knowledge (not even close to 2nd hand:-).
Shame on you for missing Kirk McKusick's talk. That was, of course, first-hand.
Sorry, I misread that sentence; you don't explicitly say Stallman personally wrote glibc.
That's OK. I could certainly have been clearer.
However, you say "Stallman's library" (or similar words) many times.
I will admit that saying "Stallman" when one means "the FSF" is a very bad habit, and I will try to cure myself of it.
No, I feel that if you are going to write a historical essay you should try a bit harder to avoid false statements or phrasing that is likely to be misunderstood. And if mistakes or misleading phrasing is pointed out, you should try to correct them.
If you mean "correct them" on the Linuxcare Web site, you're talking to the wrong party: I have no connection to Linuxcare, Inc. since I quit that company last Friday. However, I submitted the piece (for a company-internal mailing list, I should note) under the GNU GPL, so you are eminently free to rewrite it any way you like.
Oh, don't worry. I won't take it personally. People seem to get very worked up over these matters. Why, I don't know.
There is no murkiness at all; tons of people have been involved and know all about it.
Unfortunately, they do not appear to agree, as can be seen by examining the comments here, if not elsewhere. A situation that isn't aided by people going out of their way to misread what I wrote, and read into it meanings I never stated.
Example: the origin of pgcc. Stallman didn't "ignore repeated requests" for Pentium-specific optimization, the necessary information was trade secret at the time.
Oh, at one time, they were indeed. And then, later, they were available, but not accepted into gcc. Which is what I said.
Cygnus never had anything to do with pgcc.
What I remember saying is that individual Cygnus staffers were involved with PCG. Is this not correct? I'm pretty sure I verified that, back when I was running a Stampede Linux beta.
Your history of Lucid Emacs/XEmacs is, as Per has pointed out, completely wrong.
Indeed. I had it confused, at the time I wrote that, with Gosling emacs.
Your exactly right. The time table of BSD shows Rick is incorrect.
That might be a valid criticism if my article had included any sort of chronology. But it did not: I omitted any mention of when BSD OS, SunOS, and Jolix forked off from BSD 4.x because it simply was not germane to the point of the article.
I in fact ran 386BSD 0.1 -- downloaded by modem and and written out to floppies. But that would be a completely different article.
I don't think the facts are quite straight regarding FSF Emacs vs XEmacs.
No, they absolutely aren't. I really was meaning to write about Gosling emacs there, but somehow got sidetracked onto xemacs. Apologies to users of emacsen everywhere, and especially to Jamie.
At the time I wrote that, I was a bit distracted, as I was typing it into a laptop next to my girlfriend's hospital bed, last Saturday. But I should have caught that gaffe before sending it to Linuxcare. (The original version was my parting-gift essay for Linuxcare's sales staff: I had resigned from that firm the previous day.)
Questions of history aside, the main thing preventing a merge right now is that the XEmacs folks don't have legal papers for all their contributions.
Yes, collecting the copyrights would be an additional obstacle. However, the ones listed were those I recalled from Ben Wing's talk at SVLUG on July 1, 1998.
The statements about the current maintainability of XEmacs vs FSF Emacs are also suspect.
They are some combination of Ben Wing's SVLUG presentation and my own surmises. But, of course, differences of opinions are what give us horse races.
Also, with regards to GCC->EGCS->GCC, I don't believe Stallman ever did anything to delay the arrival of Pentium optimizations.
I did not mean to imply personal intransigence on Richard's part, just that FSF was dragging its feet.
Solaris is the result of Sun paying a one time licence to AT&T and then making changes/bringing in BSD compatibility.
(hence all the hate and discontent of some Sun users when Sun OS 4.x was dumped for Solaris)
You're of course quite right, except that this obligatory ritual conversation goes on to say that Solaris still is based on SunOS in some odd Sun Marketing sort of way, with cut-and-paste excerpts from login screens to prove it.
All of which was so far from the article's topic that I decided it's better not to go into it.
The mention of non-free BSD-based commercial Unixes implies that these implementation came after the release of the free BSDs and the AT&T lawsuit; they long pre-date both.
It does? I certainly didn't mean to imply that. Clearly, Sun Microsystems is contemplating such a move, but has not released the source code except possibly under NDA to some of its close business partners.
If I did imply that, than I must have been rather sloppy. Understand, please, that the whole thing got written on a laptop machine last Saturday, to occupy my mind as I waited in a hospital waiting room for my girlfriend to get medical attention. And I was seriously ill with a case of the 'flu. I'm surprised it came out as well as it did.
Don't be surprised if people think the phone contact qualifies as "out of band" - it *does*, end of story.
That misses the point entirely. I said quite specifically that "the two main principles you try to follow with businesses' InterNIC records are (1) ensuring out-of-band communication and (2) avoiding single points of failure." That is what I said, and meant, was "doing it right".
The point is that having one of the two ways of reaching you when you have nameservice problems automatically breaks when the problem condition occurs (because you've made that method dependent on the DNS zone in question), then the other method is a single point of failure.
Of course there are myriad way to "do it right". In my view, all are mindful of those two principles, both of them. My point -- and an awfully minor passing point it was -- was that LinuxOne has problems in both areas. Which I call the mark of a network amateur.
Actually, more just tired of the time consumed by all this. And the juvenile and gratuitous name-calling.
It struck me as "over-analysis" because what really happened was that several people badly misunderstood my point about DNS redundancy, because they themselves don't know how to do it the right way -- so they went off on extended fantasies about how I'd supposedly said they needed some ludicrous multi-office setup with diesel generators.
I guess I should glad that only three of my sentences were that horrendously misunderstood, else I'd be posting technical explanations in response to flamebait from anonymous trolls until doomsday.
Which reminds me: It's a nice Sunday, and I have better things to do.
But why? Why is the telephone number not adequate? Making a habit of doing this would require that an admin either use an off-site mail server for all of his email, or frequently check a secondary off-site mail server for mail about a DNS problem that will probably never arrive.
My goodness, people seem to be making a very large matter out of one small and passing point, out of many.
An in-band e-mail address as a NIC contact is valuable when the domain in question is reachable, and useless when it's not. Right? I certainly hope you'll buy that assumption, or we're not going to get anywhere. So: You're assuming it's OK for that means of contact to cease working whenever the domain has problems.
I don't share that assumption, because I figure the main reason for the contact information is to be able to get through in case of trouble, and that there are two mechanisms for reasons of redundancy. If one of them inherently goes belly-up whenever the domain has trouble (when contact in my view is most important), then there goes your redundancy.
That's why I said that at least one address ought to be out of band, for commercial sites. And, for heaven's sake, "use an off-site mail server for all his mail..., frequently check an off-site mail server..."? Hey, that sort of scutwork is what computers are for! Have an address that ordinarily goes through a.forward to somewhere, up to and including one's pager or cellular 'phone. Or just use your home address, if you're ssh'ed into there anyway. Or any of myriad other solutions. If you're a sysadmin, you've probably already figured out your own out-of-band solution.
But, really, some of you guys have gone so far out of your way to misread that one small paragraph that I pretty much had to wonder whether we were reading the same article. Like the fellows who claimed I was saying LinuxOne needed redundant multiple power circuits, redundant DNS through tier providers, and multiple offices on different continents.
Beg pardon? What say? All I did was observe that they didn't do the obvious and usual thing of having somebody else do DNS secondary (and preferably also backup MX) at some remote site. Instead, LinuxOne had all its eggs in one basket, in its Mountain View site (and thus, incidentally, on the same power circuits).
Usually, you make an arrangement with the admin of some company in another town: You'll do his secondary, and he'll do yours. A couple of lines of named.conf and sendmail configuration on each end, and you're done. No diesel generators, no "redundant power architecture", no "friggin' UPS for each circuit". If you have those, that's spiffy, I suppose, but unrelated and pretty much irrelevant to the discussion.
So look, guys: If you don't think the principles of out-of-band communication and elimination of single points of failure matter as much as I do, more power to you (but not enough to blow your surge protectors). I wish your networks the best of luck.
And I sure hope that's enough over-analysis on three of the least significant sentences in a 3,500 word article.
Actually, I wouldn't, as that is the first I have ever heard of such an option. Could you enlighten us further?
OK. Some of this may be slightly wrong because of being off the cuff and from memory, so please forgive some amount of inaccuracy.
Forged InterNIC requests are a real problem, so a year or two ago the NIC came up with an improvement. As you probably know, modify-domain and modify-host requests are honoured if they appear to come from the technical or administrative contact -- or the registrant (domain owner) has final say if need be, but not through as automatic a process.
The improvement gave you the option to set an authentication scheme for each contact record. By default, that setting still defaults to no security. (This is called the "MAIL-FROM" authentication option.) For example, I'm NIC handle RM100. Initally, the NIC would simply believe any change request that appeared to come from my address of record, rick@hugin.imat.com. Alternately, you can establish a password (which you send to them as a crypt hash) aka "CRYPT-PW authentication" or a PGP key ("PGP" authentication.
Separate from the authentication mechanism is the verification setting. This involves two settings: NOTIFY-UPDATE is whether the contact should be notified before or after a record it's associated with has been changed. Allowed values are BEFORE-UPDATE, AFTER-UPDATE, and NOT-CARE. "After" is the default. The NOTIFY-USE setting is whether tbe contact should be notified before or after the contact record has been used in (added to) a domain or host record. Valid values are BEFORE-USE, AFTER-USE, and NOT-CARE. "After" is again the default.
Anyhow, be setting the authentication and notify settings to match your degree of paranoia, you can pretty much control access to domain (and host) records registered under those contact names.
For that matter, if we didn't have those options, having a mail server be "under your administrative control" wouldn't protect you: Mail purporting to come from you can be convincingly forged from elsewhere, given a little artful SMTP header artistry.
Well, the two main principles you try to follow with businesses' InterNIC records are (1) ensuring out-of-band communication and (2) avoiding single points of failure. I certainly agree that most businesses do it wrong, but doing it correctly isn't difficult. (You do secondary DNS and backup MX service with someone distant from you, and he does it for you, making it effectively free for you both. At least, that's the traditional way.) And, I really think professionalism requires it.
As to the problems of e-mail systems not under one's administrative control, that would indeed be a problem if you failed to set a security option for your InterNIC contact record. But you'd do that anyway, right?
Please note that I made no claims about LinuxOne's redundant power architecture or lack thereof. I merely mentioned (in the context of discussing DNS redundancy) that both of their Linux machines were in the same office on the same power circuit. I'm sorry, but that's self-evidently so -- and it's just one detail of the overall somewhat slipshod setup, that I happened to mention in passing.
Slashdot Mirror
Mr. Connell makes a number of questionable assumptions:
1. "People set up computers alone."
Actually, they seldom set up computers at all. They use preloads. If customers actually had to install Win98, let alone WinNT, on a blank hard drive, we would cease to hear these foolish, context-less complaints about Linux being "difficult to install".
2. Further, he assumes that consumers won't accept any other sort of setup regime. Never mind the fact that they already do (i.e., preloads): Why should we believe that OS setup/configuration cannot be a salable service, just because Connell can't imagine it?
3. "To address this reality, new computers with pre-installed Linux should work fully and completely the first time they are turned on."
The above appears to assume that such is not the case, which is a fearsome insult to the painstaking work of ASL, Tuxtops, Cosmos Engineering, Cobalt, PromoX, Rebel.com Inc., etc.
However, he goes on to (one assumes) clarify what he meant:
"When the user plugs in a standard option that they already own -- printer, network, external storage device, etc. -- those options should be recognized and configured automatically." By way of comparison, he cites MacOS running on Apple hardware.
But that begs the question: Isn't the ease of installing peripherals on MacOS made possible by the carefully controlled standards of Apple-compatible hardware?
If you'll pardon the expression, "Apples, meet oranges."
4. "Unfortunately, most people don't know a computer expert of any kind, much less a Linux expert. It is important for the Linux community to keep in mind that most users will be completely on their own when setting up or installing Linux systems and software."
Again, this assumes that the only way the world can run is the way Connell is familiar with.
5. "Learning new applications is hard.... Several Linux fans wrote to me stating that the 'application problem' is actually a 'user problem'. Users are incorrectly resistant to change, the argument goes, when they should be accepting something that is new and better. This is backward thinking."
More to the point, the entire dichotomy Connell poses, here, is a red herring: The general (proprietary-OS) computer population already learns new applications on a recurring basis -- every time their vendors' upgrade treadmills crank up another notch, and also often when a change of management (or of employer) means learning the new local "standard": If the management team du jour says you're going to use Groupwise instead of Exchange, you'll learn it. If the local standard is Microstation instead of AutoCAD, you'll learn that, too. And when the next revision of your cherished office bundle shuffles half of the functions around, you'll learn that, too.
The point is that, if you're already contemplating a forced upgrade to your proprietary-OS package (or between two such packages), maybe the real question isn't whether learning new applications is hard, but rather whether learning new applications on Linux is significantly harder than what you're already considering.
6. "It is not the job of the masses to adapt to your computer system. The history of business is carpeted with extinct companies that did not understand this."
This seems to assume that Linux is a business. Of course, there are businesses based on Linux, but Linux itself will not live or die according to market acceptance the way, say, OS/2 did. If every significant Linux-based firm were to close its doors tomorrow, the open-source developer community, the user base, the Internet-based community mechanisms that create and nourish them both, and all the $1.99 CD-ROMs would go on with barely a jitter.
Connell's spectre of "extinct companies" is a mirage.
7. "Consider focusing your immediate application efforts on the few key pieces of software that receive 90% of home and office use.... You might create a native Linux look-a-like for MS Word."
Connell's assumption, here, is that this is or should be a task for the Linux community at large (or at least for Linux developers collectively). Which begs the question: Why? Those who want such software will create it or pay for its creation, if they want it so badly.
It's surprising that Connell should raise this argument, since obviously he's been around Linux for quite some time. The community's tradition is well known, and eminently pragmatic: If you want a piece of software created, you're free to take out your copy of gcc and hammer it out -- or give someone else a personally compelling incentive to create it.
8. "The Linux community has been on a honeymoon as it has created the Linux software.... As Linux is embraced by more organizations, and used in more ways that are crucial, the demands upon you will increase."
The Linux community has ignored clueless demands before, and it no doubt will again. "Pressure" and "demands" from third-party companies are a no-op, per se. Of course, they can "pressure" and "demand" coders they pay adequate salaries to (if they can retain such), but that is a different subject.
The assumption, in any event, is that such "demands" are a problem. That is a claim without substance.
"Wealthy organizations, accustomed to getting their way, will demand impossible schedules from you, and then complain if the quality is not perfect."
Ditto.
9. "Some readers have suggested to me that the open source method of software development causes project management issues to evaporate; that the projects manage themselves. This is a fantasy."
It is also yet another red herring. Those who need and want legal accountability and fiduciary responsibility will hire (and otherwise pay) people who wish to agree to such relationships. But that occurs distinctly from the regular community-based open-source model.
10. "You will be managing a large public programming project with conflicting demands, tight schedules, and the need for high quality."
Connell fails to state what hypothetical assumptions would lead to this situation, but one gathers that he means something like what AOL/Netscape's project managers for Netscape 5.0. Indeed, Netscape might have a project-management problem -- but, if it decides it doesn't like limited social contracts, it can at any time have exactly as many programmers on staff as it's willing to pay for (thereby buying into an entirely different collection of problems).
Connell also begs the question of what constitutes "good project management". If community-based open-source projects can't always be counted on to meet milestones and deadlines, it's equally true that they're largely immune to shipping in bug-infested condition just because some butthead executive needs to doctor the end-of-quarter books.
11. "Humility is a virtue. If Linux succeeds in a significant portion of the computer world, and it looks like it might, your time in the limelight is short." Connell then tells the cautionary tale of his former career at Digital.
However, again, Linux is not hostage to corporate fortunes. Linux cannot "go out of business", or "take a nosedive".
Connell's suggestion that Digital's fate can befall Linux is thus illogical.
12. "The same thing will happen to you. The Linux killer is just around the corner. You don't know what it is, and you won't recognize it when you first see it."
The assumption here is that this would necessarily be a bad thing, and that we have some reason to cling to Linux in the face of this "killer". Suppose the "killer" is something better than Linux. Why would we not welcome it?
"The next generation of techies will understand it and will consider you old fogies for having your heads buried in the Linux sand."
Begs the question: Aren't we on Linux because we're early-adopter types who chose it for various technical advantages? If so, wouldn't we be the ones adopting and understanding this new thing, and looking back over our shoulders at the reactionaries?
And, lest we forget: Connell seems to assume throughout his essay (but here, particularly) that one uses just one operating system at a time. Yet, it should be obvious that diversity serves a purpose, and that no one OS fulfills all roles well.
Connell is obviously a talented writer. It would be good to see him cease arguing bogus positions resting on doubtful premises.
-- Rick Moen
rick@linuxmafia.com
Sure I remember it. I even tried to download it (whilst in WinD'ohs) from Rick Moen's site. WinD'ohs kept insisting the file was html formatted
Hmm. If your browser chokes on http://linuxmafia.com/pub/linux/ apps/netshow_linux, then try ftp://linuxmafia.com/pub/linux/ap ps/netshow_linux.
You're referring to Microsoft's NetShow Revision 2.00, Build 251 beta (aka Media Player), the very first Microsoft application for Linux, released in Oct. 1998. This is a stripped, statically linked x86 ELF binary. 2MB. http://linuxmafia.com/pub/linux/ apps/netshow_linux
The above is now the main distribution point for that software, since Microsoft removed it and all mention of it from its Web pages. It's not half bad, though I'm keeping it available mostly for historical reasons.
Indeed an amusing article (the ZDNet one). However, a couple of weeks ago, I happen to have written a piece that I think does comprehensively cover the question: http://linuxmafia.com/~rick/faq/#virus
I wrote that after I was ask about Linux virus-checkers once too often.
In my articles about this company for The Register and LinuxWorld Online, I raised questions about LinuxOne's fulfillment of its GPL obligation to provide access to source code. I'm happy to report that the company appears to have substantively corrected its omission, in this area: The on-line order form now includes a checkbox to request source code, at no extra charge.
That is a welcome development, and I applaud it.
Credit where due, folks: It's only fair.
As to the rest: As I mentioned in my (and Eileen Cohen's) LinuxWorld article, if LinuxOne can carry through on its ambitions to produce and distribute Chinese- and Japanese-language versions, I'll be the first to cheer them on.
And I won't be investing in this firm, for reasons amply described, but I nonetheless wish them luck.
Well, I was going to retrieve copies of these binary-RPM "driver" files, and see if these were from Dell or are copies of open-source software from elsewhere. (Why? Because if they're distributing binaries of other people's GPL-covered drivers, and not offering source, then they're violating the licence.)
But the site is suffering from Microsoft-induced damage:
error 'ASP 0115'Unexpected error
A trappable error occurred in an external object. The script cannot continue running.
Afterthought: If the reason we're supposed to admire Dell is that they offer rather generic and poorly customised preloads of one (only) Linux distribution, then why are we supposed to be excited at binary-RPM drivers on a Web site? Does the preload come without drivers, or what?
I'll assume good intentions, here, but Dell definitely doesn't quite get it.
Where's the source code?
If Dell wants to be taken seriously on Linux, providing binary-only RPMs of x86 drivers is not the way to do it. Binary-only drivers are a security hazard, they don't benefit from peer review, they're not portable to other CPU architectures that use the chipsets they serve, and they're prone to breakage as the kernel develops. Giving us those, only, isn't even half a loaf. More like 1/10 of one.
If Dell Computer wants to get serious about this, it can start by providing chipset information on its so-called "system specifications" Web pages. Consider, for exmaple, the Inspiron 3500 system specifications page: What's the PCMCIA chipset? What's the sound chipset? What are the chipsets for the optional modem and ethernet cards? Is the CD-ROM a standard ATAPI one, or on a custom interface? Is the floppy drive on a standard floppy port, or is it USB?
And, then, once they really get serious, they can apply their influence to get full programming interface information and sample driver code for those chipsets released to the Linux developer community.
That would be genuine Linux support.
Meanwhile, it would probably be better for Linux users to patronise companies that at least seem to understand the issues, and are trying. Such as IBM with some of its ThinkPad models, for example.
Credit goes to Bay Area Linux activist Deirdre Saoirse for noticing that the plaintiff was getting away uncontested with claiming that DeCSS was a tool for copying DVDs (which it isn't) as opposed to playing them.
Deirdre got the attention of defence attorney Robin Gross, during a court recess, and made sure they understood the very vital point that DeCSS has nothing to do with DVD copying, which was possible (but uneconomical) before DeCSS was written using other tools entirely. The defence team then explained this to the judge, who was visibly surprised by the news.
The plaintiffs may well have lost the day, right there.
-- Rick M.Hot off the press (from Robin Gross, the EFF's counsel on the case):
The judge has denied the motion for a temporary restraining order. More to come soon.
Brooks's Law is no longer applicable in the Internet environment.
That is not Raymond's allegation: He claims that debugging is parallelisable in open source. Brooks's famous observation was, of course, that development cannot be parallelised. Raymond nowhere challenged this latter assertion.
-- Rick M.ugh.. that would kill off the possible explanation that the lawsuit did anything to 386BSD.
No, it wouldn't. 386BSD's code was potentially encumbered in exactly the same way that Berkeley's reference code was: If memory serves, the first release of 386BSD was essentially NET/2 code. That automatically implicated it in the lawsuit along with BSD OS.
But you're right that we're getting very far afield, at this point.
-- Rick M.What point was the author trying to make by saying (remember him?) everytime RMS was mentioned?
It's a running gag I had with the Linuxcare sales staff. You're missing the context for this, but that's because nobody really explained where my essay originated:
While I was a manager at Linuxcare, we set up a mailing list called "Brown Bag" to try to answer technical, licencing, and similar questions from the sales force. I ended up sending to that mailing list a long series of essays like the current one, about different aspects of free software (e.g., what's the deal about the GPL being "infectious").
The sales force got to know RMS from hearing him speak to them at length, a month or two ago. Ever since then, when I've spoken to a salesman to answer a question and RMS's name comes up, I often said "Richard M. Stallman (remember him?)".
I left Linuxcare this past Friday, but sent in the "forking" essay for the Brown Bag list, to complete the series, and as a parting gift to the sales staff, who are all good people whom I enjoyed working with, greatly.
-- Rick M.That statement I bolded is entirely incorrect. We know from the time-table that FreeBSD and NetBSD were derived from 386BSD, which came before the lawsuit.
I'm sorry, but your conclusion does not follow from your premise.
I nowhere stated that the lawsuit had an immediate cause-and-effect relationship to the fate of Jolix. I would not have done so, since, as a one-time 386BSD user myself, I know that the situation was quite a bit more complex.
We also know from Theo's archive that OpenBSD splitting from NetBSD had nothing to do with the lawsuit.
I'm sorry, but it's arguable that this latter split would not have happened had Bill Jolitz and his wife not, earlier, dropped out of sight, which in turn was a proximate effect of the lawsuit.
But, in any event, I didn't get into that at all. All I said was that the splits happened "under the stress of the lawsuit."
Now, I don't object to you reading into that a great deal more than I wrote. However, don't complain to me about what you then come up with.Where the camps had trouble, which I'll point you straight to SVLUG's history page, is that the lawsuit created tension.
Bingo. And that is what I said.
Also, the old tale is that AT&T sued because BSDI used 1-800-ITS-UNIX, and UCB was sued as a result.
That is yet another part of the story. The story I deliberately did not tell, because that would have been a different essay entirely.
I'm not sure if that's true, since its all 3rd or 4th hand knowledge (not even close to 2nd hand :-).
Shame on you for missing Kirk McKusick's talk. That was, of course, first-hand.
-- Rick M.Sorry, I misread that sentence; you don't explicitly say Stallman personally wrote glibc.
That's OK. I could certainly have been clearer.
However, you say "Stallman's library" (or similar words) many times.
I will admit that saying "Stallman" when one means "the FSF" is a very bad habit, and I will try to cure myself of it.
No, I feel that if you are going to write a historical essay you should try a bit harder to avoid false statements or phrasing that is likely to be misunderstood. And if mistakes or misleading phrasing is pointed out, you should try to correct them.
If you mean "correct them" on the Linuxcare Web site, you're talking to the wrong party: I have no connection to Linuxcare, Inc. since I quit that company last Friday. However, I submitted the piece (for a company-internal mailing list, I should note) under the GNU GPL, so you are eminently free to rewrite it any way you like.
-- Rick M.you richly deserve flaming....
Oh, don't worry. I won't take it personally. People seem to get very worked up over these matters. Why, I don't know.
There is no murkiness at all; tons of people have been involved and know all about it.
Unfortunately, they do not appear to agree, as can be seen by examining the comments here, if not elsewhere. A situation that isn't aided by people going out of their way to misread what I wrote, and read into it meanings I never stated.
Example: the origin of pgcc. Stallman didn't "ignore repeated requests" for Pentium-specific optimization, the necessary information was trade secret at the time.
Oh, at one time, they were indeed. And then, later, they were available, but not accepted into gcc. Which is what I said.
Cygnus never had anything to do with pgcc.
What I remember saying is that individual Cygnus staffers were involved with PCG. Is this not correct? I'm pretty sure I verified that, back when I was running a Stampede Linux beta.
Your history of Lucid Emacs/XEmacs is, as Per has pointed out, completely wrong.
Indeed. I had it confused, at the time I wrote that, with Gosling emacs.
-- Rick M.Your exactly right. The time table of BSD shows Rick is incorrect.
That might be a valid criticism if my article had included any sort of chronology. But it did not: I omitted any mention of when BSD OS, SunOS, and Jolix forked off from BSD 4.x because it simply was not germane to the point of the article.
I in fact ran 386BSD 0.1 -- downloaded by modem and and written out to floppies. But that would be a completely different article.
-- Rick M.I don't think the facts are quite straight regarding FSF Emacs vs XEmacs.
No, they absolutely aren't. I really was meaning to write about Gosling emacs there, but somehow got sidetracked onto xemacs. Apologies to users of emacsen everywhere, and especially to Jamie.
At the time I wrote that, I was a bit distracted, as I was typing it into a laptop next to my girlfriend's hospital bed, last Saturday. But I should have caught that gaffe before sending it to Linuxcare. (The original version was my parting-gift essay for Linuxcare's sales staff: I had resigned from that firm the previous day.)
Questions of history aside, the main thing preventing a merge right now is that the XEmacs folks don't have legal papers for all their contributions.
Yes, collecting the copyrights would be an additional obstacle. However, the ones listed were those I recalled from Ben Wing's talk at SVLUG on July 1, 1998.
The statements about the current maintainability of XEmacs vs FSF Emacs are also suspect.
They are some combination of Ben Wing's SVLUG presentation and my own surmises. But, of course, differences of opinions are what give us horse races.
Also, with regards to GCC->EGCS->GCC, I don't believe Stallman ever did anything to delay the arrival of Pentium optimizations.
I did not mean to imply personal intransigence on Richard's part, just that FSF was dragging its feet.
-- Rick M.Sun OS was the BSD product.
Solaris is the result of Sun paying a one time licence to AT&T and then making changes/bringing in BSD compatibility.
(hence all the hate and discontent of some Sun users when Sun OS 4.x was dumped for Solaris)
You're of course quite right, except that this obligatory ritual conversation goes on to say that Solaris still is based on SunOS in some odd Sun Marketing sort of way, with cut-and-paste excerpts from login screens to prove it.
All of which was so far from the article's topic that I decided it's better not to go into it.
-- Rick M.For example, the article states that "Lucid Emacs" was proprietary, and implies that it predates the GPL.
Oops, you're right. I was thinking of Gosling emacs, not Lucid/xemacs. That's what I get for not double-checking my work.The history of the gcc/egcs/pgcc is also very misleading.
Unfortunately, the facts are somewhat murky, and more than a little disputed. I notice that my brief account does, for whatever it's worth, match the one give at http://www.tuxedo.org/~esr/writings/cathedral-baza ar/cathedral-bazaar-15.html.
Finally, Stallman did not write glibc.
Not guilty. I made no such claim.
The mention of non-free BSD-based commercial Unixes implies that these implementation came after the release of the free BSDs and the AT&T lawsuit; they long pre-date both.
Ditto. I implied nothing of the kind.
-- Rick M.The article says that Solaris is under the SCSL.
It does? I certainly didn't mean to imply that. Clearly, Sun Microsystems is contemplating such a move, but has not released the source code except possibly under NDA to some of its close business partners.
If I did imply that, than I must have been rather sloppy. Understand, please, that the whole thing got written on a laptop machine last Saturday, to occupy my mind as I waited in a hospital waiting room for my girlfriend to get medical attention. And I was seriously ill with a case of the 'flu. I'm surprised it came out as well as it did.
-- Rick M.One other thing:
Don't be surprised if people think the phone contact qualifies as "out of band" - it *does*, end of story.
That misses the point entirely. I said quite specifically that "the two main principles you try to follow with businesses' InterNIC records are (1) ensuring out-of-band communication and (2) avoiding single points of failure." That is what I said, and meant, was "doing it right".
The point is that having one of the two ways of reaching you when you have nameservice problems automatically breaks when the problem condition occurs (because you've made that method dependent on the DNS zone in question), then the other method is a single point of failure.
Of course there are myriad way to "do it right". In my view, all are mindful of those two principles, both of them. My point -- and an awfully minor passing point it was -- was that LinuxOne has problems in both areas. Which I call the mark of a network amateur.
-- Rick M.You're getting a little touchy there, Rick.
Actually, more just tired of the time consumed by all this. And the juvenile and gratuitous name-calling.
It struck me as "over-analysis" because what really happened was that several people badly misunderstood my point about DNS redundancy, because they themselves don't know how to do it the right way -- so they went off on extended fantasies about how I'd supposedly said they needed some ludicrous multi-office setup with diesel generators.
I guess I should glad that only three of my sentences were that horrendously misunderstood, else I'd be posting technical explanations in response to flamebait from anonymous trolls until doomsday.
Which reminds me: It's a nice Sunday, and I have better things to do.
But why? Why is the telephone number not adequate? Making a habit of doing this would require that an admin either use an off-site mail server for all of his email, or frequently check a secondary off-site mail server for mail about a DNS problem that will probably never arrive.
My goodness, people seem to be making a very large matter out of one small and passing point, out of many.
An in-band e-mail address as a NIC contact is valuable when the domain in question is reachable, and useless when it's not. Right? I certainly hope you'll buy that assumption, or we're not going to get anywhere. So: You're assuming it's OK for that means of contact to cease working whenever the domain has problems.
I don't share that assumption, because I figure the main reason for the contact information is to be able to get through in case of trouble, and that there are two mechanisms for reasons of redundancy. If one of them inherently goes belly-up whenever the domain has trouble (when contact in my view is most important), then there goes your redundancy.
That's why I said that at least one address ought to be out of band, for commercial sites. And, for heaven's sake, "use an off-site mail server for all his mail..., frequently check an off-site mail server..."? Hey, that sort of scutwork is what computers are for! Have an address that ordinarily goes through a .forward to somewhere, up to and including one's pager or cellular 'phone. Or just use your home address, if you're ssh'ed into there anyway. Or any of myriad other solutions. If you're a sysadmin, you've probably already figured out your own out-of-band solution.
But, really, some of you guys have gone so far out of your way to misread that one small paragraph that I pretty much had to wonder whether we were reading the same article. Like the fellows who claimed I was saying LinuxOne needed redundant multiple power circuits, redundant DNS through tier providers, and multiple offices on different continents.
Beg pardon? What say? All I did was observe that they didn't do the obvious and usual thing of having somebody else do DNS secondary (and preferably also backup MX) at some remote site. Instead, LinuxOne had all its eggs in one basket, in its Mountain View site (and thus, incidentally, on the same power circuits).
Usually, you make an arrangement with the admin of some company in another town: You'll do his secondary, and he'll do yours. A couple of lines of named.conf and sendmail configuration on each end, and you're done. No diesel generators, no "redundant power architecture", no "friggin' UPS for each circuit". If you have those, that's spiffy, I suppose, but unrelated and pretty much irrelevant to the discussion.
So look, guys: If you don't think the principles of out-of-band communication and elimination of single points of failure matter as much as I do, more power to you (but not enough to blow your surge protectors). I wish your networks the best of luck.
And I sure hope that's enough over-analysis on three of the least significant sentences in a 3,500 word article.
-- Rick M.Actually, I wouldn't, as that is the first I have ever heard of such an option. Could you enlighten us further?
OK. Some of this may be slightly wrong because of being off the cuff and from memory, so please forgive some amount of inaccuracy.
Forged InterNIC requests are a real problem, so a year or two ago the NIC came up with an improvement. As you probably know, modify-domain and modify-host requests are honoured if they appear to come from the technical or administrative contact -- or the registrant (domain owner) has final say if need be, but not through as automatic a process.
The improvement gave you the option to set an authentication scheme for each contact record. By default, that setting still defaults to no security. (This is called the "MAIL-FROM" authentication option.) For example, I'm NIC handle RM100. Initally, the NIC would simply believe any change request that appeared to come from my address of record, rick@hugin.imat.com. Alternately, you can establish a password (which you send to them as a crypt hash) aka "CRYPT-PW authentication" or a PGP key ("PGP" authentication.
Separate from the authentication mechanism is the verification setting. This involves two settings: NOTIFY-UPDATE is whether the contact should be notified before or after a record it's associated with has been changed. Allowed values are BEFORE-UPDATE, AFTER-UPDATE, and NOT-CARE. "After" is the default. The NOTIFY-USE setting is whether tbe contact should be notified before or after the contact record has been used in (added to) a domain or host record. Valid values are BEFORE-USE, AFTER-USE, and NOT-CARE. "After" is again the default.
Anyhow, be setting the authentication and notify settings to match your degree of paranoia, you can pretty much control access to domain (and host) records registered under those contact names.
For that matter, if we didn't have those options, having a mail server be "under your administrative control" wouldn't protect you: Mail purporting to come from you can be convincingly forged from elsewhere, given a little artful SMTP header artistry.
For more on the matter, and probably a less fuzzy explanation, please see ftp://ftp.internic.n et/templates/contact-template-examples.txt.
-- Rick M.Well, the two main principles you try to follow with businesses' InterNIC records are (1) ensuring out-of-band communication and (2) avoiding single points of failure. I certainly agree that most businesses do it wrong, but doing it correctly isn't difficult. (You do secondary DNS and backup MX service with someone distant from you, and he does it for you, making it effectively free for you both. At least, that's the traditional way.) And, I really think professionalism requires it.
As to the problems of e-mail systems not under one's administrative control, that would indeed be a problem if you failed to set a security option for your InterNIC contact record. But you'd do that anyway, right?
Please note that I made no claims about LinuxOne's redundant power architecture or lack thereof. I merely mentioned (in the context of discussing DNS redundancy) that both of their Linux machines were in the same office on the same power circuit. I'm sorry, but that's self-evidently so -- and it's just one detail of the overall somewhat slipshod setup, that I happened to mention in passing.
-- Rick M.