Slashdot Mirror

Handspring Visor (TM) + iSilo (TM) + The Perl CD Bookshelf = Perl Hacker's Reference Nirvana

I carry 6 books with me on Perl, along with the whole bundle of Perl docs that come with Perl itself, on my Handspring Visor with a memory expansion module. It's nice, fairly readable and usable, and searchable. I even read the XS tutorial while in the can. It took some ponderance and reflection, and what a better place to do it? :)

As for the search engine on the CD-- it's in Java, and I've gotten it working under Linux. IIRC, there are directions in the kit on how to get it working.

As for books in general, I'm working on getting more and more of them into my Visor, but I still tend to need a physical papery copy of it lying around. Electronic books (at least on the Visor) still haven't gotten the correct user interface details down to replace paper.

My current companion is DocBook: The Definitive Guide, so that I can be a DocBook XML expert while composing the massive body of documentation for my Open Source project. Try learning a new set of XML tags without flipping rapidly back and forth to see what's valid within what, what attributes are legal where, and what the hell is this?

If you have some device that isn't supported, why not either write a driver for it (IF you know how to do so, of course),

Hell, write one even if you *DON'T* know how. You'll learn a shitload.

Start here:

Linux Device Drivers

I know this isn't exactly what you're looking for, but I purchased a copy of O'Reilly's book Practical UNIX and Internet Security 2nd Edition and have found it to be very useful. This book covers almost everything (accounts, passwords, auditing, logging, backups, physical security, file system, etc etc etc) and is well written (I expect no less from ORA). I also purchased a copy of the book you are referring to, and even though it was not very well written, the "real world" examples of TCP/IP and UDP/IP attacks were a good way to put all I knew about TCP/IP in theory into real world situations. Oh yeah, and from the book, I also know how to disconnect people from IRC now (love them RSTs!).

O'Reilly is happily publishing Open Source books, including the Linux manuals and Using Samba, so there isn't a problem getting stuff printed.

In fact, I strongly suspect that the combination of a traditional publisher, the open source licence it's published under and the active involvement of the Samba Team to swat bugs will produce a book that sells in greater quantity than a traditional "print and hope it's correct" publication.

Besides, Samba will change over time, and the openness of the process will help us keep the book up to date.

--dave c-b

O'Reilly is happily publishing Open Source books, including the Linux manuals and Using Samba, so there isn't a problem getting stuff printed.

In fact, I strongly suspect that the combination of a traditional publisher, the open source licence it's published under and the active involvement of the Samba Team to swat bugs will produce a book that sells in greater quantity than a traditional "print and hope it's correct" publication.

Besides, Samba will change over time, and the openness of the process will help us keep the book up to date.

--dave c-b

While we weren't expecting embedded questions, the O'Reilly / Samba Team did expect lots of bug-fixes and smem substantial changes in Using Samba.

I'd be quite interested in your question process: it sound cool...

--davecb

Here's a non-hardware example: Oracle. Originally, ORCL used basic heuristics and rule-based optimization. However, for large DB's and high-throughput installations, the big win comes with the Explain Plan and the performance-based optimizer. In newer versions, they will stop supporting the rule-based optimizer entirely. (read Oracle Performance Tuning)

Simply stated, there are things you can do @runtime that are nondeterministic at compile time, and thus more efficient.

This is also a good place to find a copy of the
famous argument Linus had on the subject with
the author of Minix:

Appendix A: The Tanenbaum-Torvalds Debate

This is also a good place to find a copy of the
famous argument Linus had on the subject with
the author of Minix:

Appendix A: The Tanenbaum-Torvalds Debate

Learning Perl, 2nd Edition

heckers paper which convinced the management is in here. the whole story is here.

the event was important in the history of open source, as it was the first major company opening it's source and many followed by now ( opencascade.org, zope.org )

Damian Conway's Class::Multimethods module for traditional OO in Perl.

• Most Improved Kernel Module: FreeBSD's Linux emulation module.

• Unsung Hero: In descending order:
  • Kirk McKusick, for his more than two decades of tireless service and personal sacrifices for our community.
  • Gurusamy Sarathy, Perl project release manager, responsible for bringing fork(2) to Microsoft ports of Perl and a million other things to make Perl code truly robust and portable between Microsoft and Unix platforms, a true Godsend for those of us forced to co-exist on both.
  • Malcolm Beattie, for trailblazing the Perl-to-C compiler, the Perl external byte-code interpreter, the first Perl/Tk implementation,threading in Perl, and safe blackbox compartments for mobile agents in Perl.

• Best Newbie Helper: Mike Stok from comp.lang.perl.misc. He is patient and kind, never chiding nor arrogant. He has been doing this job for many years.

• Most Deserving Open Source Charity: The Usenix Association. They don't take sides. They promote technology and open standards while remaining vendor neutral. They promote all aspects of advanced technology, but are especially supportive of open source solutions. No organization has done more to legitimize us over the last twenty-five years.

