Ask Shadowman

Are you a resident of Massachusetts? If you are, Shadowman would like a moment of your time. And if you're not, just nod your head and play along like you are.

In September 2005, Massachusetts became the first state to endorse the OpenDocument family of formats for its public records. More to the point, Massachusetts became the first state to reject Microsoft's proprietary XML format. And Microsoft is mad. Woo, mad. Crazy, nutty, working the mouthpiece organizations mad.

At some point in the not-too-distant future, the good legislators of Massachusetts are quite likely to end up in a good rousing rhetorical fistfight about all of this. In one corner: Microsoft, the 800-pound gorilla, and all the media access and lobbying that money can by. And in the other corner...

Well, that's a good question, isn't it? Red Hat will be in that corner. One can easily imagine that other big companies that embrace open source will be in that corner as well.

But the people who will ultimately matter most will be the people of Massachusetts themselves. Good people of Massachusetts: the hour may come when you get a tap on the shoulder from the corner man. "Fight's on," he might say. "Get your gloves."

So when that hour arrives, be ready. Educate yourself. And come out swinging. Microsoft is on the ropes, and this fight is yours to lose.

Got a question that you'd like Shadowman to answer? Ask him.

---

PK asked:

Shadowman, why is there no documentation on NIS server setup in Red Hat Enterprise Linux 4? I have a lot of problems setting it up like in clients no home directories of nisuser mounted and previous howtos are of no use.

To which Shadowman replies:

As the sages proclaim: there are many questions that have no answers.

Fortunately, this question is not one of them. Go to the Red Hat Knowledgebase, and ask about NIS. You'll find great step-by-step instructions on how to configure NIS servers and clients, including examples.

HR asked:

I would like to send out an executable file (obtained from a Fortran source file) to people to run on their UNIX systems (say at universities or research labs). Is there a Linux or UNIX operating system I can buy from Red Hat and a Fortran compiler so that I can compile on my PC and send out the executable? If I compile with Linux will it run on all Linux systems? Will it run on all UNIX systems?

To which Shadowman replies:

Ah, the dream of platform independence. Write once, run anywhere. In this case, HR, there's good news and bad news.

First, the bad news: Fortran is not one of those spiffy languages like, say, Java, that compiles into bytecode that can be run in a virtual machine on any system. (Assuming that you have the right version of Java running. And that the Java program in question doesn't use nonstandard extensions. Maybe it's not the best example. Anyway.)

Nope, Fortran is old school. Your Fortran compiler builds machine code that is specific to your system architecture. RISC chips, Power PC chips, Pentium chips -- they're all tasty, but they taste pretty different.

What that means to you, HR, is that you'll probably need to compile your Fortran code on every different combination of operating system and architecture you'll need to use.

The good news is that there are many open source Fortran compilers. The GNU Fortran 77 compiler (g77) is an old standby. It comes standard with Red Hat Enterprise Linux, and because it's GNU, it's also freely available for pretty much every flavor of UNIX as well. So you probably won't need to rewrite any code, although you will need to compile that code on a bunch of different machines.

Now, Linux flavors are pretty similar. The odds of getting a Fortran executable to run on different Linux systems -- so long as they're the same system architectures, like, say x86 -- are reasonably good.

You could, of course, rewrite those old scientific applications in Java. Then you'd be practically guaranteed that your program could run anywhere. Just about. Unless you've got an outdated JVM on a particular machine, in which case you might get an arcane error message. Or silent death. Or something.

Sam Samson notifies Shadowman:

We the members and board of Microsoft and Novell Software Companies, wish to congratulate and inform you of the result of the Lottery Winners International programs held on the 7th September 2005. It is aimed at compensating frequent internet users all over the World- Which has boosted sales of software and hardware materials. This is a mark of appreciation for the continuous support and patronage of our customers that have enhanced the reality of our dreams.

Your e-mail address attached to ticket number 5700159491-0017 with serial number 6100-171, batch number 820029013, ref number 6400855090 and drew lucky numbers 2-16-17-31-36-41 which consequently won in the 1st category, you have therefore been approved for a lump sum pay out of US$ 500,000.00 (Five Hundred Thousand United States Dollars).

CONGRATULATIONS!!!

Due to mix up of some numbers and names, we ask that you keep your winning information confidential until your claims has been processed and your money remitted to you. This is part of our security protocol to avoid double claiming and unwarranted abuse of this program by some participants. All participants were selected through a computer ballot system drawn from over 70,000 companies and 6,000,000 individual email addresses and names from all over the world. This promotional program takes place every year. This lottery was promoted and sponsored by Association of software producers, Steven A. Ballmer and William H. Gates(iii). We hope with part of your winning, you will take part in our next year US$1 Million international lottery.

To which Shadowman replies:

Wow. Just... um... wow.

When competitors are sponsoring prestigous lotteries of this nature, and yet Red Hat's name is conspicuously absent, it leaves Shadowman wondering where our priorities are. Perhaps Shadowman will inquire further into joining this "Association of software producers".

Confidential to Vamp:

This precise problem -- the ability to apply upgrades to older kernels, and to keep older applications in sync, stable and tested with those kernels -- is one of the reasons that Red Hat Enterprise Linux is useful. Consider this model as you look for solutions to your problem.