Slashdot Mirror

If you want to learn assembler, to it the right way, and get an ARM.

Right, or check out the armulator in GDB and apply this patch to get a cute emulated LCD screen(just a linear frame-buffer) as a window in X to dump your debug messages on.

It doesn't take a lawyer to understand the GPL. I'm a network administrator. I read the GPL. Its really quite clear.

This is exactly my point. You can't just read a legal document and decide that you fully comprehend its implications. Example: at the bottom of this page it says, "All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster." Seems clear enough, right? But it's legal for Andover to republish those comments in a book. (Although, to their considerable credit, they decided not to.)

Some stuff about KDE and Debian...

OK, I should have picked a less combustible example. I didn't make it clear, I guess, that my point here isn't who is wrong or right. My point, and this also applies to Jason Earl's comments below, is that no one on either side seems to really know who is right! They're each relying on their own layman's interpretation. (I do feel compelled to point out, though, that your version of the facts in that case is mistaken on almost every point.)

Red Hat, by the way, has a huge network of mirrors.
-----------

of open source is, that it is marked as "stable" when and only when it is really stable (and not when marketing has decided to ship the product), and yet you can still have your bleeding edge program when you like it.

Open source does guarantee that bugs will be found rather than left concealed, and that they can be fixed straightforwardly. It doesn't in any sense keep them from being made or released in the first place.

The fact of the matter is that some open-source and free-software projects have a vastly better track record in terms of stability (which includes security) than some others.

of open source is, that it is marked as "stable" when and only when it is really stable (and not when marketing has decided to ship the product), and yet you can still have your bleeding edge program when you like it.

Open source does guarantee that bugs will be found rather than left concealed, and that they can be fixed straightforwardly. It doesn't in any sense keep them from being made or released in the first place.

The fact of the matter is that some open-source and free-software projects have a vastly better track record in terms of stability (which includes security) than some others.

From what I understand, GTK-- is on the way out, being replaced by Inti developed at Red Hat. Inti is a documented C++ framework for GTK+. I don't know of any application written for Inti, but it is a space to watch. Also, I believe it was developed because of the immaturity of GTK--, and because corporations really want to develop for GNOME, but want to do it in C++.

Maybe I have it all wrong. When Helix really started coming around I remember reading on Redhat Labs that with Helix working on GNOME usability and how it looked they were going to focus their energy on improving the base toolkits like the GTK. Eazel is making the filemanager thingy(for lack of a better word) to add to the GNOME desktop. This doesn't sound like a battle to me. It sounds like each is working on their own part. Well I don't have anything to add other than that.
Molog

So Linus, what are we doing tonight?

This means that if the compiler is to be of any continuing interest as other than a "bare husk" from which GCC might "mine" some useful techniques, there will need to be a project to create a set of tools basically corresponding to Binutils and perhaps some portion of CygWin so that there is some "base" set of tools and libraries that can be used to recreate themselves.

The fact that there are existing GNU tools to that purpose ought to ease the task somewhat...

This means that if the compiler is to be of any continuing interest as other than a "bare husk" from which GCC might "mine" some useful techniques, there will need to be a project to create a set of tools basically corresponding to Binutils and perhaps some portion of CygWin so that there is some "base" set of tools and libraries that can be used to recreate themselves.

The fact that there are existing GNU tools to that purpose ought to ease the task somewhat...

Even GNU programs sometimes include similar sorts of exception statements, when practical issues demand it; see GNU Guile or Autoconf for examples.

As for linking to the Microsoft libraries, the GPL has a special exception allowing linking with anything that normally comes with the OS or the compiler.

People who say that Java is slow are correct, for the most part. Even with the best JVM, Java cannot approach the speeds of a well-designed native-code application.

You forget that Java can be compiled too. Just look at GCJ

Java is really three things. JWZ has a nice paper about this. It's a language, virtual machine, and class library.

The JVM indeed slows things down, and the class library does some too. But Java the language, even when natively compiled, is slow all by itself.

After all, the GCJ project uses the gcc/g++ compiler code base. So why is a C++ application compiled with g++ so much faster than a gcj compiled application? Must be the use of exceptions and GC (in the form of a shared library with gcj).

So Java isn't slow, exceptions handling and garbage collection are slow.

As has been previously mentioned the company MainSoft has a product called MainWin which is simply an API wrapper library similar to WINe.

Thus it stands to reason that instead of trying to port the existing Internet Explorer and Windows Media Player code, they'll add functionaliy to their wrapper API's until MSIE and Media Player compile with no dependency problems.