• Best Open Source Advocate: Larry Wall. He doesn't rant against anyone, tries to help everyone, and gives his code away for use by anyone, even Microsoft users. He doesn't restrict his good works to things that only benefit his friends. He doesn't preach, but lives by example.

• Best Unix Desktop Eyecandy: The newest version of the randomizing X screensaver. It's really great in a room full of people on acid.

• Best Unix Desktop Earcandy: The following entry in one's .Xdefaults file:

  *visualBell: on

• Best Desktop Theme: ShinyMetal

• Best Open Source-Related Book: In order of highest to lowest, all worthy of the award:
  • Writing Apache Modules with Perl and C by Lincoln Stein and Doug MacEachern.
  • Damian Conway's Object-Oriented Perl.
  • Elements of Programming With Perl by Andrew L. Johnson.

• Best Perl Module: Damian Conway's Class::Multimethods module for traditional OO in Perl.

• Best Apache Module: mod_perl; how can there be any question?

• Best Open Source Text Editor: The vim editor (vi improved), complete with its gvim graphical incarnation and its perl and python plug-ins.

• Best Deserving of a $2,000 Award:
  1. The late, great Rich Stevens's children's college fund
  2. Larry Wall's children's college fund
  3. Dennis Ritchie's retirement fund.
  (Perhaps those count as charities :-)

• Best Designed Interface in a Graphical Application:
  1. The eesh shell for controlling Enlightenment.
  2. The ddd debugger
  3. MacOS X's environment.

• Best Designed Interface in a Non-Graphical Application:
  1. The {Free,Open}BSD ports collection: being able to just cd and type make and have everything happen is the best thing that ever happened to third-parts apps.
  2. The make menuconfig directive for building Linux kernels.
  3. The v4.0 trn newsreader, with scoring and plug-ins.

• Best Dressed: Larry Wall, whether he's wearing Hawaiian shirts, tie-dies, or best of all, his outlandish, pastel-coloured tuxedos.

• Favorite Slashdot Comment Poster:
  1. Guy Harris
  2. Tom Christiansen
  3. Enoch Root
  4. Jay Maynard

• Favorite Slashdot Author: David Brin wins this one hands down.

• Best Slashdot Story of 1999: Eric Raymond's story about viruses on Microsoft vs Unix.

• Big Dumb Patent Bully: Amazon, followed by Unisys.

• Big Dumb Domain Bully: NSI, followed by Etoys.

• Clue Stick Award for FUD in Journalism: Slashdot.

Here's the start:

Abstract

Before use Coy: run
code...read rebuke. After use
Coy: run code...haiku!

Introduction

Error messages
strewn across my terminal.
A vein starts to throb.

Their reproof adds the
injury of insult to
the shame of failure.

When a program dies
what you need is a moment
of serenity.

The Coy.pm
module brings tranquillity
to your debugging.

The module alters
the behaviour of die and
warn (and croak and carp).

It also provides
transcend and enlighten, two
Zen alternatives.

Like Carp.pm,
reports errors from the
caller's point-of-view.

But it prefaces
the bad news of failure with
a soothing poem.

Haiku as error messages

The use of haiku
to couch an error message
is by no means new.

The easiest way
to ornament errors is
with a "canned" haiku.

Salon magazine
suggested this approach in
1998.

They asked readers to
submit error messages
written as haiku.

The winning entries
are now widely known. The best
of them is perhaps:

Three things are certain:
Death, taxes, and lost data.
Guess which has occurred.

But just as canned fish
soon grow less appetizing,
so too canned poems.

Inevitably,
constant repetition robs
them of their piquance.

Besides, there are too
many error messages
that need a haiku.

Perl's diagnostics
alone would require just
under 500.

And, of course, there's an
endless supply of user-
defined messages.

Here are references for you:

• The paper referenced above
• Damian's directory on CPAN
• The Coy.pm module itself
• Damian's home page

I imagine that this module will now allow ending haiku postings on Slashdot.:-)

Here's the start:

Abstract

Before use Coy: run
code...read rebuke. After use
Coy: run code...haiku!

Introduction

Error messages
strewn across my terminal.
A vein starts to throb.

Their reproof adds the
injury of insult to
the shame of failure.

When a program dies
what you need is a moment
of serenity.

The Coy.pm
module brings tranquillity
to your debugging.

The module alters
the behaviour of die and
warn (and croak and carp).

It also provides
transcend and enlighten, two
Zen alternatives.

Like Carp.pm,
reports errors from the
caller's point-of-view.

But it prefaces
the bad news of failure with
a soothing poem.

Haiku as error messages

The use of haiku
to couch an error message
is by no means new.

The easiest way
to ornament errors is
with a "canned" haiku.

Salon magazine
suggested this approach in
1998.

