User: BitMan

An Open Letter To RedHat ...

On: High Octane Hardware For GIMP Use?

Felt this was appropriate given the posts here on RedHat 7.0 (since /. rejected it as a feature previously -- hence why it is reposted here).

An open letter to RedHat ... (2000 Dec 17)

OVERVIEW:

• Introduction
• The Most Trusted Distribution Release Model
• Version Marketing v. Neurotic Upgrading
• RedHat 7: Why They Did That
• RedHat 7.0: The Worst Dot-Zero Yet
• Not Just the Waiting Game
• RedHat Dot-Zero: Have the Rules Changed?
• Just Say No To YARBD
• Accommodate With Marketing?
• Legal

INTRODUCTION

As the system administrator at a well-known semiconductor design firm for the past year and a half, my current employment includes a heavy dose of primarily Linux-based services and numerous workstations in a production engineering environment. This will eventually turn into a completely Linux-centric model with it replacing both the traditionally NT engineering desktop and the Sun workstation in the computing farm or remote X-application server; a direct result of most electronic design automation (EDA) software vendors releasing all ports of their software to the cost-effective Lintel platform (of which, may already exist and are in use on the desktops of my firm).

Yet another sysadmin in the crowd, known fondly as "TheBS" to some. An avid user of GNU/Linux/OSS solutions since 1993, the past five years have involved production utilization at various traditional engineering firms. From Samba for file services back when people were debating NetWare v. NT (and how they could bridge them to each other, let alone UNIX), to introducing Linux supercomputing clusters at aerospace firms who could not afford SGI or Sun-based solutions (of which I still do on a consulting basis), Linux is an extremely potent OS for traditional engineering environments.

For these past five years, I have been totally RedHat distribution-centric. As such, this letter will commence with a bit of praise.

THE MOST TRUSTED DISTRIBUTION RELEASE MODEL

I have tried numerous RPM-based distributions over these same five years, after discovering RedHat in late 1994. Although people have obvious feelings for various distributions (usually with some disgust of RedHat in minor or major form), and many articles and reviews focus on the install, GUI configuration and "ease-of-use," there is a simple and basic software engineering law that keeps me set with RedHat. And that very important law involves the very careful attention to the release model and versioning of their products.

Unlike Caldera, Mandrake and many other RPM-based distros, any release revision of almost any arbitary major RedHat version will tell me: **

• C Library version
• GNU toolchain version
• Kernel (or kernel headers) version

For the greater part, binary compatibility is easily achieved on this major version (e.g., 5, 6 and now 7). The same goes for headers, source and the like. I can upgrade from the .0 or .1 revision to the .2 revision in a version without major worry of incompatibilities. Furthermore, these upgrades can be made piecemeal with the simple command-line interface (CLI) RPM utility on-the-fly with little or no downtime, no major issues. No other [RPM] distribution that I know of maintains this simple, but quite rudimentary release model that gives sysadmins comfort in upgrading.

This same model also gives me a reference point for major version maturity. A RedHat .0 revision is obviously a distribution that does the following:

• Introduces library issues
• Introduces build/development issues
• Introduces less mature/tested packages

As such, RedHat .0 revision releases should be avoided for production systems. RedHat, in fact, went out of their way to announce version 7.0 as an "experimental release," which was also echoed on most Linux enthusiast hangouts like /. Unfortunately, I seriously doubt that same statement was echoed on the RedHat 7.0 box at my local CompUSA.

VERSION MARKETING v. NEUROTIC UPGRADING

Before I can start addresses RedHat's 7.0 release in greater detail, I first have to do a final round of education. A common end-user issue seems to plague many and causes the most troubles. Although vendor "version marketing" is annoying, the root problem with software adoption is what I like to call "neurotic upgrading." Although it may be commonplace when using vendor products that limit choice, users should be responsible enough to avoid this, if they can, in an software industry of so much GNU/Linux/OSS choice.

Most users, at least most enthusiasts, are neurotic upgraders, often failing to read simple READMEs or properly evaluating a new release of software before installation. Furthermore, they fail to listen to the comments of their peers, either dismissing them as not applicable to them or, more arrogantly, from less capable users. Quite ironically, many users sometimes do not even realize that despite their efforts to do so that they have not, in fact, actually acquired the latest version of the software. [ And this is common in the case of computer hardware as well ]

Most of all, I want to dispel any misconceptions before I start about RedHat 7.0 being the result of "version marketing," as it is not. The best example I can think of regarding "version marketing" was Mandrake's jump from version 6.1 to 7.0, just because of DrakX about a year ago. I was quite relieved when RedHat released 6.2 a few months later, instead of trying to play Mandrake's continuing game. RedHat waited to release 7.0 some time well after, when changes were approprite, although we will discussion whether or not that was long enough.

REDHAT 7: WHY THEY DID THAT

Applying the elementary list of three key components of any RedHat release, version 7 is built upon:

• GLibC 2.2
  (to GLibC 2.1 in v6, 2.0 in v5, LibC 5 in v4, LibC 4 in v3?)
• GCC 3 toolchain
  (to EGCS/GCC 1.1.2/2.9 in v6, GCC 2.7 in v5/4)
• Kernel 2.4
  (to kernel 2.2 in v6, 2.0 in v5/4)

Of these, GLibC 2.2 was near-release when RH70 hit in late August (2.2 released in October). GCC 2.96 is much more in-line with the API with GCC 3 than 2.95 was (much more so). And kernel 2.4 was in test release, with the headers and other key structures well defined.

After six months without a new release, I am sure RedHat was obviously itching to get a new distribution out the door with newer components like XFree86 4.0, a kernel with USB support and more of the like. Whether or not RedHat rushed out version 7 to meet competitors who already had these components, is a matter of discussion, let alone speculation. But there is no doubt that there were obviously some bad judgments made.

REDHAT 7.0: THE WORST DOT-ZERO YET

To itemize the specifics:

• GLibC 2.1.92
• GCC 2.96 (as of September)
• Including GCC 2.95.2 for kernel compiles
• Ripping other, non-release quality components from CVS trees

First off, the core of any RedHat major release is LibC, without any doubt since even RedHat version 3 (LibC 4 I believe). This library needs to be stable and release quality. Unfortunately, both 2.1.92, and the subsequent 2.1.94, release had numerous bugs and issues. Furthermore, the release of the completed 2.2 version was only about a month and a half away from 7.0's release (and even then RedHat took over a month to get it out, although that looks like it might have been due to the Alpha port holding it up?). I expect to see unstable pre-releases of core components out of Rawhide (RedHat's latest and greatest package archive), or even a beta, but not a boxed release.

