|
|
|
|
The Daemon's AdvocateCopyright © 1999 Wes Peters
The Day After NeverHappy Birthday!This is the first anniversary issue of Dæmon News, and I'd like to take a moment to applaud the people who have made this happen. This group of people have accomplished quite a bit, and not just in the publication of a good, informative eZine. BSD systems have garnered much more publicity in the last year. This been due in part to the increased awareness of BSD systems, and to the increasing corps of volunteer advocates who get the message out. Dæmon News has done more than that, though. It has fostered a sense of togetherness in the BSD community in a way no other has attempted, let alone accomplished. In the past year, we have learned to celebrate the differences between BSDs systems, to speak of the range of solutions they provide, and to embrace and improve the commonality between the systems. I would like to specifically thank the tireless efforts of the editorial staff to get each issue out the door. Brett and Chris have been done a remarkable job, learning how to make an eZine as we go along. The same goes for the corps of proof readers and formatters that take the text we write and turn it into the readable web pages you view; without them we'd be little more than a monthly mailing list. I would also like to thank the writers who have contributed so much of themselves to this effort. Without them, we wouldn't have anything to publish. Our steadily growing readership is a testament to their skills and to the growing interest in our subject. These contributors have followed the admonishment of Jordan K. Hubbard (and, I'm sure, many other BSD advocates) to stop complaining and do something about it. They are doing something about it, and doing it quite well. I would like to extend a very personal thanks to Sue Blake, Jerry Dunham, Greg Lehey, Jonathan Michaels, Jim Freeman, Chris Clark, Greg Page, and Jeremy Garff for reading my columns when they are still in a very raw state, and for providing insightful and sometimes scathing reviews. You have all conspired to make me a much better writer, and to make my columns much more clear than they would otherwise be. Thank you for showing me not only what to add, but also what to remove. A round of applause also for you, our readers. Without you, there wouldn't be any reason to do this. Even these columns are too much work to write them just for the audience of friends listed above. My final thanks for what we have accomplished in the past year goes to Greg Lehey, for saying ``Yes.'' Your professionalism and clear writing style along with your encyclopedic knowledge of BSD have lent a strong backbone of competence to this initially rather amateurish publication. If that sounded a little too much like an acceptance speech for receiving the first Dæmon award, so be it. I'm proud of what this group has done, and for what they've done for the BSD community. Innovate or dieYesterday I participated in a design review meeting for a new product at work. As usual, words like ``innovative'', ``revolutionary'' and ``new paradigm'' were applied to describe the product, none of which were true. It's a good product, one which will probably become the best selling product we've ever made, and hopefully will make a lot of customers happy with their purchase, but it is really just an evolution of everything else the company has ever done.Why do I mention this? Because big companies, and even mid-size companies like mine, rarely if ever innovate. Innovation comes from individuals or small groups who really believe in something, who have a vision. The only vision corporations ever get is of unhappy shareholders and board members, so by their very nature they become conservative and cannot innovate even if they want to. Part of the inevitable path of evolution for small companies that provide innovation is that they either become successful or they die. If they become successful, they typically get bought by larger company, or they become so large themselves they cease to innovate and begin to evolve. Open Source projects have bucked that trend. The open BSD systems and the various Linux distributions have shown they can mature and grow and continue to innovate. It is too early in the game yet to determine exactly what causes the innovation in a growing company to stop while an open source project can grow beyond that boundary and continue to flourish, but I suspect it has something to do with the short sighted nature of American[1] businesses, with their inability to focus on anything more long term than the next quarter financial returns. We live in interesting times. I for one am fascinated to watch this community grow and develop. The next year should prove even more dynamic and interesting than the previous year, with the commercial growth of Linux pumping money into the open source arena, organizations like sourceXchange arranging funding for open source development, and the world of open source application development expanding like the Big Bang. This environment presents a unique opportunity. With more and more users, IT managers, and especially young programmers becoming interested in open source projects, our BSD systems simply have to continue to provide the performance, reliability, and flexibility they are famous for, and to embrace the waves of new users and developers. And, of course, we must tell them we exist. If you build a better mousetrap, no one will beat a path to your door unless they know it exists. Hey, world! We have a better mousetrap here! Come and get it! The Day After NeverAnd finally, I get to the title of this column. You've probably been wondering what this ``Day After Never'' line was about, right?It's about Y2K. This has been beaten to death in the computer trade press, covered by all the big news media outlets, and discussed, researched, tested, and debugged nearly to death by computer vendors of all sorts. It was brought home to me yet again a couple of days ago when one of my coworkers wandered into my office and asked if he could borrow my Garmin GPS[2] data cable. His Garmin handheld GPS unit had an older software revision, every time he turned it on after the W1K[3] roll over, it would perform an extensive ``search the sky'' function, requiring nearly an hour to start up and act like a GPS is supposed to act. Garmin has a section of their web site devoted to W1K and Y2K issues in all of their products. For Chris' older unit, they have a small updater program you can run from a Windows PC that will reassure your GPS its clock is accurate. After booting my workstation into windows, connecting his GPS, and running this program, his GPS unit performed one more ``search the sky'' and now happily starts up in a minute or two like it always has. Kudos to Garmin for great products, and for providing this valuable information on their web page. My Garmin GPS, much newer than Chris', was just fine. I've started it a few times since the W1K roll over, and in each case it was able to find at least 3 satellites in under a minute. If you're looking for a GPS, I can highly recommend Garmin. Please note that I had to boot my FreeBSD machine into Windows to run their updater. While I'm generally happy with Garmin, I'm never happy to find that I have to run Windows to use some piece of equipment; I'd much rather run it on or from my FreeBSD or NetBSD systems, or on one of the Linux or Solaris systems on the network here. So what does this have to do with Y2K?Only that the W1K GPS problem was pretty much a no-show. Some drivers in Japan, heavily dependent on automotive GPS navigation systems to find addresses in the chaos of Tokyo, found their equipment failed to cope with the W1K roll over. Maritime and aviation authorities world wide have reported few if any GPS failures. If the level of preparedness for W1K is a harbinger of the Y2K problems to come, we're in pretty good shape. I say this not because the magnitude of the problems are the same, but rather because the solutions are so similar; the tools and techniques used to analyze GPS applications for W1K problems are also used to locate Y2K problems in applications. A couple of months ago, my partner Jody Worthen[4] mentioned that my birthday might not happen this year. We had been discussing some of the dates associated with their Y2K testing with one of the Oracle DBAs he works with, and they asked if I new about the ``never'' date. I didn't, so they filled me in. For these past 30 years, many business applications for subscription services have asked for both start and end dates for services. When you sign up for a continual subscription, the application doesn't understand that, so the operators of these applications would just enter a date that means ``this never expires.'' Almost universally, this ``never'' date has been 9/9/99. It's easy to type, it's easy to recognize, and you don't even trip over day/month vs. month/day encoding. The problem is, I don't want my gas, electric, phone, and water service turned off on 9/9/99. I want my toilets to still flush, my cars to still run, and my television to still work. Well, we would probably be better off without the television, but the rest of it better still work. I want to wake up on the morning of the 10th, officially ensconced in my ``late thirties,'' and not have to handle any calamities. This is a good time to check your computing systems and your truly vital systems for Y2K issues. Recent versions of FreeBSD, OpenBSD, NetBSD, and BSD/OS have all been audited and tested for Y2K compliance. Contact your ISP and ask about their hosts, access equipment, and routers. Don't forget your physical person while preparing. Contact your utility companies, or visit their web sites if available, and investigate their Y2K preparedness. This is not an occasion to panic, but it is an occasion to prepare.
Wes Peters, wes@softweyr.com
|
||||||||||