They asked readers to
submit error messages
written as haiku.

The winning entries
are now widely known. The best
of them is perhaps:

Three things are certain:
Death, taxes, and lost data.
Guess which has occurred.

But just as canned fish
soon grow less appetizing,
so too canned poems.

Inevitably,
constant repetition robs
them of their piquance.

Besides, there are too
many error messages
that need a haiku.

Perl's diagnostics
alone would require just
under 500.

And, of course, there's an
endless supply of user-
defined messages.

Here are references for you:

• The paper referenced above
• Damian's directory on CPAN
• The Coy.pm module itself
• Damian's home page

I imagine that this module will now allow ending haiku postings on Slashdot.:-)

My nominee is "open sources - voices from the open source revolution". It's a book, published by oreilly, with some 14 articles by open source heros.

If you read it you get a very good impression of the whole open source project:

• history (Berkeley unix, history of hackers, RMS)
• mindset, philosophy (RMS, ESR, Larry Wall :-)
• how a particular project works (apache, mozilla, linux
• the company-stuff (netscape, cygnus, red hat)

All in all it makes for a very decent introduction. You get a good overview and you get a foundation of information on which to build your own mindset regarding open source. It filled in quite a few blanks for me, so I like to recommend it hearthily! greetings, Reinout

First of all, I recommend the O'Reilly Servlet book.

Second, pick your servlet engine carefully. I saw the reference to some hello world tests in a previous post. The servlet tests look like they were run on Apache's servlet engine. Too bad its dog slow (last I read about it that is ~6 months ago--I'm sure that they will catch up). We used Servlet Exec, and it works well. Also, be careful to not to let yourself be misled by micro benchmarks.

Third, consider your needs. In our servlets we were able to take advantage of object caching, sophisticated object to relational mapping tools and CORBA connectivity to back end services. There's a very nice java servlet framework called Webmacro, which is free (as in software not beer). I also see potential in JSP's, although I have no direct experience with them.

I also saw some comments about Java being slow. Yes, that's true. However I would venture to guess that its fast enough for all but the most demanding applications. Comments from another post said that you'll require serious hardware to do servlets. No doubt. However, computers are getting faster and so are Java VM's. I'm sure that Java will be fast enough for those demanding applications in the next couple of years, and my opinion is that if you want to be ready to slide down that slippery slope (like Chevy Chase in Christmas vacation) when its slick enough, then there's no better time to start greasing up with the right lubricant and getting the experience than now.

In short, we've had good luck with servlets. Developement has been quick (most of the development speed gained in Java is cut out from debugging when compared to c/c++ I can't compare it to perl though). The web sites have performed well. Personally, I believe that developer time is more valuable than CPU time, so I would recommend (IMHO) spending the extra dollars on hardware, and saving on the developement and maintenence.

Good Luck

Over the past couple years, hundreds of emails have piled up that I should have replied to and handled in some way, but I didn't because I was both busy and lazy. At the same time, I've been accumulating quite a few books about things I want to learn. They sit on a shelf or the floor, mostly unread. Sometimes I look at all that I am supposed to be doing and want to do, and it's just overwhelming. My time management is severely lacking. The dawn of the 2000s (with the 3rd millennium / 21st century now less than a year away) provides an excellent opportunity to get my life in order.

I've given some thought to how I can learn and do more while enjoying a less chaotic life. Rather than just semipassively dealing with things as they come, I need to set specific goals and outline incremental steps toward their achievement. These steps should be mapped into a timetable that I will make a sincere effort to follow. This will not and should not be rigid, but should allow flexibility and changes as appropriate. I'm not going hard-line on myself -- just trying to apportion my time in an optimal manner.

Here's an example of how I intend to work this: I would like to learn Perl in the first half of this year. I own O'Reilly's Learning Perl book, which has 19 chapters. I'm in chapter 2. All I need to do is read at least three chapters per month (trying for one a week), and I should have enough basic skills to make my website more dynamic. It's easy to allocate an hour here and there for a trivial chunk of reading. What's important is that I stick to it.

I'll probably read several books concurrently so I don't get bored or frustrated with one while another one like Java beckons enticingly. No log jams here. :)

I'm not limiting this time management approach to just books, either. There are some things I seriously need to work on IRL. Exercise is just one of these. I've found it hard to drag myself to a nearby health club for a few minutes every week. Well, I'm going to step it up, because a healthy body leads to a healthy mind... or at least a better lifestyle.

But the point of this message is that I believe that self-discipline is the key to achieving goals and making the most of the time and resources God has given us.

Happy 2000!

Over the past couple years, hundreds of emails have piled up that I should have replied to and handled in some way, but I didn't because I was both busy and lazy. At the same time, I've been accumulating quite a few books about things I want to learn. They sit on a shelf or the floor, mostly unread. Sometimes I look at all that I am supposed to be doing and want to do, and it's just overwhelming. My time management is severely lacking. The dawn of the 2000s (with the 3rd millennium / 21st century now less than a year away) provides an excellent opportunity to get my life in order.