Of course, references to C:\ drives and forward vs. backslashes will need to be fixed. From the looks of it this is no different from a *nix version of the Cygwin Project.
The Queue Principle

RedHat does a whole lot more than the "usual" RedHat distribution. Since they aquired Cygnus they've been trying to profile themselves as "The Embedded Linux Company", take a look at EL/IX for instance... This partnership, together with the other ones in the previous weeks does indeed strengthen their profile in the embedded Linux market.

- Joe

GTK and GNOME bindings for Java, though they're through gcj

There are actually two significant GPL'd Java implementations, so whatever "ownership" Sun has should be less of a concern. GCJ is one, on track to be in GCC 3.0 or maybe even GCC 2.95.next; and Kaffe is very well established.

But AWT support is mostly lacking, there. Having Gnome accessible from Java is a big deal, and is likely going to be the site of future major fights. I mean, nobody implemented a cleanroom Swing (over a cleanroom AWT); and who would want to? Do a good API to Gnome instead. Swing has major virtues, but from the perspective of Free Software it's a major downer -- too much code, too much history, too much corporate control.

It'll be really interesting to see how supportive Sun is of GPL'd Java working in the Gnome environment. I suspect that if the community develops, it'll either be using GPL'd Swing (from Sun) or Gnome-from-Java.

Q: What are these same companies contributing to these "core values" of Linux? A: With the partial exception of IBM, nothing.

Just some examples to show that these companies make valuable code contributions to the free software comunity:

HP
Mauve
A free (GPL) test suite for the Java[tm].

Compaq
iPAQ port
Compaq Ports Linux to iPAQ Handheld Computer.

They should also be mentioned for their Linux work regarding 64bit processor architectures (Alpha, Intel).

SUN
StarOffice
Under the motto: Lets use the best of breed components (read filters) in our GNOME office suite. And let us not forget their donations to the Debian developers for the UltraSparc port.

SGI
SGI OSS Projects
Look at this long project list ... it speaks for itself I think.

- Just my Euro 0.02c

(Before I start, I want it made clear that I'm a Linux user, and prefer Linux and OpenBSD to proprietary operating systems of any stripe: MacOS, Windoze, BeOS, AmigaDOS, HP/UX, Ultrix -- you get the idea.)

From the non-technical business perspective, Peter Firstbrook does have some legit concerns here, even if he dances around the core of the complaint. A businessperson "betting the farm" on technology either has to have a great deal of trust in his/her technologists or in the vendors supplying the infrastructure software.

For the Fortune 5000, trust in support technologists is hard to find -- even in those companies that sell technology, such as HP and IBM. Remember, revenue-generating technology is monitored by a pyramid of management and a gaggle of process, while non-revenue technology doesn't have the same money thrown at it. Frankly, IT-based development for internal use just doesn't have the management oversight that a vendor would provide, and the business people know it.

That's why there is a tendency for business to buy infrastructure solutions from vendors who have "thrown money" at the management of technology, and is willing to take responsibility for the gaffs and fix them. (The fallacy here is that the erring vendor -- think Microsoft -- will indeed fix the problems right and right now.) As a side benefit, repair and upgrade costs can be controlled and predicted, with the vendor taking the risk. The business person will pay for 24/7 if s/he feels that level of support is necessary, but wants a definite cap on the costs. That's why service contracts are such an easy sell to Fortune 5000 types -- the contract may be expensive, but it represents a known expense that can be factored into the financial model.

Contrast that with the unknowns with in-house solutions. They may be cheaper to start, but the chance for "surprises" is very high, very frustrating to business types, and makes for an unworkable financial model for the company. How many projects have you worked on that came in on time and under budget?

Now consider the Open Source model. On the one hand, you have a peer review of the code that can't be equaled in proprietary software -- everyone who uses the system can look under the covers and see what's going on. Something not right? Either fix it and provide a patch, or report the problem and let someone else (on their own time) figure out a fix and patch.

In open source, who do you sue when the bug loses you money? There isn't just "one place" you can aim your lawyers to recoup the lost revenue when something goes very wrong. Even Red Hat isn't a very good target, because they just package Linux, they don't take responsibility for bugs in the kernel.

How about that "tinkering" argument? I believe the argument is in fact a red herring, another boogieman to scare non-technical types. Yes, it can happen. In reality, most IT types don't have the background to even attempt it, let alone make it work. The very few that can pull it off may in fact improve matters, if they are supervised properly. So, let's drop that lame claim.

It's not a question of feasibility, or of "goodness."

It's a question of responsibility, of fixing the blame.

Let's leave aside completely the question of what or who a 1.4 GHz Pfoo is currently useful for. The CPU race is engrossing enough as morbid entertainment, chronicled in all its awfulness by sites like Tom's Hardware and the Register. Instead Slashdot features this bland little piece from CNet. Funny there's no mention that the release schedule for this wonder has apparently already slipped. Funny how Intel's current woes with CPU supply, motherboard supply, the competition, and Rambus (oh, Rambus!) get um, let's say a soft touch. Now this could just be down to laziness. Or it could be another case of big-time tech journalism rolling over for powerful Intel. Could it even have something to do with the fact that Intel is a CNet shareholder? (I haven't had time to verify this from a more neutral souce yet.)