Now I know most people are questioning the inclusion of GCC 2.96 and the API switch towards GCC 3 away from EGCS 1.1.2 (which subsequently became GCC 2.91 and refined to 2.95) used by RedHat/Rawhide releases (among other, current distros). That is the wrong view to have IMHO. In fact, RedHat is on the money, again IMHO, on moving to GCC 2.96 as the forthcoming GCC 3 release is going to force source code changes anyway (everyone complained when RedHat started to use EGCS 1.1.2 as well, let alone GLibC 2.0).

The main problem with GCC 2.96 was the fact that, as of September, it was way too new to include in a production release. In fact [and I may not be remembering correctly], I believe GCC 2.96 was so new that RedHat included GCC 2.95.2 in the Pinstripe RedHat 6.9 (7.0 beta) release. Many in RedHat's own Cygnus division (who is highly respected by anyone who has used their software in mission critical spacecraft and military hardware, like NASA let alone myself at my previous employer), voiced concerns on this switch. I know RedHat was rightly gung-ho to push towards GCC 3 with 2.96 in RedHat 7.0, but far from stable was GCC 2.96 at the time of its release.

And the true testament to this was RedHat's inclusion of GCC 2.95.2 disguised as "kgcc" in the release. If RedHat wished to push to a new compiler, they should have readied kernel headers and code for it. Instead, the world has been left with a new level of mass confusion regarding kernel and driver compilation, among the normally semi-understandable nags of new 2.4 headers and includes (i.e. thanks for complicating things much more then you had to RedHat). If RedHat was serious about the quality of GCC 2.96, they should have gotten the kernel to compile with it. [ Although this is nothing new, I believe the same issue arose with EGCS' inclusion in an much older version .0 or .2 revision? ]

Lastly, GLibC 2.1.92 and GCC 2.96 were not the only CVS trees ransacked, but a few, other projects' CVS trees were pillaged. While some components, like pre-release KDE 2, were tucked safely away in a non-installation directory, others were not (including installing the Qt 2.2 beta by default).

NOT JUST THE WAITING GAME

Now one could easily argue about waiting on a release for components to mature until we were all blue in the face. Understand one always, at some point, has to put their foot down and release.

But it is quite obvious to me that RedHat failed to keep its core component at release quality for a .0 revision. Namely RedHat broke its unwritten rule of always releasing a .0 revision release with a release quality C library. By waiting another month and a half on the 7.0 release, RedHat could have not only had a release quality GLibC, but GCC 2.96 would have almost exponentially matured, a better 2.4.0 test release existed, let alone KDE 2 and KOffice were out! [ NOTE: I actually am a Gnome-bigot ]

Now one might say hind-sight is 20/20. But the focus is on the release quality of GLibC 2.1.92 and GCC 2.96 at the end of August, when RedHat 7.0 was released. I am still shocked to see the release of a full RedHat version with such experimental components at the core.

REDHAT DOT-ZERO: HAVE THE RULES CHANGED?

The FreeBSD gurus among us are probably sneering now at my comments on a .0 revision. Okay, they are probably sneering at so much discussion about a Linux release regardless. But in all seriousness, the FreeBSD world regards the .0 revision as obviously a non-production release. And those same FreeBSD'ers have universal, strict tagging system of -CURRENT, -STABLE, -RELEASE to keep one in-line as well. As such, the FreeBSD .0 revision is a perfect time to take new components, get them integrated and say "hey, this is where we are heading, it works for us, now try it out."

So my question is, after seeing the RedHat 7.0 release take form, whether or not this is where RedHat 7.0 is moving (regardless of whether they want to or not)? It may be, in fact, a fine move as seems to work quite fine for the FreeBSD folk. But RedHat 7.0 was obviously not a typical RedHat .0 revision by any means, and the rules have now, if only temporarily, changed.

If so, RedHat is going to have to realize that there is more to the FreeBSD release model than just how to approach .0 revisions or a set of known tags for their prereleases (like Rawhide). So far, RedHat has maintained a single path of releases, moving onto release 6 when 6.0 was released, and now seven, since 7.0 has been released. Now sure, there are some updates for older releases, but it still seems that much support for a previous product is dropped when a new major version is released.

With FreeBSD, and most GNU/Linux/OSS projects, there are multiple versions in development at the same time. These are called branches (and a project without a second version is said to have a single branch). For example, FreeBSD released 4.0-RELEASE in March, 3.5-RELEASE in June and 5.0-CURRENT branch has been in the CVS tree since after the FreeBSD (c/o Walnut Creek) and BSDi merge (not to mention the current 4.2-RELEASE and the 4.3-CURRENT branch).

[ NOTE: Please do not comment that a branch is the same things as a fork. Non-developers will take this as the newfound negative meaning of fork, and not the use of it in this example/proposal. ]

So maybe it is time RedHat looks at doing something similar?

JUST SAY NO TO YARBD

What I'm driving at here is the avoidance of YARBD: Yet Another RedHat-Based Distro. With both RedHat 5.2, and now 6.2, I have maintained my own network installation server for the latest .2 release with tons of patches, updates, independent updates, mix-ins of custom kernels, 3rd party packages (that may be standard in the latest .0), etc... Now I do not expect RedHat to continually release new revisions every time a patch is released, but going almost nine months on a .2 release with outdated components is a nightmare to use on production workstations and servers.

[ Side request: RedHat, please, please including all run-time compatibility libraries for all previous versions in your releases. Keeping only one major version back is not enough. You do not have to keep the entire compatibility libraries for development, just for binaries that need the run-time libraries. I know I can get them from the previous distribution version, but it is not only a pain, but can be confusing for the newbie. At a minimum, could you at least include them on the Powertools CD? Thank you. ]

Furthermore, I could easily see RedHat releasing a fourth version 6 revision, just like I thought they should have with version 5. Now I know this is not status-quo for RedHat, and not what most people are looking for. But RedHat had an updated Rawhide kernel, 2.2.16-8 with USB, I2C, AGP, and various chipset functionality, etc... support about three months after RedHat 6.2's release (yet 2.2.16-3 is what they have in the 6.2 upgrade folder). In addition, they could of released XFree86 4.0 for GLibC 2.1.3, instead of pushing everyone to 2.1.9 well before it was ready.

Finally, I submit what every production UNIX sysadmin wants: Journaling and stable NFS support (for us UNIX-to-UNIX network admins). Since June, I have been running with both Ext3 and NFS3 on my main file and applications servers (to Linux and Solaris clients) with great success. Much of this comes with thanks to H. J. Lu at VALinux (who creates kernels from VA's tarball in RedHat's RPM set layout, plus adds a number of goodies), among several other, required packages. If RedHat was serious about a production revision, at least for servers, I submit they should have seriously considered adopting the NFS3 kernel backport (from 2.4) in their kernels (starting with 2.2.14) as well as possibly opening up Ext3 as a filesystem option. And it was quite humorous to find out RedHat even left these out of the "experimental" (in their words) 7.0 release.