I've given some thought to how I can learn and do more while enjoying a less chaotic life. Rather than just semipassively dealing with things as they come, I need to set specific goals and outline incremental steps toward their achievement. These steps should be mapped into a timetable that I will make a sincere effort to follow. This will not and should not be rigid, but should allow flexibility and changes as appropriate. I'm not going hard-line on myself -- just trying to apportion my time in an optimal manner.

Here's an example of how I intend to work this: I would like to learn Perl in the first half of this year. I own O'Reilly's Learning Perl book, which has 19 chapters. I'm in chapter 2. All I need to do is read at least three chapters per month (trying for one a week), and I should have enough basic skills to make my website more dynamic. It's easy to allocate an hour here and there for a trivial chunk of reading. What's important is that I stick to it.

I'll probably read several books concurrently so I don't get bored or frustrated with one while another one like Java beckons enticingly. No log jams here. :)

I'm not limiting this time management approach to just books, either. There are some things I seriously need to work on IRL. Exercise is just one of these. I've found it hard to drag myself to a nearby health club for a few minutes every week. Well, I'm going to step it up, because a healthy body leads to a healthy mind... or at least a better lifestyle.

But the point of this message is that I believe that self-discipline is the key to achieving goals and making the most of the time and resources God has given us.

Happy 2000!

For another view of computer documentation, try my article:

http://www.oreilly.com/~andyo/professional/reliabl e.html
Methods and Mechanics of Creating Reliable User Documentation

You can get the entire Using Samba online at O'Reilly's web site.

Note that Samba currently has problems with most PDC and BDC scenarios and share ACLs among other things, and I'm not too sure that Win2K hasn't also introduced some issues with Samba compatibility.

Cheers,
ZicoKnows@hotmail.com

A lesser known operating system developed in 1970 at the University of California, Berkeley, called the BSD (Berkeley Software Design) is, in fact, the oldest free operating system.

The first free version of BSD (Networking Release 2) was distributed in June 1991, but got tied up in lawsuits from 1992 to 1994. By the time that was cleared up, early versions of Linux were already available.
--
"But, Mulder, the new millennium doesn't begin until January 2001."

Are the Open Source zealouts at it again?

Fortran itself has quite a limited number of serious users

Ummm...no. A huge number of serious scientific and engineering simulations are coded in Fortran. It is a fairly low-level language that has unmatched capabilities for optimization and parallelization.

For God's sake, take a look at O'Reilly's High Performance Computing"

And don't whine about the license.

1. Compiler optimiztions are very much tied to the architecture, so it's not surprising that the best compiler writers for a high-end RISC platform are indeed employed by same company. In this case, it's "a company like Compaq". The old Digital would have been no different.

2. If a 10% increase in hardware speed costs $10,000, then $400 for a compiler is nothing, even if the executable is only 10% faster than that of g77. And Lo and Behold, it runs on Linux, not the costly, closed-source Tru64 UNIX!

Christ, what a bargain!

In fact, [optimizing tricks for microkernels that also would apply to monolithic kernels] made me think that the microkernel approach was essentially a dishonest approach aimed at receiving more dollars for research. I don't necessarily think these researchers were knowingly dishonest. Perhaps they were simply stupid. Or deluded. I mean this in a very real sense. The dishonesty comes from the intense pressure in the research community at that time to pursue the microkernel topic. In a computer science research lab, you were studying microkernels or you weren't studying kernels at all. So everyone was pressured into this dishonesty, even the people designing Windows NT. While the NT team knew the final result wouldn't approach a microkernel, they knew they had to pay lip service to the idea.

Please see appendix XXX for the full text of the Artistic License. Although this license was originally developed for Perl, it's since been used for other software. It is, in my opinion, a sloppily-worded license, in that it makes requirements and then gives you loopholes that make it easy to bypass the requirements. Perhaps that's why almost all Artistic-license software is now dual-licensed, offering the choice of the Artistic License or the GPL.

Section 5 of the Artistic License prohibits sale of the software, yet allows an aggregate software distribution of more than one program to be sold. So, if you bundle an Artistic-licensed program with a 5-line hello-world.c, you can sell the bundle. This feature of the Artistic License was the sole cause of the "aggregate" loophole in paragraph 1 of the Open Source Definition. As use of the Artistic License wanes, we are considering removing the loophole. That would make the Artistic a non-Open-Source license. This isn't a step we would take lightly, and there will probably be more than a year of consideration and debate before it happens.

The Artistic License requires you to make modifications free, but then gives you a loophole (in section 7) that allows you to take modifications private or even place parts of the Artistic-licensed program in the public domain!