This isn't the first time this kind of thing has happened here, is it? (Or indeed the first time it's involved a company partly owned by Intel.) You'd hardly believe Slashdot is also the platform for John Katz's increasingly overblown denunciations of big-corporate influence-peddling.

since I am now posting in the 'company' of a Red Hat employee will probably end up with a lawsuit on my hands to boot

No way, unless you're inventing this to harm our reputation (which I don't think, shit happens).

Sorry for the trouble with ApplixWare - this is probably too long ago to track down and see what caused it, so I'll take it for a typical "shit happens" thing and make sure it gets fixed at least now.

For the software, all I can say is that I can't reproduce it and neither can our other customers - if you send me some details of the hardware (and the version of Red Hat Linux you were using), I'll check what's causing the problems. (We have upgraded some drivers; it may be a problem with one of them).

These problems should go into bugzilla, where actual developers can read them and take care of them. (Unless you have a support contract, the support people will help you with installation; some of them aren't qualified to fix bugs.)

Make crappy software

We're trying not to do that - and I'd really like to know if any of your problems are still occuring with the 7.0 beta version.

blame the user when it doesn't work

I guess every software company is a bit guilty about this one - if something works perfectly for you, then someone tells you it doesn't work, what would you blame first, if you don't know how much the other person knows about the piece of software?

screw the user if you can make a buck

If that was our intention, we'd be making proprietary software.

and sling mud when you have no facts

That's Microsoft's job, not ours.

The installer actually installs LILO and writes the configuration file to /etc/lilo.conf unless you turn it off.

As for the LS120 drive,
http://bugzilla.redhat.com/bugzilla/ is the right place to talk about this - we can't fix problems we aren't aware of.

There were a couple of problems in the 6.1 and 6.2 installers; most of them should be fixed in the 7.0 beta.

from the looks of inti, signals are still c style callbacks with no type checking?

No.

Looking at the headers available at http://sources.redhat.com/inti/inti-manual/ I see that each class member representing a signal is a SignalProxy, which seems to be quite like the signalling facilities provided by libsigc++. Looking at the definitition of SignalProxy, its connect method is parameterized for both the type of the signalled object and the member being connected to.

--
"Where, where is the town? Now, it's nothing but flowers!"

Since I work for a commercial developer, it's unlikely that management will be willing to distribute source code for the application. After all, we'd be giving away some very valuable secrets to our competitors, to say the least. And we can't ignore the Linux market any more. (I'll make the disclaimer here that I'm a developer, not a manager. I don't know if we've already covered these issues as a company.)

I'm hoping someone will have some thoughts or insights into this matter, so we don't end up violating the GPL and getting into legal hot water.

"Well, they have *a* shell under Windows 2000, with an add on product that they actually purchased from another company. The company was Interix, so now the product is Microsoft Interix 2.2. ...[snip]... While I'll admit it feels kind of dirty to use this product"

Any reason you can't use Cygwin, now owned and maintained by Redhat. From the intro page:

Using Cygwin, developers can manage heterogeneous environments in a consistent, efficient way. Cygwin brings a standard UNIX/Linux shell environment, including many of its most useful commands, to the Windows platform so IT managers can effectively deploy trained staff, and leverage existing investments in UNIX/Linux source code and shell scripts.

The tools only take up about 100 megs of space and provide you with bash, ksh, and tcsh as shells, and most of the tools you're familiar with in a GNU *NIX environment, including the compilers. They support Win 95/95/NT4.0-sp3 natively, which would lead me to believe you could get it to run on M$ Millenium without too much difficulty. But wait! We're not finished! Would you like a free Xserver for your Windoze boxen? Check this out!

A more informative site on Cygwin, it's current status, new bulletins, FAQs, etc (it's project center site) is as follows:

http://sources.redhat.com/cygwin

Enjoy your unholy marriage of M$ and *NIX. ;-) Oh, yeah. Did I mention, it's FREE ! Isn't GPL Licensed software wonderful?!

"Well, they have *a* shell under Windows 2000, with an add on product that they actually purchased from another company. The company was Interix, so now the product is Microsoft Interix 2.2. ...[snip]... While I'll admit it feels kind of dirty to use this product"

Any reason you can't use Cygwin, now owned and maintained by Redhat. From the intro page:

Using Cygwin, developers can manage heterogeneous environments in a consistent, efficient way. Cygwin brings a standard UNIX/Linux shell environment, including many of its most useful commands, to the Windows platform so IT managers can effectively deploy trained staff, and leverage existing investments in UNIX/Linux source code and shell scripts.

The tools only take up about 100 megs of space and provide you with bash, ksh, and tcsh as shells, and most of the tools you're familiar with in a GNU *NIX environment, including the compilers. They support Win 95/95/NT4.0-sp3 natively, which would lead me to believe you could get it to run on M$ Millenium without too much difficulty. But wait! We're not finished! Would you like a free Xserver for your Windoze boxen? Check this out!

A more informative site on Cygwin, it's current status, new bulletins, FAQs, etc (it's project center site) is as follows:

http://sources.redhat.com/cygwin

Enjoy your unholy marriage of M$ and *NIX. ;-) Oh, yeah. Did I mention, it's FREE ! Isn't GPL Licensed software wonderful?!

"Well, they have *a* shell under Windows 2000, with an add on product that they actually purchased from another company. The company was Interix, so now the product is Microsoft Interix 2.2. ...[snip]... While I'll admit it feels kind of dirty to use this product"

Any reason you can't use Cygwin, now owned and maintained by Redhat. From the intro page:

Using Cygwin, developers can manage heterogeneous environments in a consistent, efficient way. Cygwin brings a standard UNIX/Linux shell environment, including many of its most useful commands, to the Windows platform so IT managers can effectively deploy trained staff, and leverage existing investments in UNIX/Linux source code and shell scripts.

The tools only take up about 100 megs of space and provide you with bash, ksh, and tcsh as shells, and most of the tools you're familiar with in a GNU *NIX environment, including the compilers. They support Win 95/95/NT4.0-sp3 natively, which would lead me to believe you could get it to run on M$ Millenium without too much difficulty. But wait! We're not finished! Would you like a free Xserver for your Windoze boxen? Check this out!

A more informative site on Cygwin, it's current status, new bulletins, FAQs, etc (it's project center site) is as follows:

http://sources.redhat.com/cygwin

Enjoy your unholy marriage of M$ and *NIX. ;-) Oh, yeah. Did I mention, it's FREE ! Isn't GPL Licensed software wonderful?!

"Well, they have *a* shell under Windows 2000, with an add on product that they actually purchased from another company. The company was Interix, so now the product is Microsoft Interix 2.2. ...[snip]... While I'll admit it feels kind of dirty to use this product"

Any reason you can't use Cygwin, now owned and maintained by Redhat. From the intro page:

Using Cygwin, developers can manage heterogeneous environments in a consistent, efficient way. Cygwin brings a standard UNIX/Linux shell environment, including many of its most useful commands, to the Windows platform so IT managers can effectively deploy trained staff, and leverage existing investments in UNIX/Linux source code and shell scripts.

The tools only take up about 100 megs of space and provide you with bash, ksh, and tcsh as shells, and most of the tools you're familiar with in a GNU *NIX environment, including the compilers. They support Win 95/95/NT4.0-sp3 natively, which would lead me to believe you could get it to run on M$ Millenium without too much difficulty. But wait! We're not finished! Would you like a free Xserver for your Windoze boxen? Check this out!

A more informative site on Cygwin, it's current status, new bulletins, FAQs, etc (it's project center site) is as follows:

http://sources.redhat.com/cygwin

Enjoy your unholy marriage of M$ and *NIX. ;-) Oh, yeah. Did I mention, it's FREE ! Isn't GPL Licensed software wonderful?!

I already asked RedHat to implement that some time ago - see this Bugzilla entry

Frankly, DOS just don't cut it anymore.

- Steeltoe