[ Technical Note: Ext3 is currently the only option for a journaling filesystem with the newer NFS server code on kernel 2.2. ReiserFS runs into a performance race condition. ]

Packages and services like these, I believe, warrant a .3 revision, especially if it is released at the same time at the next version's .0 revision. This expands the choices for the consumer, so one is rrunning a distribution with drivers and services some nine months old, or force to go to an experimental release just to get them. Ala RedHat 7.0.

Otherwise, sysadmins like myself with production systems maintain their own "Dot Three" distro. And as much as I would like to share my repository of RPM selection with everyone around the world, understand I do not have time to be a YARBD vendor and support them. RedHat should consider releasing a .3 revision at the same time they release a .0 revision of the next version.

ACCOMMODATE WITH MARKETING?

Which brings me to a final point, there is a good marketing spin on a .3 revision released at the same time as a new .0. Taking a marketing lesson from Microsoft (yes Microsoft), not a technical one, but a marketing one, RedHat could use this to their advantage.

Whenever I see a user go to my local CompUSA to talk about buying a new computer, or just an OS upgrade, I always hear something of the sort (in recent times), "Should I run Windows 98 or Windows 2000?"

Worse yet is the fact that I actually stick around to hear the $8/hour CompUSA technician (if half-way competent) explain how "Windows 98 is a consumer PC operating system and Windows 2000 is a workstation/server operating system." This is something that, quite routinely, causes me to break out into a virtual, western-style. quick draw where I shoot both the user and the sale rep squarely in the forehead to put a pair of no-good, brainwashed intelligence to their quick and painless death where they can do no further harm.

My Linux does both and I am better off running just that single, powerful OS. But neither of them know that.

Now the point I am making is that Microsoft is not out their arguing whether or not Windows is better than Linux for the consumer, or (God help them) workstation/server, but they are selling the two-sided story as, "one needs either this product or this product." Both are, of course, conveniently owned and sold by them, hence really a one-sided argument, just with two choices (instead of sides). Sure, Microsoft is starting to play a [losing] game by arguing against Linux in the corporate front, but one does not seen much of that going on in the consumer arena.

So if we want to get the word out to "neurotic upgrading" users, while promoting GNU/Linux/OSS at the same time, maybe we should take Microsoft out of the comparison as well. Maybe RedHat should create an adverstisement display such as "What Linux version is right for me? 6.3 (or even 6.2 for now) or 7.0?" We educate users about the RedHat release model. We save them from themselves. We act like Microsoft does not exist. We sell (or make) more GNU/Linux/OSS powered systems.

Okay, okay, maybe I am stretching this all a bit, trying to add some sort of "new, revolutionary perspective" at the end of a commentary. I mean, do not worry ESR, I do not see me quitting my day job to become a world class Linux advocate. So maybe it is because it is around 8am EST and I have chosen to spend my Saturday night / Sunday morning babbling endlessly about RedHat 7.0. Either way, I hope I shed some light on the RedHat release model, what works (and has worked) and what does not (and has seemingly taken a major wrong turn IMHO).

Until this happens, 'Fester (my installation box, as in "InstalFest'er") is going to be active for as long as RedHat has .0 revisions lag six months after a .2 revision. And who knows, maybe "VaporWare Labs"(TM) might give RedHat some competition with its "Dot Three Linux" release for those companies who need that extra revision release.

[ NOTE: Anyone who knows me knows I am the king of VaporWare(TM) ]

Bryan "TheBS" Smith
RedHat Bigot(TM)

LEGAL

You are free to repost, retransmit or reprint the above commentary provided that you include an entire copy of the message (including this LEGAL section), proper reference and clear indication of the author at the beginning of a thread, page or view. You may respond, analyze, make fun of, or otherwise trash this commentary in any way you see fit, including inserting any aforementioned types of commentary, jokes and puns in between portions of the original post, as long as their is some clearly defined way to separate additions from the original as posted above. In the spirit of sharing, giving, flaming and overall end-user abuse, I leave the implementation of all this to you in the hope that you will do it no grave injustice.

In no written or unwritten way, shape or form do the opinions, views, comments or self-hypocricy reflect, project or reform those of my employer, associates, family, relatives, society (well maybe society), etc... All statements are original unless otherwise noted. If you even try to blame someone other than myself, I will personally take issue to the point with the offender to the point of UT deathmatch.

All rights reserved to the Free Software Foundation.

Seriously now, I hate lawyers and see no business for them here. But I do have a day job and everyone should fully comprehend my employer plays no part in nor sanctions anything written above.

-- Bryan "TheBS" Smith

Fairly good article, 2 corrections

On: Very Non-Biased FreeBSD Review

Linux does have flags like immutable. I'm running Ext3 and you should always use chattr +i journal.dat to make the journal immutable. Other attributes are on enabled via various patches -- including a nice compression flag for NTFS-like on-the-fly compression.

Secondly, some people prefer System V init. I do. It is a matter of choice whether or not it is confusing. Again, I like it so this may be the only section where the author was biased.

Other than that, I agree that Ext2 has some issues. Ext3 addresses most, including some more recent LFS (large file size) patches that give you >2GB support, including for NFS services. But I'd rather have UFS with softupdates at this juncture.

-- Bryan "TheBS" Smith

SCSI *IS* cheap! Even by your "analsys" ...

On: Using USB Hard Drives For Disk Images?

First off, I think you've made a number of incorrect assumptions. My views are based on years of corporate experience, including PC rollouts. Please read my responses below. Understand that I am the only person who gave you an useable, DOS/real-mode solution. And it's not as expense as you think.

SCSI is not that cheap! Perhaps for a home system, but my company is betting it's business on the systems that we buy. That means quality, reliability, and driver issues are a big deal to us.

So are mine! You think I've been fired for buying SCSI all these years? More $$$ does NOT equal quality. I go through specific products below ... (and note that NONE say "Adaptec" -- been burnt by their crap too many times).

Each change in a driver results in a different build of the OS image. If we use a no-name SCSI card, each time the support chipset changes we need to build a new image. This is very expensive for us to maintain.

All of the cards I use have quite stable drivers. Of course when you buy something new, you shouldn't expect it to work. You should always wait ~6 months for the bugs to clear out. But when if you'd waited 5 years for good Adaptec Linux drivers, then you'd get quite irritated.

You can easily standardize on one SCSI chipset, the TekRam TRM-S1040:

• Low-cost end-user boards, TekRam DC-3x5U/UW series:
  • $15-20 UltraSCSI TekRam DC-315U for internal/external SCSI peripherials (no BIOS) -- This is probably all you need!. Much faster, cheaper, better and more compatible than Adaptec's AIC-7850-powered 2906
  • ~$40 UltraSCSI TekRam DC-395U for booting devices (BIOS) -- cheaper and better than Adaptec's AIC-7880-powered 2930 IMHO
  • ~$60 UltraWide TekRam DC-395UW for 40MBps Wide devices (BIOS)
• Single driver for all boards in series
• Excellent, direct vendor cross-OS support, DOS, 9x, NT/2000, Linux, *BSD, Solaris, SCO, NetWare, BeOS -- including full boot disks for just about any flavor. Check them all out -- especially Linux, *BSD or BeOS users, never seen such support!
• Although the chipset is just over one year old, I have seen 0 issues with drivers since March of 2000.

We cannot afford to put a Zip, Jaz, CD-R/RW and DVD-RAM/RW drive on every PC in my office. Instead, we have one or more external ones and put a $15-20 TekRam DC-315U in each system. Works great! Also great for cloning when I don't want to hit my server/network too hard (in the middle of the day), let alone transfer loads of data between systems. In Linux, I can even load/unload the TekRam S1040 driver on-the-fly, flipping drives on/off various systems without a reboot/shutdown. It's _awesome_ bay-bee!

As far as other experiences, I recently had to chuck my Adaptec AHA-2940UW (AIC-7880) in my Linux server because it is a POS (in 6 years of using Adaptec on Linux, I have yet to have a good experience thanx to their non-direct support). The sucker refused to work properly with a new, $4,000 Exabyte Mammoth2 60/150GB tape drive (talk about "betting my company's business" on a SCSI card!). I replaced it with an $60 Advansys (now owned by ConnectCom) chipset-based card:

• $60 UltraWide SIIG AP-40 Pro -- also readily available at your local computer/electronics store (although you'll pay about $99 retail).
• Advansys is known for their excellent direct driver development, and broad OS support (first vendor to officially support Linux -- way back in 1995)
• Has full per-device configuration in BIOS, just like Adaptec (i.e. Ctrl-A at boot). Works much better and more compatible with more devices than Adaptec IMHO!

But if you need faster still, Symbios Logic (now owned by LSI Logic) is always faster and more ubiquious than Adaptec. So much so that Adaptec attempted to buy Symbios out (since they were kicking Adaptec's butt in the OEM and FibreChannel market). You'll be interested in the popular 53c895/1010-series:

• Mid-cost, end-user boards in the TekRam DC-390U2 series -- 53c895 Ultra2/LVD (aka Ultra80) chipset:
  • $100 TekRam DC-390U2B for single channel Ultra80/LVD (or UltraWide) channel
  • $130 TekRam DC-390U2W for single channel Ultra80/LVD and isolated UltraWide bus
• Dual-channel, 32/64-bit PCI end-user boards in the TekRam DC-390U3 series -- 53c1010 Ultra160/LVD chipset:
  • $175 TekRam DC-390U2W for single channel Ultra160/LVD (or UltraWide) plus single channel UltraWide legacy
  • $235 TekRam DC-390U2D for dual-channel Ultra160/LVD (or UltraWide)
• Symbios Logic 53c8xx-series supported natively in just about every OS -- many chipset are upward compatible (with exception of 53c1010 that requires a new driver -- but still better than Adaptec's cards, especially their newer ones)
• Better than Adaptec performance at any chipset/protocol (usually by an average of 5-10%)
• Widely supported, numerous OEMs, >10 year-old 8xx-series design/support
• The best damn cabling/converter bundle I've ever seen in a kit (boy is Adaptec stingy!)

And when it comes to hardware RAID, Adaptec is just NT/Netware-only. As such, I prefer DPT or, better yet, StrongArm ASIC-powered Mylex RAID controllers with broad OS support (and better performance too).

So what brand are you blindly putting your faith in? Eh?

SCSI hard disks are much more expensive than IDE. I just checked pricewatch, and a roughly equivalent SCSI drive was around $200 more than it's EIDE counterpart (36GB)

And those IDE drives can be put in a $20-40 enclosure and made to work at 20MBps+, right? Not! When it comes to external (isn't that what we are talking about, eh?), IDE is a joke -- with slow as molassas USB (even in 12Mbps/1.5MBps "fast" mode) being the only option (although new ATAPI-to-FireWire bridges, like this Ultra33 one from Intito, is changing that -- although it requires OEM firmware/programming). Plus we're back to the DOS/real-mode issue (even for FireWire). Only SCSI is "ready-to-go" external.

Now you can compare GB/$ all you want. You do NOT need the latest SCSI drives. Go with a late-model 9-18GB SCSI drive. I mean, how much storage do you need? We're only talking $100-200 for the drive, another $20-40 for the enclosure and another $10-30 for cabling and termination, max. You could do it for under $150, including cables and termination, if you pinch your pennies (and buy your stuff mail-order -- use Cyberguys for SCSI cables/terminators). Plus, you must be looking at 7,200-10,000rpm RPM drives -- don't make the mistake of comparing 5,400rpm IDE drives to obviously much faster SCSI drives.

-- Bryan "TheBS" Smith

ATA drives in Firewire are usually 33MBps

On: Using USB Hard Drives For Disk Images?

FYI, I seriously doubt you get Ultra100 on a 100-400Mbps (12.5-50MBps) Firewire interface. In fact, all the ATA to 1394 bridge controllers I've seen are Ultra33 (33MBps -- like this one).

Most IDE/SCSI drives burst transfer at 15-30MBps from platter to interface. The 12Mbps (1.5MBps) interface of "fast mode" USB is a major bottleneck.

Worse yet is the massive overhead (much worse than SCSI or Firewire). USB is one of the worse serial busses ever created. There were better alternatives but Intel and Microsoft designed USB so most of the effort fell on the device and drivers (the controller and OS support is minimal). Why do you think the devices lacked the basic southbridge/OS support by 2-3 years???

-- Bryan "TheBS" Smith

OFF-TOPIC?!?!?! Just how much ignorance is on /.?

On: Using USB Hard Drives For Disk Images?

FIRST OFF, TO ANSWER THE ORIGINAL POSTERS QUESTION, SCSI IS ABOUT THE ONLY WAY TO GET DOS/REAL-MODE SUPPORT!!! JUST HOW THE F--- IS THE "OFF-TOPIC"??? [ Too much ignorance on /. IMHO!!! ]

Secondly, the TekRam DC-315U is a measly $15-20, does UltraSCSI (20MBps) and interfaces nicely to just about any old/new hard drive. It is completely supported by just about any OS (TekRam even has Linux and BSD drivers -- including distro installation driver disks). I buy one for all new PCs I get -- a smart move given the number of external Zip, Jaz, burners and whatnot that fly around the office.

Third, you can get late-model SCSI drives for under $100. Most will have enough storage for several cloned images. You don't need a modern SCSI drive, just one that will give you about 15MBps performance -- that's 10x the performance of USB!!! Add $20-40 for an external case, another $20-40 for cables and terminators and you're cooking! If you use Linux, you can hot-plug the solution and modprobe the TekRam driver on-the-fly!

Fourth, I do this for cloning. Yes, I do some over the network, but I don't always like to taxi my server in the middle of the day (among other reasons). And if I need to get the system up faster, SCSI gives me better performance than the network. Either way, USB is a slow pig and anyone who has used an external USB knows what I'm talking about! God, I cannot believe people have such ignorant, "say no to SCSI" attitudes! Geez!

Fifth, I'm glad someone else mentioned (since I forgot to) that PCMCIA SCSI cards are easily swappable, so yes, I use a PCMCIA SCSI card for the few notebook systems I have. I only need one card (and I have only one card).

Six, I do NOT disagree that IEEE1394 is a better, future solution. Frankly, I'm PO'ed that Intel is stalling on making it a standard feature in the southbridge chip (it was supposed to be standard with the PIIX4 southbridge!). I think AMD/VIA will force the issue with forthcoming chipsets and that will finally force Intel to put it on-board as well. Until then, TekRam SCSI cards are half the price and almost as fast (20MBps) as the 100-400Mbps (12.5-50MBps) Firewire cards. And, again, I'm NOT sure there is DOS/real-mode support.
[ But it's still good to see companies like Maxtor coming out with IEEE1394 drives (probably using a 33MBps 1394 to ATA bridge like this one). ]

-- Bryan "TheBS" Smith

"CVS Version Control for Web Site Projects"

On: Managing Websites with Unix/CVS?

CVS Version Control for Web Site Projects is always what I reference for help. In addition to that documentation, they also host the standard Cederdqvist CVS Manual in HTML, which I reference continuously for software development.

I'd simply remote into the web server and use the simple cvs export -r tag -d dir module command to export the files without CVS admin files (provided I cvs logged in to my remote CVS server via SSH/pserver, unless local). Or if you keep the CVS info in the directory for easy updating, simply cvs update -r tag in the directory you want to update.

-- Bryan "TheBS" Smith

I've said it before ... SCSI!!!

On: Using USB Hard Drives For Disk Images?

I've said it before, and I'll say it again. At only $15-20 extra per machine, you should be buying systems with SCSI cards. After that, you can plug in external SCSI devices, like hard drives, that are 20x faster than USB with full DOS/real-mode compatibility.

For more information, see this previous /. thread on USB hard drives (and just how freak'n slow they are). Look for my post in the middle (search for SCSI).

Otherwise, does anyone know if IEEE1394 FireWire cards have ASPI/real-mode drivers? If so, that might be another good option. But since most PCs still do not come with FireWire, and FireWire cards are more expensive than SCSI (and the drives aren't much cheaper, although Maxtor is trying to change that), it may not be better.

Either way, avoid USB since it is a slow pig. SCSI or FireWire is a much, much better angle that is 20x faster!

-- Bryan "TheBS" Smith

LyX! -- Re:LaTeX is the worst thing in the world.

On: Could LaTeX Replace HTML?

You want LyX!!!

-- Bryan "TheBS" Smith

i440GX sux, go ServerWorks instead (Intel did!)

On: Is AMD Worth A Professional Reputation?

The Intel 440GX is way behind the curve. Intel has poured so much into the Rambus avenue they forgot about the high-end where 4GB RAM and 2 standard PCI busses don't cut it. And the MTH (memory translator hub) failed to produce the SDRAM alternative they needed with the i840.

Enter ServerWorks' (formerly Reliance Computer Corporation, RCC) ServerSet III chipsets. They product chipsets for the big-boys, now for mainboard OEMs like Tyan, Asus and SuperMicro. 2 to 3 PCI busses (1 or 2 are 64-bit x 66MHz -- NOT slots, but whole busses!), 2 to 4-way PC133 SDRAM (supports upto 16GB), DDR SDRAM on the way, just awesome. The massive PCI I/O blows anything Intel's got away, and meets or beats most RISC vendors. Cheap too as the 2 CPU, 2 PCI bus, 2-way PC133 bus ServerSet IIILE can be had for just over $250 in SuperMicro mainboards.

ServerWorks is so good, Intel has adopted their chipsets for their own branded mainboards. Again, check them out!

P.S. As far as AMD, stay _away_ from Gateway 2000 -- the cheapest/worst components. Stick with a vendor that builds quality AMD systems, with AMD-approved components. Try Micron PC as they just introduced systems based on the new DDR SDRAM AMD i760 chipset mainboards and PC266 CPUs.

-- Bryan "TheBS" Smith

Documentation language, then documentation GUI

On: Technical Documentation With Automated Publishing?

First off, don't put your documentation or data at risk, always use standard documentation languages. Languages that are not only open, not only formats taht will last for decades, but formats that are 100% facimile reproducable. Think like a publisher.

With that said, SGML with strict DTDs is key. Factor in the ubiquious nature of other, widespread documentation languages like TeX/LaTeX, HTML, XML and, now, DocBook and its obvious that you want to standardize on SGML and DocBook and convert between them all. Plus you need to be able to make PDFs quick and easy.

Now you need a GUI. The problem with most GUIs is that you are limited by them. Not LyX, it is highly-extensible and more and more features are added by the moment. Originally a WYSIWYG (actually WYSIWYM, "what you mean") for TeX/LaTeX, LyX can eat TeX/LaTeX, SGML and other mark-up in-line. Again, you have a GUI, but you are not limited by it.

From the GUI standpoint, LyX has automatic TOC, TOF, biblio, indices, notes and other table/figure generation. I personally love LyX for its margin note and sidebar features, as well as headers and footnote. Lastly, LyX can eat EPS in-line and the PostScript preview is exactly what PostScript will go to your printer (I hate apps with print previews that aren't exact).

Lastly, built in support for RCS/CVS revision control makes it an ideal application for multiple tech writers. IMHO, who need limited collaboration tools when you have real revision control underneath?

If you're looking for a quick "HOWTO" to getting LyX installed, there is one for RPM-based distros here..

-- Bryan "TheBS" Smith

US Engineers learn metric, but industry varies

On: Will America Ever Go Metric?

The American public education system as well as scientists and engineers have been teaching almost entirely metric since the '70s. There is no debate what our schools should be and actually are teaching, and the effort at the educational level to use SI cannot go any deeper.

However, there is still a lot British Unit Standard is use. And reversing that is tough. Why? As someone mentioned, it has to do with engineering. Looking at the core three engineering disciplines, I will break it down:

• Civil

  Civil is probably the most entrenched area of British Units. A great majority of this country (at least the East and Midwest, where I've lived and worke) was surveyed and completed by the mid-1800s. Plats, surveys and all major reference points are still in British Units, although civil engineers have been using 1/10th of a foot (instead of an inch) to reduce confusion for the past century. All new submissions are required to have both in most federal and state mandates.

  But there is a major problem with the entire conversion process. Remember all those tests on significant digits? Well, a number of people forget the basic concepts and use only 3 significant digits for conversion (e.g., 2.54cm = 1inch). When spread over several square miles, that lack of attention can lead to someone being cheated an acre of land! It's an entire mess, hence many surveyors and engineers still use British units alongside the required metric ones to keep the numbers correct.

  This really makes you wonder if metric is a good choice for civil engineering yet, especially land surveying. The lack of attention to significant digits is really causing a backlash against those making these mandates (yet not caring about accuracy). I should know, my father is a land surveyor and I occassionally help him out.

• Mechanical

  Some of the greatest booms in the US' industry might came at the turn of the century and during World War II. Not surprisingly, all these machines are British standard. Changing this is slow task as nobody wants to chuck working machines, let alone possibly have to change to metrica suppliers who are harder to find. Furthermore, running with a dual-setup only adds confusion which, again, hurts their bottom line.

  You can see the mechanical influence in just about anything, from American cars to computer enclosures (see Electrical below). You can always tell what parts are made in America (or North American) and which are foreign, the former are (usually) in British, the later in metric. With more and more American cars just assembled in the US, while parts are made abroad, the are becoming more and more metric. And as American machines wear out, you'll see entire companies switch to metric.

  Now under mechanical is aerospace. And I'm personally sick of the ignorant bashing of NASA and contractors here on /. NASA and contractors are filled with metric spewing engineers -- I know, I worked in the aerospace field for 3 years. But the machinists and technicians are usually older gentlemen with quite a number of British-based machines and techniques. "Balast" (arbitrary weight used to modify center of gravity, etc...) is a very important in aerospace and while the engineers might do all the math, we don't assemble the rocket. Again, another issue in conversion.

• Electrical

  Electrical technologies are relatively new in the engineering discipline scheme. As such, by the time electricity came about (late 1800s), use of the metric was widespread among the American scientists who helped inventor or cultivate those technologies. Although British units were used at the time, most of the basics of electronics were set in stone at its infancy (volts, amps, watts, etc..>). From By the 1950s, most electrical engineering, technology and well as end-user usage programs focused on using only metric.

  Now getting back to my previous mention of computer enclosures, ever look at a spec sheet? Note how the dimensions of the enclosure are in British, yet the dimensions of the power supply are in metric! And it's not just because a good number of electronics come from outside the US, the US engineering industry has been metric for a long time. Sure, PCBs are still referenced in "mills" (thousands of an inch), but most of the time the mills spec is actually just an conversion approximation of the actual size in milli or micrometers (aka microns).

  As an engineer with a degree in electrical and computer engineering and one who currently works in the semiconductor industry, when accuracy matters, metric is always the standard (using mills for only quick representation in size of larger, lesser important dimensions).

Again, the issues are deep. I've personally seen them working in all three major engineering disciplines over the past 13 years. Anything electrical is basically metric here in the US. But there are still deep investments in British machines and other mechanical field equipment that will take time to change (but will). And as far as I am concerned, moving any civil standard away from British standard is not a good idea at this time, and given the reinvestment in re-surveying the country, I'd say it's not going to change for awhile (unless satellites can fully replace land surveyors, which is not happening for various reasons).

I appreciate everyone who took the time to read this. Most /.'ers postings on NASA and other engineering firms have been leaving bad tastes in my mouth.

-- Bryan "TheBS" Smith

Re:Not at my school - ABET classifies programs

On: College: Are They Training Engineers Or Coders?

When looking for graduates, you need to find how their program is classified. The American Accreditation Board of Engineering and Technology classifies various programs of various disciplines:

• Engineering Programs
• Technology Programs
• Engineering-Related Programs

Again, if you are looking for traditional engineering types, you want the first. If you are looking for formally trained technicians, then you want the later. Beyond that, you do not need formally educated personnel IMHO. Either that or the personnel you are looking for are part of the math/science disciplines (like CS).

-- Bryan "TheBS" Smith

Re:Students don't know what employers are looking

On: College: Are They Training Engineers Or Coders?

Yes, I agree, co-op programs are excellent! If your university does not off one, suggest it, and plan to work during college in a technical capacity on your own anyway.

Traditional universities are NOT institutions for technology application. They are for research and new ideas. They cannot possibly keep up with the industry, nor should they -- technology changes so much. They are designed to teach you how to learn and how to keep yourself learning throughout your life, giving you the basic tools to be able to learn anything.

Technology and engineering technology is where you learn practical knowledge. But since technology changes so much, technical degrees are really no better than real-world experience. Hence, I'm back to my original argument. The only thing that you can get from college that you cannot from real-world experience are those non-practical concepts that are applicable in some positions (like traditional engineering and design).

Most people do not need any formal training for technical positions, although you can always tell who has them. Because either they are inexperienced and know nothing, or they are experienced and, combined with their intuition, seem to know or can tackle anything. It all comes down to the ability of the individual to take that formal education and use it in the real-world. Again, I always look for engineers who held a technical job for 20-30+ hours/week while in college.

The former Soviet Union is the epitome of a _failed_ engineering programs. You could get a engineering degree in ball bearings at the Soviet Union. Such a specialization is useless except for in a narrow field. In contrast, I have done software development for ballisitic missiles at an aerospace firm and now I work in the IC design industry.

-- Bryan "TheBS" Smith

Re:The fault lies within the corporations.

On: College: Are They Training Engineers Or Coders?

That's because companies like Novell and Microsoft don't make the proper distinction between engineers and [engineering] technologists. They get caught up in "we _are_ engineers, really." Hence, the lack of differentiation.

Most people just lump the guy who can repair PCs and network computers and the guy who can design integrated circuits (i.e. computer chips) into the same group, engineers. It's one thing to have an informal title of "engineer", which is tolerable, but it is another to be representing yourself in a consulting capacity as an engineer. There is a whole slew of liability and licensing issues that goes along with that title which most people do not have (unless they are traditional engineers).

And unlike the electrical/computer engineering fields, both corporations and regulatory bodies of other engineering disciplines (like civil) don't stand for this. The IS/IT professional or system administrator is to electrical/computer engineering field as the land surveyor or draftsman is to the civil/environmental field. In each case, the former is 10x more numerous and pratical than the later. But you cannot have the former if you don't have later, otherwise there would be no products to use, install or fix.

[ Note: This is not an "anal" stance, but a stance of trying to "reduce confusion" so don't all you IS/IT professionals get all pissy on me. I already said you are more "practical" and _are_ in more demand than us traditional types. ]

-- Bryan "TheBS" Smith

Re:I graduated in '96 with a BSECE ... my perspect

On: College: Are They Training Engineers Or Coders?

So you're in a technology program. There is nothing wrong with that. I was reponding to the original post on why there *IS* a lack of good problem solvers and designers out there. US colleges are only graduating less than 20,000 traditional engineering types a year. That's not good.

BTW, read Asimov's Foundation Trilogy. Excellent theme in there -- if a portion of the population does not continue to "learn the basics" our whole technology infrastructure will die. Knowing how to use technology and knowing the concepts and designs behind them are two different things. You cannot have people doing the former if you do not have people doing the later.

-- Bryan "TheBS" Smith

Re:I graduated in '96 with a BSECE ... my perspect

On: College: Are They Training Engineers Or Coders?

Dude, if you don't use Linux, don't comment about Linux. If you don't use BSD, don't comment about BSD. If you don't use Solaris, don't comment about Solaris. Etc ... That's all I meant!

-- Bryan "TheBS" Smith

I graduated in '96 with a BSECE ... my perspective

On: College: Are They Training Engineers Or Coders?

I don't know about your local university, but my 5-year computer engineer degree was of the traditional engineering type. Math, mechanics, traditional EE core, only 4 courses different that specialized in software, computer architecture and algorithms. I know people complained that we weren't learning much that was applicable, that we shouldn't have to take materials, dynamics, analysis, etc..., especially combined all the intros we took into other engineering disciplines (like environmental, etc...), but I felt it really taught us to problem solve, even if we were in unfamiliar territory (like another discipline).

In all my engineering courses, especially in my EE/ECE discipline, we were pretty much given a problem and told to figure out how to solve it. They didn't baby us by teaching programming languages, they didn't tell us what language you had to use. In fact, when I reached my EE/ECE courses and I had to code -- they expected you to have already learned a programming language somewhere (or take a 3 hour survey course if you didn't, and it didn't count as a valid option towards your graduation requirements either). Whether it was some piece of software, required an embedded circuit design, etc... You had to look at it, try something, get frustrated, try something else, at one point you always hit the professors office hours to ask a question or two, then finally solve it. I remember spending a lot of time in the labs looking at spec sheets, playing with analog/digital ICs and drawing on the knowledge of others, especially technicians who worked in the industry (or our large research park, #2 in size in the nation), to come up with solutions.

I also received a computer science minor from the same university. It was less math, less physics, and numerous, what could be considered, "remedial" programming courses -- requiring you to use a specific language (Modula-2). If CS was my major, the other courses would go on to 8-bit microcontrollers, 32-bit microprocessors, several surveys of programming languages and the standard survey and choice of other topics. In the end, a 120 semmester hour CS degree comprised to about 3/4ths (~90 hours) of just software implementation and IC technology.

Again, in comparison, the engineering discipline at my univeristy shouved a total of 135 semmester hours of largely traditional engineering down my throat (~80 hours), then only a year (~24-30 hours) of one of the "big-three" disciplines (civil/electrical/mechanical, electrical in my case) and only half a year (~15 hours) of the further specialty (computer in my case). A lot of people complained about the lack of specialty, but I personally like it -- felt like it taught me to think.

I felt CS (among other 4-year degrees like engineering technology and 2-year tech degrees) are more "practical" whereas traditional engineering doesn't teach you anything "useable" except for the ability to think and problem solve. It'd rather have the intuition in the later than the knowledge in the former, because I can always compile the former with experience -- and I worked 30+ hours while in college in IS/IT departments at various engineering firms, which gave me the former at the same time. I guess the type of graduate produced at institutions depends on the institution one attends. The EE department at the institution where I attended ranks in the top 25 on the College Board rankings for EE departments. [ I personally think my institution sux, big time, from the administration to most of the departments. But the engineering college is a complete 180 from the rest of the college. I wouldn't have gone anywhere else. ]

-- Bryan "TheBS" Smith

Re:Linux IS supported -- it's a known bug

On: AMD's DDR-Capable 760 Chipset Reviewed X3

Here's the 1-line patch (change in bold):

00-09-10 H.J. Lu
* linux-2.2.16-pn.patch: New. Only disable CPU serial number
for Intel CPUs.
--- linux/include/asm-i386/processor.h.pn Sun Sep 10 16:38:54 2000
+++ linux/include/asm-i386/processor.h Sun Sep 10 16:39:57 2000
@@ -126,6 +126,7 @@ extern int disable_x86_serial_nr;
static inline void disable_serial_nr(void)
{
if ( disable_x86_serial_nr &&
+ (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) &&
(boot_cpu_data.x86_capability & X86_FEATURE_PN) ) {
printk("Disabling CPUID Serial number...");
__asm__ __volatile__( "movl $0x119,%%ecx\n\t"

It seems to work fine with Pentium, Pro, II, III chips and AMD Athlon, Duron and Thunderbird -- trying to disable in the former, skipping the code in the later. The kernel panic results from the disable opcodes running different instructions that trash the Athlons (especially the newer Duron/Thunderbirds). Have not tried the code on older 386/486-class CPUs, but it probably will work fine on them too.

In a nutshell, anyone who compiles in the PIII S/N disabled by default should patch their kernel with this 1-line change!

-- Bryan "TheBS" Smith

Install the Outlook Security Patch

On: Scanning For Windows Viruses Using Unix?

Will solve 99.9% of your problems. Of course it messes up Outlook's automation features, but that was the problem in the first place. It got rid of all our issues.

BTW, Bynari has an Exchange-server replacement for Linux that will give your Outlook clients most of those features back at the server level. As such, we're thinking about switching from HP OpenMail to Bynari's TradeServer.

-- Bryan "TheBS" Smith

Re:seconded. - Removable IDE works too

On: USB Hard Drive Recommendations?

Yes, I agree that removable IDE works too. Bays and trays are $15-25 at Cyberguys.

Just realize that you'll have some master/slave issues if you have devices on both IDE channels, or your IDE devices have different jumpers between single/master (e.g., WD drives).

That's why I like SCSI. Although an additional PCI IDE card in each would also be a good option -- but then we're back upto the cost of my SCSI solution.

-- Bryan "TheBS" Smith

Buy SCSI, 10x speed, 10x+ storage, save money ...

On: USB Hard Drive Recommendations?

Okay dude, I know this sounds weird but SCSI would not only be faster, but probably cheaper. Most SCSI drives (of even two generations back) can do easily 10MBps+ (80Mbps+), whereas even USB's fastest speed, we're talking only 1.5MBps (12Mbps). And don't even think of those IDE to parallel kits, 2MBps (16Mbps) max (most don't get get 1MBps/8Mbps). Plus SCSI support under Linux is easy (and even loadable on the fly!).

Cards, case and cabling should run you under $100 for two systems. The a good sized, but older model, SCSI drive should only be another $30-100 for a decent size (2-23GB) and speed (5400-7200rpm, 512-2048KB buffer). The breakdown:

• Cards ($20/each) -- (2) SCSI cards at about $20 a piece thanx to the TekRam-315U (UltraSCSI, no-BIOS). You can find them at your favorite PriceWatch advertising reseller. You'll need more if you have more than a few systems to swap between. Of course this becomes cost prohibitive if its more than 5 systems, so consider that. But for just 2-4 systems, it's great (and, again, fast)!
• Case ($20) -- You can usually find them at various on-line resellers for $20 or so. Here's a great 2-bay w/40W PS for $19, and that's new. If you want smaller, there are various resellers with single bay SCSI enclosures too. Cyberguys has a 3.5" for $50, although you might find cheaper if you look a bit. The case should come with internal cabling (I've never seen one without).
• External Cabling ($10) -- Cabling is also an addition, but fairly cheap anymore. Assuming you set the drive jumper for termination, you only need the cable. You can get the SCSI-2 HD50M to Centronics 50M for $9 for cases with Centronics connectors, or SCSI-2 HD50M to HD50M for $10 for cases with SCSI-2 HD connectors -- both at Cyberguys. If you really want to not terminate the drive itself, but on the case, HD50M active terminators are $11 and Centronics passive terminators are $5
• Hard Disk ($30+) -- Depending on what model you get, older SCSI hard drives can be had for $30-100. If you want massive or fast, $200-300 will get you give a bit of each. Some resellers that carry new, unused, used and refurbished hard drives:
  • Computer Geeks Outlet -- good personal experiences
  • Hi-Tech Cafe -- don't deal with their web site (sux, lose orders), call them instead
  • Com puter Surplus Outlet -- good dealings with them several times

Drives that are 50-pin narrow (Fast, Ultra, Ultra2, etc...) and will work in the case without modification. Some with be 68-pin wide or 80-pin SCA (FastWide, UltraWide, Ultra2Wide/Ultra80, Ultra160). In the case of the two later, Cyberguys sells converters to 50-pin narrow for nearly all of these connectors. The only caveat you'll have is termination, either terminate on the drive itself (i.e. don't use an external terminator) or tell the drive to use 8-bit SCSI (instead of 16-bit in 68/80-pin) as any external terminator for 50-pin will only terminate the lower 8-bits (some drives will autosense the connection as narrow and will autoterminate anyway -- see the drive docs).

Again, the only reason not to go with this config is if you are going to be sharing with more than just a few systems. You're going to be lugging around a drive anyway, why not forget worrying about carrying the media as well and have 50x the storage (compared to Zip -- much more manageable).

If you absolutely need removable and have the money to burn look at SCSI Jaz instead (2GB capacity, ~5MBps/40Mbps performance). But don't go optical, e.g. 5.2/9.4GB DVD-RAM, it's slow (9x CD, 1x DVD = 1.35MBps/10.5Mbps).

-- Bryan "TheBS" Smith

No GNU toolchain keeps me from developing on it

On: The Rise Of QNX

The big reason I haven't gotten into QNX is their lack of using the GNU toolchain. Now I noticed someone here mentioned that QNX is older than GNU (established 1983-84), which would explain why they didn't use it off-the-bat. But you would have figured that they would have moved over to the GNU toolchain sometime since. Expecially in light of numerous other, commercial RTOS' use of the GNU toolchain (e.g., VxWorks).

-- Bryan "TheBS" Smith

Not surprising, most engineering is UNIX ...

On: NCSU/Red Hat "Open Source University"

Most mechanical/aerospace and electrical/computer design firms are heavily rooted in UNIX. I work for a semiconductor design and technology firm and all our EDA (electronic design automation) tools not only run on UNIX, but 75% of them either don't have Windows ports or are "crippled" on Windows (because of issues with multiuser, remote display, etc...).

About half of those tools now have full, native ports on Linux. Specifically you ask? Try Synopsys, Mentor Graphics, ModelTech, etc... Although Sun just came out with a powerful new UltraSPARC III chip (powerful from an FPU, and therefore engineering, standpoint against x86), Linux gives you much more "bang for the buck" on single/dual processor x86 hardware than SPARC.

Furthermore, many of the preceding companies have been touting the price vs. performance ratio of Linux clusters versus traditional shared memory Sun systems (in favor of Linux, of course ;-) and have modified their Linux ports just for such implementations.

-- Bryan "TheBS" Smith

NeoMagic chipset is proprietary, unsupported?

On: Configuring X to Run on VAIO Desktop LCD Screens?

I was under the impression that the NeoMagic chipset that Vaio's use was proprietary and supported. In the past, there were binary-only X-Servers. I'm unsure of what your current options are, but can only offer my experience.

Of the newer Vaio's I've seen with the NeoMagic chipset, you had to use the kernel framebuffer support and the FBDev X-Server to get working. I assume the same is true for XFree86 v4.0, you use the FBDev driver.

[ P.S. I also understand many NeoMagic chipsets, including those used in the Vaio, do not support Direct3D as well. ]

-- Bryan "TheBS" Smith

Get rid of NT Server on your network, chatty f'ers

On: Subnets and Network Browsing?

I run a UNIX/Samba LAN. I use only UNIX/Samba for file/print services. We use WINS on all our clients, including talking to other subnets.

Unfortunately, I have one NT Server for a SQL application (that I fought, and lost, to keep off my network -- only 3 people use it). I do not use named pipes on it at all and tell it to use WINS for NetBIOS resolution. But the f'er sends out more broadcasts that all other (50) systems combined (an average of ~10/second). I have tried tweaking this thing 10 ways to Sunday and cannot get it to stop the chatter (and yes, I've told it to NOT be the local master).

Case in point, if get NT Servers off your network, you'll cut the chatter several times over. I'm much more of an expert at Samba than NT, but after 8 years experience with NT, I think I know somewhat of I'm doing (although I'll take any suggestions at this point ;-).

P.S. I was the contributing author on Samba Unleashed and wrote Chapter 33 on "Cross Subnet Browsing" (which was a last second rush job, otherwise I would have added info to fix exactly the issues you are having by replacing NT with Samba). IMHO Samba is just so much better at running large WANs with multiple subnets!

-- Bryan "TheBS" Smith