Chapter 10, 'Geometric Algorithms' is available in PDF format, here.

--Kevin

=-=-=-=-=-=
"I think the P-Funk Mothership just landed in my back yard!"

Ah yes, the UNIX and "Open Source"(TM) misinformation campaign rolls forward.

... Whereas the predecessor to UNIX, Multics, a large project with heaps of developers failed miserably and never produced a working system. ...

From http://www.multicians.org/history.html
"6. Commercial announcement (1/73)"
It must not of been a working system.

You probably also think that UNIX was the first OS not written in assembler.

From http://www.tuxedo.org/~esr/j argon/html/entry/Unix.html
... The turning point in Unix's history came when it was reimplemented almost entirely in C during 1972-1974, making it the first source-portable OS. ...

From http://www.oreilly.com /catalog/opensources/book/raymond.html
... Thompson and Ritchie were among the first to realize that hardware and compiler technology had become good enough that an entire operating system could be written in C, and by 1974 the whole environment had been successfully ported to several machines of different types. This had never been done before, and the implications were enormous. ...

From http://www.multicians.org/general.html #tag13
...
1.3.3. High-level language implementation

Multics was implemented in the PL/I language, which was then a new proposal by IBM. Only a small part of the operating system was implemented in assembly language. This was a radical idea at the time. ...

If you have a bit of time left, read Open Sources. It contains (among others) an interesting article by Richard Stallman and lists up the controversy around monolithic/micro kernels back in the days when Linux was still a very small project. A well-known computer science professor tried to convince everybody else that 'Linux is obsolete' (appendix A).

Yep - that's unfortunate. Whenever you have physical access to the machine, you can just rip out the plug if you want to. That's why my favorite security book, Practical Internet and UNIX Security, has an entire chapter on how to lock your machines up, physically. For mission critical 24/7 systems, once you've got things as secure as you can on the network end, you have to make sure the machines are in a secure server room with big locks on the doors, a chemical fire extinguishing system, etc.

When you see a book written by "A with B" it usually means that A didn't write a word: A was interviewed by B, and then B wrote it.