Secondly, Perl has been ported to Windows. Now, you can run all the nice perl scripts and programs on Windows. Check the Perl Power Tools for another set of free standard Unix utilities that you can run on Windows.

Unfortunately the Adaptec AIC7xxx SCSI driver was REALLY broken and 6.2 won't even install

It is my understanding that some cards using the AIC7xxx chipset are really broken and 6.2 doesn't have the right workarounds (it definitely works on my home machine with an original Adaptec 2940).

Did you try the patch from http://people.redhat.com/dledford/ai c7xxx.html? A couple of people have reported that fixes the problem (use the driver at the BOTTOM of the list), so I guess it's actually resolved.

I don't have the actual hardware to verify this myself.

---

Not for now, because it's too unstable (journal format changing every couple of releases), and once you've managed to mess up a filesystem beyond what a journal replay can fix, chances are you're in trouble with reiserfs.
Once it has stabilized, we'll include it unless something better comes along before that.

For 7.0, I'll put up a kernel RPM with the ReiserFS patch on http://people.redhat.com/bero/experimen tal/ when I have the time (probably shortly after the 7.0 release) for those who want to play, but don't say I didn't warn you.

• You can choose not to install X. Seriously, just don't install the X packages. However, most newbies want to use X because it provides an environment that is similar to what they are used to.
• I don't really use Red Hat's hardware utilities, except Xconfigurator. Thus, I don't really have enough information to discuss this point.
• I would argue that Red Hat pushes the rest of the distributions forward. Yes, there were quite a few bugs that were introduced with Red Hat 6.0. However, Red Hat released bug fixes and security updates. For 6.0, there are located here; in fact, their entire support area is pretty well done. And why should a company update old versions of its distro when it has already released a new one? I think that providing RPMs for support is quite sufficient. It's not a "service pack," but RPMs are really easy to use, and gnorpm is improving. It wouldn't surprise me to see a wizard-type interface be built on top of rpmlib through gnorpm.

• You can choose not to install X. Seriously, just don't install the X packages. However, most newbies want to use X because it provides an environment that is similar to what they are used to.
• I don't really use Red Hat's hardware utilities, except Xconfigurator. Thus, I don't really have enough information to discuss this point.
• I would argue that Red Hat pushes the rest of the distributions forward. Yes, there were quite a few bugs that were introduced with Red Hat 6.0. However, Red Hat released bug fixes and security updates. For 6.0, there are located here; in fact, their entire support area is pretty well done. And why should a company update old versions of its distro when it has already released a new one? I think that providing RPMs for support is quite sufficient. It's not a "service pack," but RPMs are really easy to use, and gnorpm is improving. It wouldn't surprise me to see a wizard-type interface be built on top of rpmlib through gnorpm.

Why does there need to the start of beta? Should not all distributions be continuously in beta?

Yes. And we are. Check out Raw Hide, which is actually a snapshot of our current development work, updated every couple of days.

Our official betas are when we decide something has all the features we need in the final version, and generate ISO images to make it available to a broader group of people.

Red Hat Beta 6.0, 6.1 and Alpha 6.2 which include the newest and most unstable of all releases.

You must be using a different 6.2 than the rest of the world then...
If you have any issues with 6.2, report them - we can't fix problems we aren't aware of. Considering my web server (running 6.2) has had an uptime of 103 days before I rebooted it for a kernel upgrade, I'd hardly call it alpha-quality code.

Announcing...

Red Hat Linux "Pinstripe"
a Beta release

Red Hat. Inc. presents a beta release of Red Hat Linux for your
hacking pleasure. First, the regular drill:

This is a beta release of Red Hat Linux. It is not intended for
mission critical applications. It's not even intended for
non-mission critical applications. Important data should not be
entrusted to Pinstripe, as it may eat it and make loud belching
noises.

Significant changes have been made since the last version of Red Hat
Linux. We need your help to find and report bugs. Search for
existing bug reports for problems you find by using bugzilla at:

http://bugzilla.redhat.com/bugzilla/

Attach patches if you're motivated!

This beta includes so much cutting edge software, the binary packages
come on two iso images. The installation program now handles reading
packages from multiple CDs.

* Where can I get this release?

Pinstripe can be downloaded from our public FTP site at:

ftp://ftp.redhat.com/pub/redhat/beta/pinstripe

With the support of volunteers ftp site administrators, Pinstripe is
available from several mirrors. The following have complete copies of
Pinstripe, please use a mirror close to you:

