The problem isn't immigrants in general, it's underpaying immigrants so they can replace higher salaried Americans! That's what H1B VISA's promote! The IEEE has been trying to get this fact out, but people think it's an immigration v. anti-immigration issue. Not so! It is more complex than you realize -- and American companies are here to dupe you! Trust me, immigrants, the IEEE-USA is your friend in this!
What the IEEE-USA does is actually promote giving real green cards to immigrants who are engineers instead of H1B VISAs. They recognize the real problem and how companies abuse the H1B VISA system whereas they cannot "abuse the system" with green cards. Unlike H1B VISAs where companies can "put the screws" to immigrants who cannot change their sponsor, so they work for less, so they can replace Americans. So why does this matter?
Green card holders can change jobs so they demand the same salaries as Americans! As such, Americans don't get fired, nor do their salaries decrease! Green card immigrants are only brought in to augment them as necessary and become Americans themselves. H1B VISAs are used to temporarily gain access to lower-costing employees and destroy America in general for corporate profits (this still happens despite the supposed "loophole changes" in H1B VISAs). The IEEE promotes an "accelerated program" to allow real engineers to get green cards faster than the normal process. Linux Torvalds is one of their "poster childs" showcasing the enormous amount of BS he had go through.
Furthermore, they have tried to "educate" the public on a "technician" and the so-called "IT shortage" versus "engineers" who do not deal with IT!
No one in the world has the unique perspective to put a technical or financial focus on a political problem (e.g., VISA and green cards -- the IEEE has a very insightful view into those that most people don't know;-). The IEEE has its own political action committees (PACs) and other lobbying efforts which many members pay for by default. So let's not get into the BS about the IEEE "not being able to do anything."
Not bad, #27. But if you look at the SE US Regional Standings, we look even better! #1, #4 and #7 -- our undergrad teams regularly beat other SE US graduate teams. UCF has represented the SE US at the world finals for most of the competition's history, including they heaftier competition of more recent years.
UCF has never won #1, but they took #2 in 1987 and #4 in 1986 back in the Early Years. In the '90s, we've broken the top 10 at world only once or twice, but we've managed to place in the top 25 regularly.
At every hackfest, I had at least 2-3 people ask about my Loki games, "Are you allowing people to copy this?" Com'mon! I too bought most of my Loki games direct for $25-50, and picked up a few others at EB for $10-20.
Of couse, the game market just had too thin of margins for Loki to survive regardless. I'm glad to see independent developers signing NDAs with game makers to make Linux ports though. Hopefully the major houses will start doing their own soon enough.
I'm not a Mandrake fan, nor do I use it. But I've gotta side with Mandrake in this one, because it's obvious some of you are taking their goodwill too far. I pay RedHat the similar $60/year, the lowest level, for priority downloads and other services. I don't expect anything more, nor should you Mandrake $60/yearers after reading their agreement.
Reality check people! $60/year does NOT entitle you to a
product that is almost $100 on the retail shelf. I don't care about OEM licensing, Mandrake has got to make money! Furthermore, that $60
probably barely covers all the other services and benefits provided. Lastly, the statement of "receive the same benefits" would most likely
extend to only Mandrake products and services, and NOT 3rd party
products and/or services. Otherwise, Mandrake would go "belly up"
(actually all distros seem to have a constant loss after all expense
considerations, even RedHat).
Frankly, Mandrake should be commended on allowing StarOffice to be
downloaded as an.iso thanx to membership, and Sun for licensing it to Linux distributors so they can do so. Man, I'm really getting sick of
this "whining" crap. Some of you "whiney" Linux users need to go! At least before most of the good, GPL-focused commercial organizations cannot sustain your selfishness!
2/3rds of the states bother to "show up" and ultimately represent the underlying balance of and right to local judgement. Chalk up another one for freedom, regardless of what you think of this trial in general. I guess the US still has more life to it than I previously thought.
Re:DVD-R vs DVD+R -- It's called Sony/Philips ...
on
HP DVD+R Writers Examined
·
· Score: 3, Interesting
See my other post. While the DVD consortium standardized on DVD-R and DVD-RAM back in the early '90s, Sony/Philips saw an opportunity to break away from the consortium. One reason was that Pioneer's DVD-R, DVD-R(A) at the time, was expensive ($10K+!), and Panasonic's $500 DVD-RAM was designed for optical archiving (long story, but its not designed for consumers), and could only hold 2.6GB/side at the time. Sony/Philips had a 3GB design that could also record/rewrite CD-R/RW as well. They called this "standard" DVD-R+W
But Sony/Philips soon "woke up" to the reality of their design took too long to build -- over 3 years! By the time their 3GB drive was ready to "hit the market" in 2000, Panasonic had delievered its sub-$500 2nd-gen 4.7GB/side DVD-RAM drive and Pioneer released sub-$1K DVD-R(G) drive. So the 3GB DVD-R+W drive never saw the light of day, and S/P went "back to work" on an "improved" DVD-R+W drive. This would become DVD+RW
Well, even before DVD+RW finally hit in 2001, Panasonic had released a 3rd gen DVD-RAM which was a 2nd gen DVD-RAM + DVD-R(G), and Pioneer had come out with its consumer DVD-RW drive, which also did CD-R/RW as well as DVD-R(G). So basically DVD-R(G) _is_ the standard for recordable DVD, and DVD-RW is the consumer rewritable, and DVD-RAM is the optical archiving rewritable.
Now you've got the requirement of a second gen DVD+RW drive just to get DVD+R. And I haven't seen any compatibility testing to show its as good as DVD-R. If DVD+R is only as compatible as DVD+RW, then it's only around 70%. Although that is the same as DVD-RW, and much better than DVD-RAM), it's still not as good as the 99.9% compatibility of DVD-R(G), which is now done by _all_ competiting drives. Worse yet, you can get the 3rd gen Panasonic drive for less than $300 and the rewrite capability it has been working in Linux for years (and cdrecord/DVD-R(G) is in beta testing).
Sony/Philips has proven they are consistently "behind the times" and they flat out make promises they canNOT keep! As such, this whole DVD+R announcement does NOT shock me at all.
Guys, this is nothing new. As someone who has had a DVD-RAM drive, working in Linux since 1998, I've followed Sony/Philip's "non-standards" since 1995.
They "broke off" from the DVD consortium and introduced a 3.0GB DVD-R/W "standard" that never shipped back in 1999. They have broken promise after promise after promise, again and again and again. I figured DVD+R would be more of the same -- and we've yet to see the "compatibility" tests to see if it is "as good" as DVD-R(G).
Meanwhile, both Panasonic DVD-RAM (3rd gen, 2001) and Pioneer DVD-RW (2000) drives write DVD-R(G), a near-100% compatible standard. Not only are 3rd gen DVD-RAM drives sub-$300, but the DVD-R(G) disks are sub-$3/each! And the cdrecord 1.11 test releases support DVD-R(G) recording.
If you just need backup, DVD-RAM works great in Linux now as a "packet writer" (i.e. like a generic, random access disk -- has for 4 years!) and has a longer shelf-life (especially in the 2-sided, cartridged version) with 100x the rewritability of either DVD-RW or DVD+RW (100,000x v. 1,000x). Unfortunately, it's not player compatible (because they don't have the added logic and laser wavelength required) because it was designed as the new, universal, optical archiving format (and not a consuemr one). Hence why it's for archiving, not consumer use.
"They don't build 'em like this anymore, gentlemen - all you need to do to see that is look at the Mars probes."
You should really compare Pioneer 10 v. Galileo, Cassini or other, similar-costing, "full QA" projects from NASA. The "better, faster, cheaper" Mars probes that gained a lot of noteriety in their failures are NOT good comparisons based on their cost and lack of equivalent QA/testing.
Simple engineering risk analysis showed NASA that the orders of magnitude in additional cost are worth it to guarantee an over 99% chance of success, versus less than 50% in the BFC approach. NASA will no longer attempt to build probes like those three Mars BFC projects (of which, only one was a success) again.
Imagine how much GPL development could be funded?
on
Spyware in Audio Galaxy
·
· Score: 1, Offtopic
Now I feel there is no excuse for RedHat users such as myself not to help fund RedHat.
In praise of 100% GPL-focused RedHat
RedHat, despite what you might think of their distro or business-side tactics, funds probably the greatest number of 100% GPL software developers (since VA no longer does). I cannot stress enough the importance of this fact. Every distro enjoys the fruits of RedHat employee labor, and not just Gnome developments either.
Imagine the number of developers that could be hired
For every 2,000 people who sign up for the service, that's $120K/year for RedHat. Figuring half of that goes to upgrades to their network
infrastructure to support the additional downloads, that leaves $60K to fund another developer on-staff. If all 2 million RedHat sysadmins (my estimate is 2M, which equals ~20M installs, ~10 installs/per sysadmin on
average) coughed up $60/year, that's $120M/year for RedHat. That could equate to adding $60M for developers, or about a thousand employees!
Personal note
I've been a total RedHat leech here. Although I have worked for various companies who have paid for Cygnus tools (Cygnus is a division of
RedHat), I've pretty much only bought the boxed sets on every.2 release (and I haven't bought 7.2 yet). I've been running RedHat on this system
(through various hardware upgrades) since 4.2, only re-installing once to move to XFS (RedHat 7.0.92 + XFS 1.0 betas was a "clean" install).
I've installed RedHat on close to 500 systems now, and I'm sure well over half of those are still in use. So that amounts to about $0.10 per
system I've installed. Definately not enough IMHO. I want to change this. This is a great avenue to do so.
As your momma always said: 'If you don't have anything good to say about someone, don't say it' or 'if you someone keeps "bothering" you, just stay away from them.' It's as simple as that.
So if you don't like Richard Morrell, head of the SmoothWall project, consider:
ignoring him
the fact that SmoothWall is free software and freely supported (regardless of the "requests" for monetary support made)
disregarding SmoothWall altogether, if it really "bothers" you that much (see below)
Personally, I'm sick of the "one-sided" reporting on Mr. Morrell. I've seen way too many people "complain" about him, but never comment on various personal details that are partially the cause of this -- let alone the daily on-slaught of Windows users who've barely heard of Linux, who don't bother reading the FAQ, let alone demand that SmoothWall automagically support every little, crappy-designed Windows application and their proprietary protocols that don't work well with firewalls anyway. After a week of being on the SmoothWall lists, I'd kill some very rude and ungrateful users well before Morrell. If you feel Morrell is "really bad for the project," then that's his problem, not yours!
Now if you still want something like SmoothWall without the SmoothWall(TM), take notice that others have forked the project into a new one called IPCop. Version 0.1.0 features SmoothWall 0.9.9, all the major post-0.9.9 patches and various enhancements. A final 0.1.1 release is to follow shortly before the team starts to work on version 0.2.0, an Linux 2.4/Netfilter implementation.
For all I care, you can think of IPCop as "SmoothWall without Morrell." Just don't say it outloud since many of us are all sick of hearing it!
One thing I've been able to do is stump MS every time. Several times I've gotten the answer "our OS don't let you do that," and my superior's jaws would just drop! It's one of the reasons why we've had to chuck MS products in many applications.
In addition to the "ReiserFS absolutists" who know little about XFS, it seems we also have so "SCSI RAID absolutists" here who know little about 3Ware microcontroller-driven RAID controllers. So a little education is in order.
First off, most of the "dumb, BIOS-only" IDE RAID solutions do "suck." Since they are still just a "dumb" IDE controller, they still off-load computational and other details off to the CPU, which is still, ultimately, driving the drives. So they still inherit all the limitations of IDE, including the 128GB max addressing limitation. Worse yet, nearly all of these solutions allow more than one drive per channel with just kills performance (especially in the 4 drive, RAID-0/1 implementations).
Fortunately, 3Ware and a few select others have built real host adapter solutions, except they use IDE drives. With that small exception, they are almost exactly like more expensive, SCSI-based RAID controller solutions. They have an on-board microcontroller that not only off-loads all the computational details, but drives the IDE disks directly. As such, the 3Ware card, for all intents and purposes, is a SCSI controller from the OS' perspectively, including support for upto 2TB device sizes. The OS never sees the underlying hardware itself, which also allows these devices to emulate advanced SCSI features like command queuing, threading and even sector remapping.
The 3Ware Escalade 6000 series comes in 2, 4 and 8 channel versions, with one device per channel, at a cost of about $60/channel. 3Ware support is included in all the latest 2.2 and 2.4 kernels from most distros (and in most stock Linux kernel releases as well). Although Adaptec now has a similar, 4-channel product (that does RAID-5 as well?), I have not seen Linux support for it. In the near future, 3Ware plans on introducing a new product series with RAID-5 support (current Escalades can only do RAID-0, 1 or 0/1).
My appologies for the typos including the use of "XFS" when I meant "NFS" in a few places. This post has been moderated upto to 5, and I have received numerous direct mailings -- all positive, unbelievable! This has restored my faith in/., who I was privately boycotting until I saw the XFS/. discussion mention on NewsForge.
What I am really "arguing for" here is not a "what is better" or a "why is ReiserFS in kernel 2.4.1+ and not XFS?" 'jealousy' attitude (as Hans Reiser recently called it;-), but a simple "call on RedHat and VA Linux to start looking at XFS." I do not think it is my business to question Linus non-inclusion of XFS in the kernel, as he has a better understanding that I. All I'm asking for is the industry to start supporting something that obviously works for a good portion of us.
Especially now in light of layoffs at SGI, which can only mean a reduction in direct support of XFS by them.
Whether you agree with it or not, RedHat and VALinux alike have spurned adopting ReiserFS despite its inclusion in the stock Linux kernel as of 2.4.1. Both vendors have courted the more "evolutionary" Ext3 kernel for 2.2 releases, but Ext3 is not the future of JFS' on Linux. As such, I offer this article in a plea for RedHat and/or VA Linux to begin consideration and formal testing of XFS as a viable JFS for their future, kernel 2.4-based product releases.
Your typical dual-NFS/SMB file server administrator
I have been integrating and maintaining production NFS/SMB UNIX servers and networks for years. As such, I ask that some of the "ReiserFS absolutists" (i.e. believe only ReiserFS should exist as every other JFS for Linux is "not as good" in their opinions) out there, who don't use Linux's kNFSd services in a heavy production environment (especially with non-Linux NFS clients) like myself, please not blindly comment on this post. Remember, every OSS project "itches a scratch," and there is a reason why Tweedie's Ext3 and SGI's XFS exist in addition to Namesys' ReiserFS (disclaimer: I know little about IBM's JFS).
Why some of us went Ext3 over ReiserFS
Because I have UNIX NFS clients, ReiserFS was quickly identified as a "non-viable solution" for my needs (not that it is not applicable in many other areas, no sir, so don't flame me!) when I first looked at JFS' in early 2000. Although ReiserFS is very innovative in design, which includes a recent DARPA grant to extend these capabilities, its lack of a traditionally keeping meta-data in the inode itself results in a host of traditional UNIX service and VFS incompatibilites. So I ended up testing the early, full data journaling (aka Ext3 "v1 mode") Ext3 releases (e.g., 0.0.2f) for 3 months on non-critical systems with great success. I eventually adopted it on my main fileservers in summer of 2000 and it has worked flawlessly since. I even had a physical disk error, which my RAID controller did not catch for 24 seconds (long story, the firmware and driver versiuons was out of sync, my fault) and I was able to drop down to the full Ext2 fsck to fix things.
Ext3, the conservative solution
For people like me, Ext3 is a nice, "evolutionary" approach to journaling that significantly reduces the variables involved -- important to some of us that don't embrace "change" so quickly (for obvious reasons;-). Ext3 is also a quick upgrade for existing Ext2 filesystems (get Ext3 kernel, e2fsprogs aware version, create the journal file, and mount as Ext3) plus complete reversable back to Ext2 (just delete the journal file and reset some superblock variables), which meant I could "switch back at a moments notice." I find the VA Linux kernels with Ext3 added (along with NFS v3, unified IDE and other 2.4 backports to 2.2) most excellent, and longtime Linux kernel NFS guru H.J. Lu (now formerly of VA) takes the time to make the appropriate RedHat RPM kernels for us RedHat users (shortly after HJL's departure from VA, I began hosting his kernels). VA Linux uses Ext3 in their enterprise NAS device products (actually based on not a RedHat kernel, but SuSE!), although RedHat's adoption of Ext3 has been limited to a public beta, and installer/BOOT kernels that are simply "Ext3 aware."
Ext3, not ideal for the near future
Today, Ext3 is still a kernel 2.2-only solution. And it still "inherits" all the "limitations" of Ext2 -- so it is not ideal where features are more important that minimizing variables. Now it's not that I've adopted kernel 2.4 on my most critical services, as it is still maturing IMHO (not bashing 2.4 at all, but as more systems run it, more "issues" are identified that were not before), but it would still be nice to have on some of my more "bleeding edge" workstations. I would be satified if Tweedie would only port the full data journaling (v1 mode) capability to 2.4, although I heard he purposes held off on the kernel 2.4 port and Ext3 1.0's release until 2.4 itself "stabilized" in his view (of which, I've heard many good reasons for doing so). If anyone has any insight to all this, I'm all ears (as I can only "assume" things here from what I've heard).
Re-evaluation of ReiserFS in kernel 2.4.1+
As such, that left me with re-evaluating ReiserFS for 2.4 systems, now in the stock 2.4.1 kernel, or possibly SGI's XFS or IBM's JFS. I looked at ReiserFS only to discover that the stock kernel does not include the kNFSd workaround patches. Furthermore, many ReiserFS users were still plauged with NFS and even quote issues, even after patching. This tends to make me believe that it will still be awhile before specific Linux subsystems "better accomodate" ReiserFS completely for certain users (like myself), although it is a viable solution for most standalone workstations or Windows-centric file servers. Even I am using ReiserFS on a kernel 2.4 Netfilter firewall and Squid Proxy cache/filter, where it excels (but does no direct network file serving duties).
First impressions of XFS in mid-February
This led me to SGI's XFS. Mid February saw the release of kernel 2.4.2 and, by the weekend of the 24th, SGI had already adopted 2.4.2 as the base of their XFS development CVS repository. I was impressed with this attention to keeping XFS' development as close to the stock kernel as possible. I decided to check out the kernel, compile and test it on a few older and newer systems, and ended up writing an RPM spec file and releasing some RPMs for RedHat 7.0 at the time (since it has been a couple months, using 2.4.0pre kernels, since SGI had done so). Thus I began my standard "three month evaluation" of XFS in early 2001, like I did with ReiserFS and Ext3 in early 2000.
What is instantly preferrable about XFS
It did not take me long before I was impressed with SGI's XFS implementation. Most specifically:
Forgetting features, Linux-oriented integration was at the forefront of XFS' port. The fsck program was called "fsck.xfs" (which really did only some basic things, relying on "xfs_repair" for any rare "dirty work"), and "xfsdump" preserved advanced XFS attributes in backups.
The structure of XFS has remained relatively unchanged since the original whitepapers and release in the 1993-1994 timeframe. One thing that scares me about ReiserFS is the changing internal structure, not just via the extensible features of putting meta-data directly in the root tree -- which is a very interesting, advanced and novel idea -- don't get me wrong -- but I believe even Linus had to put his foot down on some of these "variables" before ReiserFS was included in 2.4.1 (as I have heard). Again, XFS' structure on Linux is that of the Irix implementation.
Regarding features, according to the Linux Gazette #55 review of JFS' for Linux (mid-2000), XFS sported the most features -- from B+Tree directory and free block management to small data file and directories being stored in the inode itself. But it still preserved the traditional, UNIX FS inode structure that made NFS, quota and other support natural and minimal in effort.
The ability to move storage devices from MIPS/Irix systems to Linux systems is a big plus. Most intererstingly, this also included almost direct porting of XFS's Access Control List (ACL) capability from the Irix platform to Linux. I had personally never used ACLs on Irix before, just Solaris, and was impressed by XFS' storing of ACLs in the filesystem meta-data, instead of in separate files like Solaris (although the XFS "acl" front-end has a syntax that leaves much to be desired;-).
Lastly, it looks like SGI is "thinking ahead" to enterprise NAS/SAN devices by implementing a Data Management API (DMAPI) for hierarchical storage management (HSM) subsystems. XFS excels at large file performance, hence why MIPS/Irix is a favorite platform for A/V content servers.
How SGI releases XFS
Shortly after my RPM releases for RedHat 7.0, SGI began a series of test releases for the RedHat 7.1 beta (first Fisher, 7.0.90, and then Wolverine, 7.0.91) in March and April, and eventually RedHat 7.1 itself. Like the 2.4.0pre kernel releases before them, RedHat releases XFS in a three fold scheme:
Tarballs from CVS, and patches from CVS again the stock kernel, which include the ability to build RPMs and Debian packages (by including the appropriate SPEC/config files).
[Source] RPMs for popular RPM distributions (e.g., RedHat), as SGI has a long stance of not being in the business of distributing their own full-up distro (just support "add-ons" for their hardware).
A modified RPM set and Anaconda installer, including a bootable, pre-mastered ISO CD, that allows XFS to be installed alongside a stock RedHat distribution. This is especially sweet IMHO.
XFS Release 1.0 is a solid JFS for 2.4 file servers
As of May 1st, XFS Release 1.0 was released. In following their three fold release venue, it includes a ~300MB additional ISO CD for installing with RedHat 7.1. But instead of patching XFS against just the stock Linux kernel, SGI took the time to take the RedHat 7.1 2.4.2-2 RPM kernel release and patch it against that (they actually did this with 1.0-Test3 as well) -- inheriting and benefiting all the patches and other kernel decisions that RedHat makes. This is very important to system administrators like myself which only trust RedHat releases and kernels for heavy file server duties (please, no flames on this -- I'll list reasons off-list, and I *DO* recommend Mandrake and, increasingly, Debian for many other purposes).
Additional advantages of XFS that RedHat/VALinux should consider
As such, I am surprised that RedHat and, especially, VA Linux have not taken a closer look at evaluating and, gulp, even supporting XFS's development on kernel 2.4. XFS is the natural upgrade for these two firms, being that both have spurned supporting ReiserFS for its non-traditional and troublesome design with traditional UNIX services and capabilities like XFS. In addition to design attitude, features and other considerations SGI has made in porting XFS to Linux as I made above, I would like also point out the following, additional considerations:
Again, I want to hammer home that SGI has been committed with each and every OSS project and release to base them on the "common" project releases. Not only does SGI keep their CVS repository in-sync with the latest kernel and support project releases, but they can integrated XFS with even RedHat's heavily patched kernel releases. I would personally like to hear what Alan Cox thinks of adding XFS to either his "ac" release, or pushing it on RedHat internally.
XFS's ACL capabilities are superb and add quite an "enterprise punch" to Linux. Not only are the XFS ACL's supported fully in Samba 2.2 on both Irix and Linux, but Steve Lord of SGI was part of the kernel 2.5 developers conference presenting the idea of adopting XFS' ACL approach in the core VFS (virtual filesystem) layer of Linux 2.5 itself (so all filesystems could benefit). This should tell everyone about the capabilities XFS brings to the Linux table for all Linux filesystems to benefit from.
In addition to ACLs, quota support is production quality. Not only does XFS have full, VFS-compatible quote support, but XFS is now a supported fs in the official Linux Quota project's CVS repository (and future releases). This should further drive home the fact that XFS can be and is being easily integrated into standard, stock Linux.
XFS is fully LILO compatible, meaning a system, with or without a separate/boot filesystem, can be completely XFS. In addition to being XFS root bootable via in-kernel compilation, the three core XFS components can be compiled as modules, and loaded via an initrd (initial root disk) instead. No "performance hidering" options are necessary for this compatiblity (unlike ReiserFS and its "notail" option).
Disclosing the few disadvantages and issues with XFS
As much of a XFS advocate as I am, I am also quick to honestly and complete disclose each and every "disadvantage" or "issue" with XFS. Note that they are few and usually non-issues in most situations, although XFS is no more of an "universal JFS for applications" than ReiserFS is (and I would and should be considered a "XFS Absolutist" if I didn't). Specifically, I find the following disadvantages to and issues with XFS:
Although XFS sports some excellent performance number in certain operations (especially large files and random writes), XFS' inherit design makes it horrendous at deleting lots of small files, even versus Ext2 (and specifically against ReiserFS where ReiserFS excells). This makes XFS a less than ideal JFS solution for caching/temporary/log filesystems (e.g.,/tmp and/var) and applications/services (like Squid proxy cache/filtering servers) -- although I have found that a XFS/tmp and/var "feel just as fast" as Ext2 on workstations (haven't done extensive testing on servers yet). Since this is a design flaw in XFS' structure itself (although that same design allows faster operations and performance in other areas;-), in the future, I hope both XFS and ReiserFS will be part of the same, stock kernel releases so I can use XFS on data and application partitions (like/home,/usr,/usr/local,/opt, etc...) that are XFS exported, and ReiserFS on local, non-exported support partitions (like/tmp and/var -- although I will probably leave/var/spool XFS since most operations, like print jobs, are large files).
The size of XFS' code base is very large, resulting in a ~1MB support module set -- too big to fit the initrd on a floppy with the kernel, or just barely small enough to fit compiled-in kernel that sports little else on a floppy. Although I'm fairly sure this may be just a short-term fact of a "first port" -- I being a true believer in "get the sucker running, then optimize code size" and XFS is currently one of those codebases where many routines are redundant throughout the code. But the size of the code base and binary does not affect overall run-time performance as various XFS benchmarks prove -- which supports my theory that the current Linux port is simply an un-sized-optimized release that will improve in the future.
Although XFS is fully LILO compatible, it is only LILO compatible when LILO is used in the MBR (master boot record). Those of us who like to use 3rd party boot managers and put LILO at the beginning of the root (or/boot) partition will find that this is not an option with XFS if the root (or/boot) partition is XFS. To use a 3rd party boot manager, the root (or/boot) must be Ext2 on XFS systems (although I believe ReiserFS is in the "same boat" here as well?).
The final analysis
SGI's XFS is a powerful, stable and feature-packed JFS that is mission-critically proven on Irix and now available for Linux. It brings a wealth of features and traditional UNIX fs compatibility to Linux, while only sporting a few, less than optimal attributes in some limited areas. Being that SGI has gone to great lengths to synchronize its codebase with the common codebase of the projects it integrates with, and some of these projects (notably Quota and Samba) have adopted native support for it, many XFS users are starting to question why XFS has not become an option in our favorite distributions.
As such, I urge RedHat and VALinux, two companies who currently favor Ext3 and spurn ReiserFS for specific issues that XFS does not have, to consider beta testing and offering XFS as an option for their distributions and systems. As the 2.4 kernel matures and gains widespread acceptance, those of use who cannot adopt ReiserFS will need a solid replacement for Ext3 coming from kernel 2.2. And the additional enterprise-driven features of XFS make its consideration that more inviting.
I thank you for your open consideration of this article.
Kinda off topic here, but I want to suggest to you that you go back to nVidia release 0.9-6, instead of using the latest 0.9-769 release. I ran with the former for 2 months, with lockups being extremely rare. After 3 weeks of running with 0.9-796 and locking up reguarly, I de-installed it and went back to 0.9-6. I'm so glad I did.
Just a recommendation. I find 0.9-6 to much more rock solid than 0.9-769 under any kernel, 2.2, Ext3-patched 2.2, 2.4 or XFS-patched 2.4 releases.
MacMillian's "Unleashed" series is designed to cover everything. This includes having multiple experts and any "redundancy" being "welcomed."
Why? Simply put, the book is so thick (1,248 pages), most users are only going to move to the chapter they need. As such, you canNOT assume they read previous chapters anyway. So having multiple authors is not an issue (as long as there is only one author per chapter).
I hear you! I got to save Steve Litt (my good friend and regular flamemail target;-) in March [2000] by writing Chapter 33 (~45 pages) in a weekend (after another contributing author "flaked" -- which is quite common). I also did Appendix A and B (the ones on Solaris and BSD), although I had plenty of time to write those (pretty much all of January [2000], for only ~30 pages total).
So, as far as myself, I'm good for about 1 productive page/hour (including proofreading/revisions/reorg) -- and I assume other people are in the same boat. That means 3-4 chapters are possible per week, if you don't have a regular, 40hour/week job (which I do).
Yes, the Word markup really pissed me off, crashing numerous times resulting in no less than 2 total losses of my file (luckily I exit and save the file to a different directory every 15 minutes). The sad thing is that I regularly use LyX for all my personal and semi-professional technical writing. LyX which produces LaTeX, which is probably what they were parsing the Word back into for final publication -- quite ironic IMHO.
As far as "compensation," did you read your contract? I was under the impression that you should NOT reveal any compensatory info to anyone else! Oh well, here's the "unwritten rules" on compensation:
Contributing authors (1-5 chapters, usually 3-10 in any publication) get a flat rate, no advance.
Main authors (10-50 chapters, or co-authors, meaning only 2, possibly 3, total) get a flat rate and/or royalties, possibly with an advance (along with their name on the cover;-).
Compensation is relative to your authoring experience. [ Mine was none, so I did it for the exposure -- the "rate", based on my 1 product page/hour, was quite a "pay cut" from what I'm used to.;-PPP ]
Again, the contract forbids you from devulging this info in public. [ I'll assume MacMillian is "done with you" now;-P ]
SVG (Scalable Vector Graphics) is the preferred W3C standard for vector graphics. I recommend converting to this standard instead. You can get Adobe's free SVG viewer for Netscape/IE (Mac/Windows-only though). Mozilla also comes with SVG support (although you usually have to add it in yourself from the codebase -- haven't checked the latest 0.8 for inclusion though). There are numerous programs for UNIX that do SVG import/export (almost all the major Qt/GTK+ vector graphics programs do), and support seems to be increasing in Windows programs (although I haven't seen it in Visio, but I might be one version back now).
One more thing, I forgot to mention the obvious thing about THX-1138. You enter the equation in the handwritten-like notation (free-form, multiline) at the top, then hit "Numpad =" (or Math -> Evaluate from the menu) and it will spit out the one-line version (e.g., "5/(2+3)") at the bottom (and evaluate it if possible). You could then cut'n paste this in your entry box.
Being out of college now, I don't run into this too much. And my trusty HP 48/49 RPN calculator keeps me from writing too much down when I do. But this is an interesting question that I will probably pursue for you (because I want to do it for myself since I regularly consider switching to teaching). In the meantime, I offer these leads (feel free to contact me directly), although it's NOT a direct answer to your question.
As you mentioned, LaTeX is less than ideal. But even those that do not like LaTeX like LyX. LyX is a WYSIWYM (what you see is what you mean) TeX/LaTeX, SGML/DocBook, HTML, etc... editor for UNIX (and Windows if you have an X-Server like eXceed). It can export HTML c/o its integrated (as of v1.1.6) TTH (TeX to HTML) export. TTH produces multiline equations usually in standard HTML. So I guess using LyX and its export, people can generate HTML and cut'n paste the resulting HTML into their text box on your site (or export and cut'n paste LaTeX for that matter). Maybe you can take the LyX/TTH source (which is GPL) and tailor the app.
Another interesting program that I think does NOT have HTML export features (but is interesting none-the-less) is Net Planet Software'sTHX-1138. NPS has a clean X-Windows C++ framework called JX built right atop of plain'ole Xlib. THX-1138 is a "quickie, but goodie" program written in this framework and is a nice, equation writing features. Although I did not see an HTML export feature, it can export EPS (encapsulated postscript -- a size-efficient vector graphics format for printing) which can be used for conversion to another graphic format -- like a small, vector-based graphic format (so you don't have to worry about size/resolution issues with bitmap graphics).
I'm sure there are many, many other examples, probably ones not so UNIX-focused either (I run Linux 100% of the time -- and support UNIX at work -- sorry). I'll let you know if I find anything else.
One thing I can honestly say about Fujitsu, they don't play stupid "100% Sun" games like Sun does -- E.g.,
My local (Orlando, FL) Sun sales/support office is right across the hallway from my company (yes, a whole 20 feet!). I made the grave mistake of going over and asking for a SunSolve CD once. They started asking me for Host IDs, and said that since I had clones (alongside separate, 100% Sun hardware) in the same office, they could not give me one. And what really ticked me in the end was the sales rep trying to sell me a new box! Geez, I just wanted to ask for a SunSolve CD so I would have to avoid downloading a lot of the patches (our Internet bandwidth was limited at the time) and I got my head bit off! Imagine if I really had an issue?!
Fujitsu sells some excellent, re-designed SPARC modules and boxes. In fact, I would argue that if eBay would have gone Fujitsu instead of true Sun, they probably wouldn't have had their "oopses" awhile back with Sun's inadequate airflow causing the ECC cache memories to fail. Their systems are of much better designs, industrial quality and usually cheaper in the end. And, again, their support doesn't bog you down with "100% Fujitsu" questions -- they get right to the problem and help you resolve it.
As such, I'll almost always buy Fujitsu over Sun. And they can (and did) quote me on it (see page 2). Yes, I also support and use x86/Linux, and we are slowly moving away from Solaris as more and more EDA tools are ported to it, but I still need to buy SPARCs on occassion. Fujitsu will continue to get the bill for SPARC.
-- Bryan "TheBS" Smith
Some new DDR boards have both memory slots ...
on
Is DDR Worth It?
·
· Score: 2
Just want to point out the fact that many new DDR boards have both the 184-pin DDR SDRAM slots and older 168-pin SDR (i.e. "normal") SDRAM slots. Of course you have to choose one or the other when you buy/install, but it's still nice to have the option (and upgrade path).
In addition to dual-SDR/DDR support, you'll get a better and wider range of supported SDR types. Why? VIA makes most of the chipsets on these boards and even the older SDR memory interface and memory compatibility matrix has been improved with the newer chipset.
Slashdot Mirror
The problem isn't immigrants in general, it's underpaying immigrants so they can replace higher salaried Americans! That's what H1B VISA's promote! The IEEE has been trying to get this fact out, but people think it's an immigration v. anti-immigration issue. Not so! It is more complex than you realize -- and American companies are here to dupe you! Trust me, immigrants, the IEEE-USA is your friend in this!
What the IEEE-USA does is actually promote giving real green cards to immigrants who are engineers instead of H1B VISAs. They recognize the real problem and how companies abuse the H1B VISA system whereas they cannot "abuse the system" with green cards. Unlike H1B VISAs where companies can "put the screws" to immigrants who cannot change their sponsor, so they work for less, so they can replace Americans. So why does this matter?
Green card holders can change jobs so they demand the same salaries as Americans! As such, Americans don't get fired, nor do their salaries decrease! Green card immigrants are only brought in to augment them as necessary and become Americans themselves. H1B VISAs are used to temporarily gain access to lower-costing employees and destroy America in general for corporate profits (this still happens despite the supposed "loophole changes" in H1B VISAs). The IEEE promotes an "accelerated program" to allow real engineers to get green cards faster than the normal process. Linux Torvalds is one of their "poster childs" showcasing the enormous amount of BS he had go through.
Furthermore, they have tried to "educate" the public on a "technician" and the so-called "IT shortage" versus "engineers" who do not deal with IT!
No one in the world has the unique perspective to put a technical or financial focus on a political problem (e.g., VISA and green cards -- the IEEE has a very insightful view into those that most people don't know ;-). The IEEE has its own political action committees (PACs) and other lobbying efforts which many members pay for by default. So let's not get into the BS about the IEEE "not being able to do anything."
In case people are curious, I've written further under the original Newsforge post here: "The "IEEE has quite a lobbying effort ..." and "That's not what an IEEE member does ..."
Not bad, #27. But if you look at the SE US Regional Standings, we look even better! #1, #4 and #7 -- our undergrad teams regularly beat other SE US graduate teams. UCF has represented the SE US at the world finals for most of the competition's history, including they heaftier competition of more recent years.
UCF has never won #1, but they took #2 in 1987 and #4 in 1986 back in the Early Years. In the '90s, we've broken the top 10 at world only once or twice, but we've managed to place in the top 25 regularly.
At every hackfest, I had at least 2-3 people ask about my Loki games, "Are you allowing people to copy this?" Com'mon! I too bought most of my Loki games direct for $25-50, and picked up a few others at EB for $10-20.
Of couse, the game market just had too thin of margins for Loki to survive regardless. I'm glad to see independent developers signing NDAs with game makers to make Linux ports though. Hopefully the major houses will start doing their own soon enough.
I'm not a Mandrake fan, nor do I use it. But I've gotta side with Mandrake in this one, because it's obvious some of you are taking their goodwill too far. I pay RedHat the similar $60/year, the lowest level, for priority downloads and other services. I don't expect anything more, nor should you Mandrake $60/yearers after reading their agreement.
Reality check people! $60/year does NOT entitle you to a product that is almost $100 on the retail shelf. I don't care about OEM licensing, Mandrake has got to make money! Furthermore, that $60 probably barely covers all the other services and benefits provided. Lastly, the statement of "receive the same benefits" would most likely extend to only Mandrake products and services, and NOT 3rd party products and/or services. Otherwise, Mandrake would go "belly up" (actually all distros seem to have a constant loss after all expense considerations, even RedHat).
Frankly, Mandrake should be commended on allowing StarOffice to be downloaded as an .iso thanx to membership, and Sun for licensing it to Linux distributors so they can do so. Man, I'm really getting sick of
this "whining" crap. Some of you "whiney" Linux users need to go! At least before most of the good, GPL-focused commercial organizations cannot sustain your selfishness!
2/3rds of the states bother to "show up" and ultimately represent the underlying balance of and right to local judgement. Chalk up another one for freedom, regardless of what you think of this trial in general. I guess the US still has more life to it than I previously thought.
See my other post. While the DVD consortium standardized on DVD-R and DVD-RAM back in the early '90s, Sony/Philips saw an opportunity to break away from the consortium. One reason was that Pioneer's DVD-R, DVD-R(A) at the time, was expensive ($10K+!), and Panasonic's $500 DVD-RAM was designed for optical archiving (long story, but its not designed for consumers), and could only hold 2.6GB/side at the time. Sony/Philips had a 3GB design that could also record/rewrite CD-R/RW as well. They called this "standard" DVD-R+W
But Sony/Philips soon "woke up" to the reality of their design took too long to build -- over 3 years! By the time their 3GB drive was ready to "hit the market" in 2000, Panasonic had delievered its sub-$500 2nd-gen 4.7GB/side DVD-RAM drive and Pioneer released sub-$1K DVD-R(G) drive. So the 3GB DVD-R+W drive never saw the light of day, and S/P went "back to work" on an "improved" DVD-R+W drive. This would become DVD+RW
Well, even before DVD+RW finally hit in 2001, Panasonic had released a 3rd gen DVD-RAM which was a 2nd gen DVD-RAM + DVD-R(G), and Pioneer had come out with its consumer DVD-RW drive, which also did CD-R/RW as well as DVD-R(G). So basically DVD-R(G) _is_ the standard for recordable DVD, and DVD-RW is the consumer rewritable, and DVD-RAM is the optical archiving rewritable.
Now you've got the requirement of a second gen DVD+RW drive just to get DVD+R. And I haven't seen any compatibility testing to show its as good as DVD-R. If DVD+R is only as compatible as DVD+RW, then it's only around 70%. Although that is the same as DVD-RW, and much better than DVD-RAM), it's still not as good as the 99.9% compatibility of DVD-R(G), which is now done by _all_ competiting drives. Worse yet, you can get the 3rd gen Panasonic drive for less than $300 and the rewrite capability it has been working in Linux for years (and cdrecord/DVD-R(G) is in beta testing).
Sony/Philips has proven they are consistently "behind the times" and they flat out make promises they canNOT keep! As such, this whole DVD+R announcement does NOT shock me at all.
Guys, this is nothing new. As someone who has had a DVD-RAM drive, working in Linux since 1998, I've followed Sony/Philip's "non-standards" since 1995.
They "broke off" from the DVD consortium and introduced a 3.0GB DVD-R/W "standard" that never shipped back in 1999. They have broken promise after promise after promise, again and again and again. I figured DVD+R would be more of the same -- and we've yet to see the "compatibility" tests to see if it is "as good" as DVD-R(G).
Meanwhile, both Panasonic DVD-RAM (3rd gen, 2001) and Pioneer DVD-RW (2000) drives write DVD-R(G), a near-100% compatible standard. Not only are 3rd gen DVD-RAM drives sub-$300, but the DVD-R(G) disks are sub-$3/each! And the cdrecord 1.11 test releases support DVD-R(G) recording.
If you just need backup, DVD-RAM works great in Linux now as a "packet writer" (i.e. like a generic, random access disk -- has for 4 years!) and has a longer shelf-life (especially in the 2-sided, cartridged version) with 100x the rewritability of either DVD-RW or DVD+RW (100,000x v. 1,000x). Unfortunately, it's not player compatible (because they don't have the added logic and laser wavelength required) because it was designed as the new, universal, optical archiving format (and not a consuemr one). Hence why it's for archiving, not consumer use.
You should really compare Pioneer 10 v. Galileo, Cassini or other, similar-costing, "full QA" projects from NASA. The "better, faster, cheaper" Mars probes that gained a lot of noteriety in their failures are NOT good comparisons based on their cost and lack of equivalent QA/testing.
Simple engineering risk analysis showed NASA that the orders of magnitude in additional cost are worth it to guarantee an over 99% chance of success, versus less than 50% in the BFC approach. NASA will no longer attempt to build probes like those three Mars BFC projects (of which, only one was a success) again.
Now I feel there is no excuse for RedHat users such as myself not to help fund RedHat.
In praise of 100% GPL-focused RedHat
RedHat, despite what you might think of their distro or business-side tactics, funds probably the greatest number of 100% GPL software developers (since VA no longer does). I cannot stress enough the importance of this fact. Every distro enjoys the fruits of RedHat employee labor, and not just Gnome developments either.
Imagine the number of developers that could be hired
For every 2,000 people who sign up for the service, that's $120K/year for RedHat. Figuring half of that goes to upgrades to their network infrastructure to support the additional downloads, that leaves $60K to fund another developer on-staff. If all 2 million RedHat sysadmins (my estimate is 2M, which equals ~20M installs, ~10 installs/per sysadmin on average) coughed up $60/year, that's $120M/year for RedHat. That could equate to adding $60M for developers, or about a thousand employees!
Personal note
I've been a total RedHat leech here. Although I have worked for various companies who have paid for Cygnus tools (Cygnus is a division of RedHat), I've pretty much only bought the boxed sets on every .2 release (and I haven't bought 7.2 yet). I've been running RedHat on this system
(through various hardware upgrades) since 4.2, only re-installing once to move to XFS (RedHat 7.0.92 + XFS 1.0 betas was a "clean" install).
I've installed RedHat on close to 500 systems now, and I'm sure well over half of those are still in use. So that amounts to about $0.10 per system I've installed. Definately not enough IMHO. I want to change this. This is a great avenue to do so.
As your momma always said: 'If you don't have anything good to say about someone, don't say it' or 'if you someone keeps "bothering" you, just stay away from them.' It's as simple as that.
So if you don't like Richard Morrell, head of the SmoothWall project, consider:
Personally, I'm sick of the "one-sided" reporting on Mr. Morrell. I've seen way too many people "complain" about him, but never comment on various personal details that are partially the cause of this -- let alone the daily on-slaught of Windows users who've barely heard of Linux, who don't bother reading the FAQ, let alone demand that SmoothWall automagically support every little, crappy-designed Windows application and their proprietary protocols that don't work well with firewalls anyway. After a week of being on the SmoothWall lists, I'd kill some very rude and ungrateful users well before Morrell. If you feel Morrell is "really bad for the project," then that's his problem, not yours!
Now if you still want something like SmoothWall without the SmoothWall(TM), take notice that others have forked the project into a new one called IPCop. Version 0.1.0 features SmoothWall 0.9.9, all the major post-0.9.9 patches and various enhancements. A final 0.1.1 release is to follow shortly before the team starts to work on version 0.2.0, an Linux 2.4/Netfilter implementation.
For all I care, you can think of IPCop as "SmoothWall without Morrell." Just don't say it outloud since many of us are all sick of hearing it!
One thing I've been able to do is stump MS every time. Several times I've gotten the answer "our OS don't let you do that," and my superior's jaws would just drop! It's one of the reasons why we've had to chuck MS products in many applications.
-- Bryan "TheBS" Smith
In addition to the "ReiserFS absolutists" who know little about XFS, it seems we also have so "SCSI RAID absolutists" here who know little about 3Ware microcontroller-driven RAID controllers. So a little education is in order.
First off, most of the "dumb, BIOS-only" IDE RAID solutions do "suck." Since they are still just a "dumb" IDE controller, they still off-load computational and other details off to the CPU, which is still, ultimately, driving the drives. So they still inherit all the limitations of IDE, including the 128GB max addressing limitation. Worse yet, nearly all of these solutions allow more than one drive per channel with just kills performance (especially in the 4 drive, RAID-0/1 implementations).
Fortunately, 3Ware and a few select others have built real host adapter solutions, except they use IDE drives. With that small exception, they are almost exactly like more expensive, SCSI-based RAID controller solutions. They have an on-board microcontroller that not only off-loads all the computational details, but drives the IDE disks directly. As such, the 3Ware card, for all intents and purposes, is a SCSI controller from the OS' perspectively, including support for upto 2TB device sizes. The OS never sees the underlying hardware itself, which also allows these devices to emulate advanced SCSI features like command queuing, threading and even sector remapping.
The 3Ware Escalade 6000 series comes in 2, 4 and 8 channel versions, with one device per channel, at a cost of about $60/channel. 3Ware support is included in all the latest 2.2 and 2.4 kernels from most distros (and in most stock Linux kernel releases as well). Although Adaptec now has a similar, 4-channel product (that does RAID-5 as well?), I have not seen Linux support for it. In the near future, 3Ware plans on introducing a new product series with RAID-5 support (current Escalades can only do RAID-0, 1 or 0/1).
-- Bryan "TheBS" Smith
My appologies for the typos including the use of "XFS" when I meant "NFS" in a few places. This post has been moderated upto to 5, and I have received numerous direct mailings -- all positive, unbelievable! This has restored my faith in /., who I was privately boycotting until I saw the XFS /. discussion mention on NewsForge.
What I am really "arguing for" here is not a "what is better" or a "why is ReiserFS in kernel 2.4.1+ and not XFS?" 'jealousy' attitude (as Hans Reiser recently called it ;-), but a simple "call on RedHat and VA Linux to start looking at XFS." I do not think it is my business to question Linus non-inclusion of XFS in the kernel, as he has a better understanding that I. All I'm asking for is the industry to start supporting something that obviously works for a good portion of us.
Especially now in light of layoffs at SGI, which can only mean a reduction in direct support of XFS by them.
-- Bryan "TheBS" Smith
Whether you agree with it or not, RedHat and VALinux alike have spurned adopting ReiserFS despite its inclusion in the stock Linux kernel as of 2.4.1. Both vendors have courted the more "evolutionary" Ext3 kernel for 2.2 releases, but Ext3 is not the future of JFS' on Linux. As such, I offer this article in a plea for RedHat and/or VA Linux to begin consideration and formal testing of XFS as a viable JFS for their future, kernel 2.4-based product releases.
I have been integrating and maintaining production NFS/SMB UNIX servers and networks for years. As such, I ask that some of the "ReiserFS absolutists" (i.e. believe only ReiserFS should exist as every other JFS for Linux is "not as good" in their opinions) out there, who don't use Linux's kNFSd services in a heavy production environment (especially with non-Linux NFS clients) like myself, please not blindly comment on this post. Remember, every OSS project "itches a scratch," and there is a reason why Tweedie's Ext3 and SGI's XFS exist in addition to Namesys' ReiserFS (disclaimer: I know little about IBM's JFS).
Because I have UNIX NFS clients, ReiserFS was quickly identified as a "non-viable solution" for my needs (not that it is not applicable in many other areas, no sir, so don't flame me!) when I first looked at JFS' in early 2000. Although ReiserFS is very innovative in design, which includes a recent DARPA grant to extend these capabilities, its lack of a traditionally keeping meta-data in the inode itself results in a host of traditional UNIX service and VFS incompatibilites. So I ended up testing the early, full data journaling (aka Ext3 "v1 mode") Ext3 releases (e.g., 0.0.2f) for 3 months on non-critical systems with great success. I eventually adopted it on my main fileservers in summer of 2000 and it has worked flawlessly since. I even had a physical disk error, which my RAID controller did not catch for 24 seconds (long story, the firmware and driver versiuons was out of sync, my fault) and I was able to drop down to the full Ext2 fsck to fix things.
For people like me, Ext3 is a nice, "evolutionary" approach to journaling that significantly reduces the variables involved -- important to some of us that don't embrace "change" so quickly (for obvious reasons ;-). Ext3 is also a quick upgrade for existing Ext2 filesystems (get Ext3 kernel, e2fsprogs aware version, create the journal file, and mount as Ext3) plus complete reversable back to Ext2 (just delete the journal file and reset some superblock variables), which meant I could "switch back at a moments notice." I find the VA Linux kernels with Ext3 added (along with NFS v3, unified IDE and other 2.4 backports to 2.2) most excellent, and longtime Linux kernel NFS guru H.J. Lu (now formerly of VA) takes the time to make the appropriate RedHat RPM kernels for us RedHat users (shortly after HJL's departure from VA, I began hosting his kernels). VA Linux uses Ext3 in their enterprise NAS device products (actually based on not a RedHat kernel, but SuSE!), although RedHat's adoption of Ext3 has been limited to a public beta, and installer/BOOT kernels that are simply "Ext3 aware."
Today, Ext3 is still a kernel 2.2-only solution. And it still "inherits" all the "limitations" of Ext2 -- so it is not ideal where features are more important that minimizing variables. Now it's not that I've adopted kernel 2.4 on my most critical services, as it is still maturing IMHO (not bashing 2.4 at all, but as more systems run it, more "issues" are identified that were not before), but it would still be nice to have on some of my more "bleeding edge" workstations. I would be satified if Tweedie would only port the full data journaling (v1 mode) capability to 2.4, although I heard he purposes held off on the kernel 2.4 port and Ext3 1.0's release until 2.4 itself "stabilized" in his view (of which, I've heard many good reasons for doing so). If anyone has any insight to all this, I'm all ears (as I can only "assume" things here from what I've heard).
As such, that left me with re-evaluating ReiserFS for 2.4 systems, now in the stock 2.4.1 kernel, or possibly SGI's XFS or IBM's JFS. I looked at ReiserFS only to discover that the stock kernel does not include the kNFSd workaround patches. Furthermore, many ReiserFS users were still plauged with NFS and even quote issues, even after patching. This tends to make me believe that it will still be awhile before specific Linux subsystems "better accomodate" ReiserFS completely for certain users (like myself), although it is a viable solution for most standalone workstations or Windows-centric file servers. Even I am using ReiserFS on a kernel 2.4 Netfilter firewall and Squid Proxy cache/filter, where it excels (but does no direct network file serving duties).
This led me to SGI's XFS. Mid February saw the release of kernel 2.4.2 and, by the weekend of the 24th, SGI had already adopted 2.4.2 as the base of their XFS development CVS repository. I was impressed with this attention to keeping XFS' development as close to the stock kernel as possible. I decided to check out the kernel, compile and test it on a few older and newer systems, and ended up writing an RPM spec file and releasing some RPMs for RedHat 7.0 at the time (since it has been a couple months, using 2.4.0pre kernels, since SGI had done so). Thus I began my standard "three month evaluation" of XFS in early 2001, like I did with ReiserFS and Ext3 in early 2000.
It did not take me long before I was impressed with SGI's XFS implementation. Most specifically:
Shortly after my RPM releases for RedHat 7.0, SGI began a series of test releases for the RedHat 7.1 beta (first Fisher, 7.0.90, and then Wolverine, 7.0.91) in March and April, and eventually RedHat 7.1 itself. Like the 2.4.0pre kernel releases before them, RedHat releases XFS in a three fold scheme:
As of May 1st, XFS Release 1.0 was released. In following their three fold release venue, it includes a ~300MB additional ISO CD for installing with RedHat 7.1. But instead of patching XFS against just the stock Linux kernel, SGI took the time to take the RedHat 7.1 2.4.2-2 RPM kernel release and patch it against that (they actually did this with 1.0-Test3 as well) -- inheriting and benefiting all the patches and other kernel decisions that RedHat makes. This is very important to system administrators like myself which only trust RedHat releases and kernels for heavy file server duties (please, no flames on this -- I'll list reasons off-list, and I *DO* recommend Mandrake and, increasingly, Debian for many other purposes).
As such, I am surprised that RedHat and, especially, VA Linux have not taken a closer look at evaluating and, gulp, even supporting XFS's development on kernel 2.4. XFS is the natural upgrade for these two firms, being that both have spurned supporting ReiserFS for its non-traditional and troublesome design with traditional UNIX services and capabilities like XFS. In addition to design attitude, features and other considerations SGI has made in porting XFS to Linux as I made above, I would like also point out the following, additional considerations:
As much of a XFS advocate as I am, I am also quick to honestly and complete disclose each and every "disadvantage" or "issue" with XFS. Note that they are few and usually non-issues in most situations, although XFS is no more of an "universal JFS for applications" than ReiserFS is (and I would and should be considered a "XFS Absolutist" if I didn't). Specifically, I find the following disadvantages to and issues with XFS:
SGI's XFS is a powerful, stable and feature-packed JFS that is mission-critically proven on Irix and now available for Linux. It brings a wealth of features and traditional UNIX fs compatibility to Linux, while only sporting a few, less than optimal attributes in some limited areas. Being that SGI has gone to great lengths to synchronize its codebase with the common codebase of the projects it integrates with, and some of these projects (notably Quota and Samba) have adopted native support for it, many XFS users are starting to question why XFS has not become an option in our favorite distributions.
As such, I urge RedHat and VALinux, two companies who currently favor Ext3 and spurn ReiserFS for specific issues that XFS does not have, to consider beta testing and offering XFS as an option for their distributions and systems. As the 2.4 kernel matures and gains widespread acceptance, those of use who cannot adopt ReiserFS will need a solid replacement for Ext3 coming from kernel 2.2. And the additional enterprise-driven features of XFS make its consideration that more inviting.
I thank you for your open consideration of this article.
-- Bryan "TheBS" Smith
Kinda off topic here, but I want to suggest to you that you go back to nVidia release 0.9-6, instead of using the latest 0.9-769 release. I ran with the former for 2 months, with lockups being extremely rare. After 3 weeks of running with 0.9-796 and locking up reguarly, I de-installed it and went back to 0.9-6. I'm so glad I did.
Just a recommendation. I find 0.9-6 to much more rock solid than 0.9-769 under any kernel, 2.2, Ext3-patched 2.2, 2.4 or XFS-patched 2.4 releases.
-- Bryan "TheBS" Smith
NO! Only the original copyright holder on software can give his/her copyright to Microsoft. God, my article is getting out of hand!
I'm putting up a new version (with the INcorrect statement about "license revocation" removed).
-- Bryan "TheBS" Smith
MacMillian's "Unleashed" series is designed to cover everything. This includes having multiple experts and any "redundancy" being "welcomed."
Why? Simply put, the book is so thick (1,248 pages), most users are only going to move to the chapter they need. As such, you canNOT assume they read previous chapters anyway. So having multiple authors is not an issue (as long as there is only one author per chapter).
-- Bryan "TheBS" Smith
I hear you! I got to save Steve Litt (my good friend and regular flamemail target ;-) in March [2000] by writing Chapter 33 (~45 pages) in a weekend (after another contributing author "flaked" -- which is quite common). I also did Appendix A and B (the ones on Solaris and BSD), although I had plenty of time to write those (pretty much all of January [2000], for only ~30 pages total).
So, as far as myself, I'm good for about 1 productive page/hour (including proofreading/revisions/reorg) -- and I assume other people are in the same boat. That means 3-4 chapters are possible per week, if you don't have a regular, 40hour/week job (which I do).
Yes, the Word markup really pissed me off, crashing numerous times resulting in no less than 2 total losses of my file (luckily I exit and save the file to a different directory every 15 minutes). The sad thing is that I regularly use LyX for all my personal and semi-professional technical writing. LyX which produces LaTeX, which is probably what they were parsing the Word back into for final publication -- quite ironic IMHO.
As far as "compensation," did you read your contract? I was under the impression that you should NOT reveal any compensatory info to anyone else! Oh well, here's the "unwritten rules" on compensation:
[ Mine was none, so I did it for the exposure -- the "rate", based on my 1 product page/hour, was quite a "pay cut" from what I'm used to.
[ I'll assume MacMillian is "done with you" now
-- Bryan "TheBS" Smith
SVG (Scalable Vector Graphics) is the preferred W3C standard for vector graphics. I recommend converting to this standard instead. You can get Adobe's free SVG viewer for Netscape/IE (Mac/Windows-only though). Mozilla also comes with SVG support (although you usually have to add it in yourself from the codebase -- haven't checked the latest 0.8 for inclusion though). There are numerous programs for UNIX that do SVG import/export (almost all the major Qt/GTK+ vector graphics programs do), and support seems to be increasing in Windows programs (although I haven't seen it in Visio, but I might be one version back now).
-- Bryan "TheBS" Smith
One more thing, I forgot to mention the obvious thing about THX-1138. You enter the equation in the handwritten-like notation (free-form, multiline) at the top, then hit "Numpad =" (or Math -> Evaluate from the menu) and it will spit out the one-line version (e.g., "5/(2+3)") at the bottom (and evaluate it if possible). You could then cut'n paste this in your entry box.
-- Bryan "TheBS" Smith
Being out of college now, I don't run into this too much. And my trusty HP 48/49 RPN calculator keeps me from writing too much down when I do. But this is an interesting question that I will probably pursue for you (because I want to do it for myself since I regularly consider switching to teaching). In the meantime, I offer these leads (feel free to contact me directly), although it's NOT a direct answer to your question.
As you mentioned, LaTeX is less than ideal. But even those that do not like LaTeX like LyX. LyX is a WYSIWYM (what you see is what you mean) TeX/LaTeX, SGML/DocBook, HTML, etc... editor for UNIX (and Windows if you have an X-Server like eXceed). It can export HTML c/o its integrated (as of v1.1.6) TTH (TeX to HTML) export. TTH produces multiline equations usually in standard HTML. So I guess using LyX and its export, people can generate HTML and cut'n paste the resulting HTML into their text box on your site (or export and cut'n paste LaTeX for that matter). Maybe you can take the LyX/TTH source (which is GPL) and tailor the app.
Another interesting program that I think does NOT have HTML export features (but is interesting none-the-less) is Net Planet Software's THX-1138. NPS has a clean X-Windows C++ framework called JX built right atop of plain'ole Xlib. THX-1138 is a "quickie, but goodie" program written in this framework and is a nice, equation writing features. Although I did not see an HTML export feature, it can export EPS (encapsulated postscript -- a size-efficient vector graphics format for printing) which can be used for conversion to another graphic format -- like a small, vector-based graphic format (so you don't have to worry about size/resolution issues with bitmap graphics).
I'm sure there are many, many other examples, probably ones not so UNIX-focused either (I run Linux 100% of the time -- and support UNIX at work -- sorry). I'll let you know if I find anything else.
-- Bryan "TheBS" Smith
One thing I can honestly say about Fujitsu, they don't play stupid "100% Sun" games like Sun does -- E.g.,
My local (Orlando, FL) Sun sales/support office is right across the hallway from my company (yes, a whole 20 feet!). I made the grave mistake of going over and asking for a SunSolve CD once. They started asking me for Host IDs, and said that since I had clones (alongside separate, 100% Sun hardware) in the same office, they could not give me one. And what really ticked me in the end was the sales rep trying to sell me a new box! Geez, I just wanted to ask for a SunSolve CD so I would have to avoid downloading a lot of the patches (our Internet bandwidth was limited at the time) and I got my head bit off! Imagine if I really had an issue?!
Fujitsu sells some excellent, re-designed SPARC modules and boxes. In fact, I would argue that if eBay would have gone Fujitsu instead of true Sun, they probably wouldn't have had their "oopses" awhile back with Sun's inadequate airflow causing the ECC cache memories to fail. Their systems are of much better designs, industrial quality and usually cheaper in the end. And, again, their support doesn't bog you down with "100% Fujitsu" questions -- they get right to the problem and help you resolve it.
As such, I'll almost always buy Fujitsu over Sun. And they can (and did) quote me on it (see page 2). Yes, I also support and use x86/Linux, and we are slowly moving away from Solaris as more and more EDA tools are ported to it, but I still need to buy SPARCs on occassion. Fujitsu will continue to get the bill for SPARC.
-- Bryan "TheBS" Smith
Just want to point out the fact that many new DDR boards have both the 184-pin DDR SDRAM slots and older 168-pin SDR (i.e. "normal") SDRAM slots. Of course you have to choose one or the other when you buy/install, but it's still nice to have the option (and upgrade path).
In addition to dual-SDR/DDR support, you'll get a better and wider range of supported SDR types. Why? VIA makes most of the chipsets on these boards and even the older SDR memory interface and memory compatibility matrix has been improved with the newer chipset.
If you're interested in all the details, I cover the broad spectrum of different chipsets and their memory support/issues here. It includes a discussion of VIA's latest Intel/Athlon DDR chipsets and their SDR support.
-- Bryan "TheBS" Smith