For example, the Freeing the Source: The Story of Mozilla chapter of O'Reilly's Open Sources book is credited as ``by Jim Hamerly and Tom Paquin with Susan Walton.'' In fact, that document was written entirely by Susan Walton (and I think she did a good job of it.) She based it on extensive interviews with Hammerly, Paquin, and myself. I pissed off a lot of people (at Netscape and O'Reilly) by refusing to allow them to list me as an author, because, quite simply, I hadn't written a word of it, and I didn't want to take credit for something I didn't write.

``This is how the publishing industry works,'' they told me. ``Everyone knows what `with' really means.'' Well, I hadn't known that, and I found it to be deceptive, so I wouldn't play along. I thought it should have been credited as ``by Susan Walton based on interviews with ...'' or ``...as told to...'' or something, but they hated those.

Anyway, about the Red Hat book...

I thought the history of Red Hat was interesting. But I'll comment on the parts I have direct knowlege of:

The inside-Netscape history is fairly accurate, including the deliberations about the licenses, but as far as I can tell most of it is lifted directly from Frank Hecker's writings on the subject. If you're interested in this part, you should read Hecker's papers, because they are a much better explanation in their pre-condensed form.

I thought their summary of why we didn't use GPL left out a very important detail. Anyone who understands copyright law would respond to the reasons they gave (``we want to bundle with other proprietary software'') by pointing out that the copyright holder always has the right to do things like that. The important point that they failed to mention is that if the copyright holder does so, they eliminate their ability to take contributions from the outside, which is pretty much a deal-breaker. They mentioned that we had a very hard time trying to find a solution to our various license-related problems, but I don't think they did a very good job of explaining what those problems were, or why we reached the decisions we did. Maybe this wasn't an important detail to a book about Red Hat, but if not, they shouldn't have included it at all. What they did include is fairly muddled.

Throughout the book, there were quite a few things that jumped out at me, like saying in one paragraph about Cryptozilla on page 98 ``less than a month after the source code was released ... the group added full encryption,'' and then saying two paragraphs later, ``fifteen hours after the source code release, a fully crypto-enabled version of Mozilla for Linux was released.''

So yeah, 15 hours is less than a month. But the book contains a lot of strange errors like this. It's as if there were no review copies distributed at all. (Were there?)

The entirety of the first year of mozilla.org, between April 1998 and April 1999, seems to be skipped over somewhere in the middle of page 100. Then they say, ``it took over a year for Netscape to ship Netscape Navigator version 5.0.''

When did they ship that exactly? For those keeping score at home, it has now been 18 months, and will certainly have been two years, if it ships at all.

Also they consistently misspelled my name (for which Bob was extremely apologetic -- he mailed me about it a few days before the book was released.) Not that I particularly care about trivia like the spelling of my name, but getting that wrong in a book is really a rookie move, and reflects badly on the book that something so basic slipped through.

I think that all of these problems stem from sloppy editing and lack of review. This book would have been much better if they had taken another month or two to distribute review copies and get feedback and corrections.

``Release early, release often'' doesn't work so well with physical media.

When you see a book written by "A with B" it usually means that A didn't write a word: A was interviewed by B, and then B wrote it.

For example, the Freeing the Source: The Story of Mozilla chapter of O'Reilly's Open Sources book is credited as ``by Jim Hamerly and Tom Paquin with Susan Walton.'' In fact, that document was written entirely by Susan Walton (and I think she did a good job of it.) She based it on extensive interviews with Hammerly, Paquin, and myself. I pissed off a lot of people (at Netscape and O'Reilly) by refusing to allow them to list me as an author, because, quite simply, I hadn't written a word of it, and I didn't want to take credit for something I didn't write.

``This is how the publishing industry works,'' they told me. ``Everyone knows what `with' really means.'' Well, I hadn't known that, and I found it to be deceptive, so I wouldn't play along. I thought it should have been credited as ``by Susan Walton based on interviews with ...'' or ``...as told to...'' or something, but they hated those.

Anyway, about the Red Hat book...

I thought the history of Red Hat was interesting. But I'll comment on the parts I have direct knowlege of:

The inside-Netscape history is fairly accurate, including the deliberations about the licenses, but as far as I can tell most of it is lifted directly from Frank Hecker's writings on the subject. If you're interested in this part, you should read Hecker's papers, because they are a much better explanation in their pre-condensed form.

I thought their summary of why we didn't use GPL left out a very important detail. Anyone who understands copyright law would respond to the reasons they gave (``we want to bundle with other proprietary software'') by pointing out that the copyright holder always has the right to do things like that. The important point that they failed to mention is that if the copyright holder does so, they eliminate their ability to take contributions from the outside, which is pretty much a deal-breaker. They mentioned that we had a very hard time trying to find a solution to our various license-related problems, but I don't think they did a very good job of explaining what those problems were, or why we reached the decisions we did. Maybe this wasn't an important detail to a book about Red Hat, but if not, they shouldn't have included it at all. What they did include is fairly muddled.

Throughout the book, there were quite a few things that jumped out at me, like saying in one paragraph about Cryptozilla on page 98 ``less than a month after the source code was released ... the group added full encryption,'' and then saying two paragraphs later, ``fifteen hours after the source code release, a fully crypto-enabled version of Mozilla for Linux was released.''

So yeah, 15 hours is less than a month. But the book contains a lot of strange errors like this. It's as if there were no review copies distributed at all. (Were there?)

The entirety of the first year of mozilla.org, between April 1998 and April 1999, seems to be skipped over somewhere in the middle of page 100. Then they say, ``it took over a year for Netscape to ship Netscape Navigator version 5.0.''

When did they ship that exactly? For those keeping score at home, it has now been 18 months, and will certainly have been two years, if it ships at all.

Also they consistently misspelled my name (for which Bob was extremely apologetic -- he mailed me about it a few days before the book was released.) Not that I particularly care about trivia like the spelling of my name, but getting that wrong in a book is really a rookie move, and reflects badly on the book that something so basic slipped through.

I think that all of these problems stem from sloppy editing and lack of review. This book would have been much better if they had taken another month or two to distribute review copies and get feedback and corrections.

``Release early, release often'' doesn't work so well with physical media.

Open Sources - Voices from the Revolution is a better all-round read and the whole book is available online from here.

Newsgroup for RedHat Linux installation: http://www.deja.com/group/linux.redhat.install/

Beginners guide for installing Linux: http://www.linux.ie/beginners-linux-guide/

Remember, not everyone will be helpful if you post in a wrong area, like you did here :-) Try to find a relevant site and be sure you first read what's already there since no one likes duplicate postings or being asked a question that's already been answered. I'm jealous of your machine... what a piece of hardware! Did you build it yourself? If so this will help you since you will need a lot of information on your machine once you actually get into setting up Linux. If you didn't build the machine, write down everything you can about what's inside it before you start installing. You don't have any fancy setup to do this for you like Windows does. For an idea of what you need to know, see section 2.1.5 of Linux Installation and Getting Started. When I first installed Linux, I put it on a machine I had built myself and had a second machine next to it constantly logged onto the web for finding information. My "fun" started when the setup couldn't find my SCSI CD/ROM, so I bypassed the situation by plugging an old CD/ROM into a free IDE port and got started. The only other major hang-up after that involved the wrong video card being identified during setup, and my monitor got very hot and made an unwelcome whining noise that sounded like oncoming death (which made me glad it was an older monitor whose loss would be bearable)... fixing this required changing settings on the X-server.