North Carolina, USA:
ftp://metalab.unc.edu/pub/Linux/distributions/redh at/beta/pinstripe/
http://metalab.unc.edu/pub/Linux/distributions/red hat/beta/pinstripe/

California, USA:
ftp://ftp.sourceforge.net/pub/mirrors/redhat/redha t/beta/pinstripe/
http://ftp.sourceforge.net/pub/mirrors/redhat/redh at/beta/pinstripe/

California, USA:
ftp://ftp.kernel.org/pub/mirrors/redhat/redhat/bet a/pinstripe/
http://www.kernel.org/pub/mirrors/redhat/redhat/be ta/pinstripe/

Connecticut, USA:
ftp://ftp.uselinux.org/pub/redhat/beta/pinstripe/

Indiana, USA:
ftp://csociety-ftp.ecn.purdue.edu/pub/redhat/beta/ pinstripe/
http://csociety-ftp.ecn.purdue.edu/pub/redhat/beta /pinstripe/

Michigan, USA:
ftp://mrhankey.bizserve.com/pub/linux/redhat/ftp.r edhat.com/redhat/beta/pinstripe/

New York, USA:
ftp://ftp.ee.cornell.edu/pub/linux/redhat/beta/pin stripe

Pennsylvania, USA:
ftp://carroll.cac.psu.edu/pub/linux/distributions/ redhat/redhat/beta/pinstripe/

Pennsylvania, USA:
ftp://cronus.res.cmu.edu/pub/linux/ftp.redhat.com/ beta/pinstripe/

Tennessee, USA:
ftp://sunsite.utk.edu/pub/linux/redhat/redhat/beta /pinstripe/
http://sunsite.utk.edu/ftp/pub/linux/redhat/redhat /beta/pinstripe/

Australia:
ftp://mirror.aarnet.edu.au/pub/redhat/beta/pinstri pe/
http://mirror.aarnet.edu.au/pub/redhat/beta/pinstr ipe/

Germany:
ftp://ftp.gmd.de/mirrors/redhat.com/redhat/beta/pi nstripe/

Germany:
ftp://ftp.uni-bayreuth.de/pub/linux/redhat/beta/pi nstripe/
http://ftp.uni-bayreuth.de/pub/linux/redhat/beta/p instripe/

Norway:
(ISO images only)
ftp://carroll.cac.psu.edu/pub/linux/distributions/ redhat/redhat/beta/pinstripe/

Peru:
ftp://sajino.terra.com.pe/pub/linux/redhat/beta/pi nstripe/

Japan:
ftp://ftp.kddlabs.co.jp/Linux/packages/RedHat/redh at/beta/pinstripe/

* What's new in this beta?

General system improvements:
o FHS compliant packaging of files
/usr/man is now /usr/share/man
/usr/doc is now /usr/share/doc
/usr/info is now /usr/share/info
See http://www.pathname.com/fhs/ for more information

o Document roots for Apache and anonymous FTP are removed from
/home so it may be automounted.

o Packages with services are automatically restarted on live
upgrades

o Expanded LDAP integration

o Expanded Kerberos integration

Core system components:
o glibc 2.1.91
o XFree86 4.0.1, XFree86 4.0.1 runtime environment
o XFree86 3.3.6 X servers included for maximum hardware compatibility
o GNOME 1.2
o kernel 2.2.16
o GCC 2.96

Expanded hardware support:
o Basic USB support (mouse and keyboards)
o Expanded hardware accelerated 3-D support

System service changes:
o inetd replaced by xinetd
o BSD lpr replaced by LPRng

A sampling of package upgrades:
o GIMP 1.1.24
o Perl 5.6.0
o Tcl/Tk 8.3.1

A sampling of Package additions:
o SDL, smpeg
o SANE
o gphoto
o MySQL
o AbiWord
o dia
o ispell has been replaced by aspell
o XEmacs

Next generation development library previews included:
o pango: Unicode font rendering
See http://www.pango.org/
o Inti: C++ foundation libraries including GTK+ GUI toolkit classes
See http://sources.redhat.com/inti/

Enjoy!

The OS Development Team
Red Hat, Inc.

1. Amazon, for taking out absurd patents
2. Unisys, for enforcing the GIF compression patent
3. MPAA member studios, for bringing charges in the DeCSS matter

At least slashdot has quit linking to Amazon in their book reviews. But they stif use GIFs, as do Red Hat, VA Linux, and even GNOME. The MPAA boycott is a complete joke. The latest spawn of the many-tentacled corporate movie industry was much hyped through out the geek community.