Regarding the posts here on the "6.1" thing, here's a little sidenote. Linux distributors (such as RedHat) have their own numbering system that is best thought of as unrelated to the underlying Linux kernel. You may have RedHat 6.1, TurboLinux 3.6, and Slackware Linux 4.0 all out at the same time using the same Linux kernel, which is version 2.2. The second number indicates whether you have a "stable" or "development" version: if that number is even, it is stable. Thus Linux 2.2 is a stable version, while 2.3 is the current development (unstable) version. While you can download and install 2.3 and think you are getting a "newer" version, don't! Wait until you are way beyond the newbie stage to wander there.

Not that I want to push anyone's products here, but if you are planning to stick with it and get into Linux, you might consider getting a copy of Running Linux. I didn't buy it until I had Linux up and running - reading the first few chapters before I attempted an install would have been helpful, and it is great to have around afterwards to learn from. In the mean time, have fun and hang in there during the installation!

O'Reilly also has some of their books available at their Open Books Project . -Kazir

A safe bet for any toy-lovin' geek remains the Lego Mindstorms kit and accessories. The basic kit is a bit pricey ($219 US), but well worth it. And if your geek has the basic kit already, there are expansion packs ($49.99 US), an upgrade ($24.95 US), additional RCX ($129.99 US), remote controls ($19.99) and touch, light, temperature and rotation sensors ($9.99 - $19.99 US) as well as additional motors ($18.25 US).

All these elements are available at Lego World Shop.

If your geek is the kind of geek who has all the Lego Mindstorms stuff already, there's a book from O'Reilly on Mindstorms ($24.95 US), which will provide advanced tips for design and programming. It was reviewed on Slashdot.

"The wages of sin is death but so is the salary of virtue, and at least the evil get to go home early on Fridays."

A safe bet for any toy-lovin' geek remains the Lego Mindstorms kit and accessories. The basic kit is a bit pricey ($219 US), but well worth it. And if your geek has the basic kit already, there are expansion packs ($49.99 US), an upgrade ($24.95 US), additional RCX ($129.99 US), remote controls ($19.99) and touch, light, temperature and rotation sensors ($9.99 - $19.99 US) as well as additional motors ($18.25 US).

All these elements are available at Lego World Shop.

If your geek is the kind of geek who has all the Lego Mindstorms stuff already, there's a book from O'Reilly on Mindstorms ($24.95 US), which will provide advanced tips for design and programming. It was reviewed on Slashdot.

"The wages of sin is death but so is the salary of virtue, and at least the evil get to go home early on Fridays."

It was ESR's second essay in Open Sources, and you can read it here.

--
QDMerge 0.4!

The licence is kind of interesting.

"Using Samba" may be freely reproduced and distributed in any form, in any medium physical or electronic, in whole or in part, provided that the terms of this license are adhered to and that the reproduction includes this license or a reference to it...

Read the whole story at http://www.oreilly.co m/catalog/samba/chapter/licenseinfo.html.

That contradicts the open source definition as given by Bruce Perens.

There is a commented version in the book "Open Sources" on p. 82, point 6.
No discrimination against persons or groups. He gives the example of an abortion clinic and an anti-abortion organization, and I think he's totally right there. Once you start restricting organizations and people, where will you draw the line?

The very interesting book can be read online and even downloaded from oreilly.com. Or you could just buy a copy! ;-) Here's the URL of the chapter I talked about: http://www.oreilly.com/ catalog/opensources/book/perens.html.

You can read all about Cygnus and its free software business plan from Michael Tiemann's chapter of "Open Sources: Voices from the Open Source Revolution" (aka The Book that Slashdot Made).
--

I, on the other tentacle, recommend getting The Complete FreeBSD by Greg Lehey with the FreeBSD CD-ROM set and starting from there. It is also a great book; Tim O'Reilly has publicly lamented deciding not to publish it. The Complete FreeBSD will walk you through the installation of FreeBSD and then provide help in configuring FreeBSD to do a variety of work, including various internet services and X windows workstation configuration.

Jon Udell talks a lot about groupware solutions using 'simple' Internet protocols such as NNTP and HTTP. Collaboration tools, examples and discussions of this are available in his new book Practical Internet Groupware - see http://www.oreilly.com/catalog/pracintgr/ for more details.

This may help, and fit in nicely with the move to Linux. Good luck

dj (not related to Jon, just interested in what he has to say).

You mean like any of the textbook examples in Chapter 5 of Writing Apache Modules with Perl and C

I went through the same process recently, looking at everything I could find to move from UBB. Whatever I tried came up short on performance or features except O'Reilly software's WebBoard.

I know this package is outside your existing platform, but I've found it reliable and extremely resilient under a heavy load (1000 posts with binary attachments per day). It's also ready to go out-of-the-box and scriptable. Customization is as easy as HTML.

It comes with real-time paging, a variety of chat features, SMTP notification with listservs and .ZIP digests, and NNTP support. Administration is web-based and well implemented.