So I'm not expecting much out of this boycott. Sure, a few of us will give up corporate movies and music, but the majority will keep right on eating up all the pop music, movies, and television they can ge their hands on.

For those of you with a backbone, go to independent films, attend live concerts, sell your DVD player, and turn off the TV

IIRC, bonnie uses the stock getc() and putc(), which under Linux are threadsafe. These functions acquire a lock in userspace, and so have more overhead than is necessary for a single-threaded application. As Doug Ledford explains on this page, bonnie performs much more realistically when modified to use the non-threadsafe versions (which is a valid thing to do in a single-threaded application).

In case you're interested in eCos, here's the homepage URL (forget to include it above):
http://sources.redhat.com/ecos/

-- Bryan "TheBS" Smith

[ Note: I was a Software Engineer at Coleman Aerospace for 3 years ]

Many of the early computers in ballistic missiles and space probes borrowed heavily from the military. Much of the gyros and computing systems were produced by Bendix for the Department of Energy (according to various public documents from about a year ago, Bendix development is still located at the DoE's Kansas City Plant). In case you aren't familiar with how the government works, the DoE was and still is the non-military, government agency tasked with the creation of numerous components of our nuclear arms technology (as well as their normal energy details, a natural tandem role). Looking at their "most advanced computer" in the early 1980s (the Bendix 930 in the Pershing II MRBM), you essentially had a 16-bit CPU and database with 64KB of memory on various cards in a wire-wrapped backplane. And, yes, all the target code for these machines are done in assembler.

Today, both the military and NASA contractors "better, faster, cheaper" attitude of using off-the-shelf hardware, tools and software revolves mainly around the VME architecture (usually for 68300 and, increasingly, PowerPC boards -- military spec/hardening) with WindRiver's VxWorks RTOS. VxWorks is heavily BSD 4.3-based OS with response times in the tens of microseconds (on a 40-50MHz processor). Development is done using GNU development tools using a customized Cygnus GNUPro (now under RedHat's services group) product called Tornado (customized for WindRiver by Cygnus) so it can target various VxWorks architectures with Linux, Solaris and Windows being the most popular host development platforms. [ I personally found Windows to be a real pain if you also install Visual Studio on the same system because which tries to take over your system -- have to be careful you run the right make, etc... binary ].

A well-known 68K/VxWorks-based mission was the Mars Pathfinder. Today, the combo is used in a wide variety of launch and space vehicles. At my former employer, we used it for our ballistic target and booster vehicles for the military and LEO (low earth orbit) launch vehicles for NASA (and they continue to do so). A future mission to the outer planets will be PPC/VxWorks-based, all written with the GNU development system. [ Since Linux nor most other general-purpose OSes cannot guarantee such "hard" real-time response times (let alone no Windows platform can seem to deliver even deliver any "soft" real-times either), it is my hope that Cygnus' (now RedHat's) eCos takes off and cuts into VxWorks' market in the next 5 years). ]

Which brings me to my final point: I think people get caught up with the whole this OS versus that OS issue when the argument should be GNU development versus Microsoft Visual development for "mission critical" purposes. The GNU cross-compilers and tools allow you to target dozens of platforms and massive code reuse whereas Microsoft changes its Visual Studio products on a whim. I mean, it's really harder to port Windows code just for a version change than it is to port to another, completely different architecture with GNU. I personally don't see why Windows developers put up with it because Cygnus makes some damn good IDE and tools for development.