Drawback is the cost: about $1000 for the software plus an NT box. You don't need to fool with IIS as it runs best with the included web server.

Jonathan has been quite active on the lego user group mailing lists, and he definitely knows his stuff- I'll be ordering the book soon. In the meantime, for those of you who aren't quite ready to buy the book, he has published an excellent list of online resources for Mindstorms. It is quite thorough, and a great place to start if you are thinking about buying a set and wondering what you can find online.
~luge(who is mentioned down there in ch. 10)

"I thought titles like that were reserved for IDG, Sams and other less respectable publishers. "

Yes, Suse is available in a box. As is slackware, Mandrake, and certain others (I just know I've seen others, but can't remember the names).

Two links of note, found thanks to this article:

• Learning Debian GNU/Linux (online book)
  
• Learning Debian GNU/Linux (order page)
  

Yes, Suse is available in a box. As is slackware, Mandrake, and certain others (I just know I've seen others, but can't remember the names).

Two links of note, found thanks to this article:

• Learning Debian GNU/Linux (online book)
  
• Learning Debian GNU/Linux (order page)
  

THE GOOD

• LinuxCare's little bootable Linux recovery CD kicks ass. No bigger than a business card, it fits in the 3" diameter groove in CD-ROM/DVD-ROM drive trays and has the potential to save your butt when lilo eats itself. They also had some Linux stickers that now adorn the case of my 386... (Yes, it runs Linux.)
• IBM had a presence. Although certainly not the largest or flashiest booth in the show, Quake 3 on a rather large plasma display attracted lots of attention. Dual PII-400 Intellistation + Voodoo 3 3000 + large plasma display. Mmmmmm. Thanks to the guys there for letting me get some game time on that mammoth thang...
• O'Reilly also had a presence, and their trade show pricing kicks much booty. Picked up a few books for 20% off list and got a shirt to boot...
• Mad props to VA Linux Systems for not only having a cool booth and giving away lots of stuff but for supplying the machines used for public Internet access. Their Debian boxed set is pretty cool and sports Learning Debian GNU/Linux from O'Reilly. (Yes, I was one of the people who stood around in line for ten or fifteen minutes to win this...)
• Thanks to the Sun and Rave Systems folks for all the free stuff. Learn to play Quake 2 without cheating before next year's show... :-) (Now where's my complimentary Sparc 5?)

THE BAD

• None of the shirts I got fit. None. Zero. Zip. Zilch. I'm 6-foot-3-inches tall and weigh 295 pounds. Show me the big-assed shirts!
• The IBM guys told me that the Showcase had a T-1 connection to the 'Net. I couldn't verify -- the packet loss and latency was horrible on the connection. I'm hoping this is only because lots of geeks were pounding on the connection like a pack of wild monkeys...
• Food choices were few, and lines were long. Within the Galleria, your choices were Subway, some cafe whose name I don't remember, Ruby Tuesday's, and Chick-Fil-A. If you were bold, you could go to the movie theater downstairs and buy a big tub of popcorn. The group I was with walked across the street to another mall and ate at Arby's. Yum... I think.

THE UGLY

• Where the hell were the Slackware people? I wanted Slackware apparel... Hmmph.
• Linux merchandise places came out of the woodworks to hock their goods. Yay capitalism...
• Don't eat at Shoney's. Our group waited over an hour for food before giving up and leaving.

THE REST

• The andover.net/freshmeat.net/slashdot.org booth was smack dab next to the linux.com booth. Taken together, it looked like one big congregation of slackers with laptops. All things considered, however, I wouldn't have minded flopping down on the couch for a rest after walking around for a few hours...
• I will seek revenge against the guy in the Debian shirt who shot me in the arm with a Nerf dart... muahahahaha
• The Debian folks had a Sun Ultra 5 running XaoS, Netscape, and some Tetris clone in separate windows. Just for kicks, I maximized the XaoS window. Can we say slideshow?
• I had nothing interesting enough to trade with the lady at the VA Linux booth, so I didn't get one of those nifty enlightenment shirts. Dammit.
• NetBSD was there. Go figure.

Overall, it was a pretty cool show, but I wish I didn't have the 2-1/2 hour drive. It was put on very professionally and appeared to be very well organized. I was only slightly disappointed that the show wasn't any bigger... The nifty canvas bag attendees got and the included CD made up for that, though.

Intelligent writers have been talking about this for years. One I particularly like is Steve Talbott, who publishes the NETFUTURE newsletter. He was also the article of a very well regarded book on the subject called "The Future Does Not Compute". I disagree with much of what he says (particularly his New Age nature worshiping), but it's always a good read. Especially important are the writings on computers in education.

The following essays he's written should give you a feel for the flavor of NETFUTURE:

Why Timesaving Devices Don't Save Time

and

The Principle of Technological Deceit