Personally, I think the best remedy for the whole DOJ v. Microsoft trial would be to force Microsoft to support GNU-based development tools for the Windows platform (both target and host) -- and set a time-frame in which they would have to drop their current, non-GNU-based Visual product (e.g., 5 years). This would do several things: actually force the documentation of the API, thus increase overall stability of the Windows platform, finally address multi-user ignorance as the main problem with Windows security (98% of even Microsoft's own applications are multi-user ignorant!), and many, many other benefits to the developers as well as the consumer. Of course no one in the trial has the forsight to see this as the best remedy, and I seriously doubt we will see any discussion of it either.

-- Bryan "TheBS" Smith

<shameless plug>
I'm in the process of setting up on-line ordering on my website right now. Most of the website is technical resources for building electronic projects using embedded processors. A recent addition, that we expect to need the on-line ordering for, is the open source MP3 player, which today is a primitive first generation design, but hopefully soon I'll have a nicely redesigned version.
</shameless plug>

Fortunately, my partner is an accountant, which has really helped. She set up a proper visa merchant account with our bank. It cost $100 up front. They take $0.65 per sale, plus approx 3%. There's a minimum $15 monthly charge, so hopefully we'll actually sell at least $500/month. The visa charges are entered using a touch-tone phone, so we didn't have to buy any equipment. They offer a terminal, for (I think) $450. With the terminal, we would get a per-sale charge of $0.07, and a little lower percentage of the sale, about 2.5% as I recall. They let you buy and add the terminal anytime you want.

It looks like there's a free software package called CCVS - Credit Card Verification System which allows your linux (or unix) box to emulate a terminal (requires a dedicated modem)... but there's a catch. It needs to be loaded with an encryption key. Redhat sells these keys for approx $1000. If anyone knows someone who can provide a key for CCVS for less, please contact me. Robin found a similar windoze based program, where they wanted a monthly charge and some percentage of the sale, on top of the percentage taken by the bank! Not cool, but I wouldn't run a windows server even if it was affordable.

Setting up the SSL stuff on the webserver is relatively easy, but you need a cert. VeriSign charges $350, so we went with Thawte, who only wanted $125 (even though they're now owned by Verisign). Again, robin did most of the work there. I generated the CSR from the server software, and she faxed them copies of our LLC papers and other business stuff. About a week later we got the cert. The cert lasts for only one year, you it looks like we have to pay $125 every year. I hope they don't jack their price up to Verisign's level!

Robin ran a test charge onto her credit card a couple days ago, and it seems to be working very nicely. The merchant appears as "PJRC.COM, LLC", which I think is much cooler than "ibill...some number".

For the on-line shopping cart, I looked at a couple of them, but they didn't have that look and feel that I want for my website, so I've been rolling my own. It's turned out to be a bit more coding than I originally thought, but still not too bad, and I'm really happy with the results. When the order is confirmed, the code just sends Robin and I an email, and makes sure the data stored in our database really matches what they filled out on the form.

I'm putting the final finishing touches on the cgi scripts right now, and hopefully it'll be on-line later tonight!

I think that Red Hat Kickstart is exactly that. It lets you script the answers to all the questions and choices in the installer and perform a fully automated install. Basically, you put the script on a boot diskette and put the cdrom in the cd drive and off you go...

I think you will find more embedded systems devoplers going to X because is allow them to remotly display debugging back to the desktop.

microwindows has a client / server network transparent architecture, similar to X. it's a heck of a lot smaller than X, too.

there is also RTEMS, which is a real-time multiprocessor-supporting OS, if you ever want to ditch vxworks... (there is also ecos which looks interesting. but this is getting off topic.)

OpenSSH runs great on my Red Hat boxen. The source and executable .rpms are downloadable .

FiSSH is being turned over to MIT, and as soon as they unscramble their (currently hosed) distribution and apply the known patch for Win98 compatibility (thot Win95/98 ran the same apps? think again) there will be a freely available SSH client for Winblows lamers, um, I meant mainstream users, built from True Free Open Source! Yay!

TeraTerm SSH is another Win32 client, but not really open source, because Teranishi-san has disappeared and the license is oddly written, but it does work for most purposes.

For file transfer, don't use FTP, use rsync.

> Shall we start the old rumor that RedHat 7 will have XFree86-4, kernel 2.4, KDE 2.0 and Gnome 1.2 again?

Some of that has already made it into Red Hat's "Rawhide" release, which is a sort of beta for their forthcoming versions. They put a new one out at rawhide.redhat.com about once a month.

ps - No, it's not slashdotted. It's just a seriously overloaded server. Try it at an off hour if you want to sneak a peak or download it.

--

Here's that URL again:
http://bugzilla.redhat.co m/bugzilla/show_bug.cgi?id=12310

Make sure that Redhat doesn't let this one drop!

What's next, Linux Certification? Linux Certified Engineers?

Actually, RedHat has a Certification Program.

Latin american Conectiva has its own, also. I know one of their certified engineers.

(No, I dont work for them, I just happen to use their distribution.)

Doesn't Dell own stock in RedHat??

Just curious... Would Dell be forming alliances and other things if they weren't interested in making RedHat look good??

Dell And RedHat Alliance
Yet Another Dell/RedHat Alliance

I'm not trying to start a flame war, just trying to see if other people see connections... This is yet another example of why benchmarks suck!!

My .2c
The "Top 10" Reasons to procrastinate: