433 MHz is right in the middle of the US amateur radio band. As an FCC authorized user of that band, this device and it's kin had best not interfere with me, or I will get them shut down. They are part 15, I am part 97, I win!
What's pathetic is that there was MORE character development and story development (even unto having a story arc over the whole season) on Buffy than on Voyager.
Just think: if five years ago I'd told you that a show based on the movie Buffy the Vampire Slayer would have better writing than a show based on Star Trek....
Upon consideration, I can thing of exactly one case in which I would accept TimeTraveling Baddies From An Alternate Universe® in the Star Trek Universe.
However, this is somewhat unlikely to happen until CGI gets much better at rendering teeth and curls....
I fevently hope this article is pure BS! I am so damn tired of every Star Drek show being TimeTraveling Baddies From An Alternate Universe®. I was hoping, from the trailers, that Enterprise was going to be more like the STTOS. If this article is even half correct, then it's time to take the Star Trek universe and put a stake through its heart, fill its mouth with garlic bulbs, cut its head off with a gravedigger's shovel, and bury it at a crossroads in blessed ground.
The problem with USB in general that I can see is that the USB design does not have the idea of "standard types".
Consider SCSI: any SCSI hard disk ID's itself as a SCSI mass storage device, any SCSI CDROM ID's itself as a CDROM, any SCSI CDR as a CDR (with the new standards....), etc. I don't have to have a special driver to connect my Quantum Fireball to my SCSI bus.
Now look at USB: I have a USB mass storage device (the docking bay for my NEO-35), a SCSI over USB based scanner, and a USB serial port. Do any of those things have drivers under Linux? Only the serial port. Why? Because there is no standard for USB to SCSI adapters, no standard for USB mass storage devices, no standards IN GENERAL.
The USB design committee basically said "Here's how you read a unique ID from the device. From there, you look in C:\Windows\System, A:; and D: for your DLL". In other words, they basically did half the job of coming up with a standard, taking the "Yer gonna use the Winders Drivers, right?" attitude.
Why don't they establish some standards for devices: Any USB mass storage adaptor must provide these commands, any USB CDR must provide these commands, any USB scanner must provide these commands, any USB to SCSI bridge must provide these commands, etc.
Also, on the subject of the USB HID (human interface device): this is nothing but a big MGI (mogolian group intercourse) - an HID is a thing that does stuff. That's about the extent of the USB spec. How about specifying that an HID must provide a descriptor list in a well defined format (XML, anyone?) that defines what inputs and outputs the device has?
Sorry, but until the various standards committees accept that "Supply a GUID, and the rest is up to Windows" is not enough, things like USB, Firewire, Bluetooth, etc. will not be supportable by anything other than Windows.
As an embedded systems developer, I am disgusted by having to either waste my time writing a million drivers for the things people want to hang off my box, or having to embed Windows.
I would disagree with your statement that "prior art is dead" - the biggest issue is to make sure that your prior art is well established and incontrivertable. The best thing would be to start a section on a high profile location, like your journal here or on Sourceforge, as well as trying to get a story in an appropriate trade journal.
Since we are talking about software radio, I'd suggest writing up your idea, and submitting it to QST (http://www.arrl.org). ANYBODY in the radio profession will read QST (and QEX), and that makes it very hard for a would-be patent scum to say "I didn't see that!".
I'm glad you took my response correctly - I was afraid you'd think I was blowing you off, rather than covering my own ass. If I owned the company, it might be different (hence why if I ever did strike out on my own, I would avoid letting my company become publicly traded: as soon as you become publicly traded, you no longer own the company.).
While I am of the personal belief that any sane individual opposes the DMCA and the trial of Dmitri, I also am opposed to a teacher telling his students they must protest an action. What if some student in your class feels that the DMCA is a good thing, and that Dmitri should "... be torn into little bisty pieces and buried alive!"?
Offer writing letters to the CongressDrone either for or against as an option, or allow them to present a short speech about their thoughts on the case.
Well, as far as telling you more about my project... I'd feel very uncomforable going into any greater detail than the marketing data I pointed to in the main post - there are issues of disclosure.
As for hearing about your idea - same thing. If your idea is close to something we are already working on, then it opens up a huge can of worms. If your idea ISN'T something we are working on, but pertains to what we do, then it's not just a can, it's a barrel.
Basically, if you don't feel comfortable detailing it in a post to Slashdot, then I don't feel comfortable discussing it without running past Legal. Sucks, but that's life in the twenty-first century.
Actually, not as funny as the number of "Overrateds" I get. Just goes to show that Metamoderation really isn't doing as much as it might to keep the moderators honest...
Being able to make "features" as small as 13 um (and remember, "as small as" means this is a lower limit, and includes all sizes larger than this, up to Ringworld and beyond....) does not translate into working transistors at this size. You start getting into quantum tunnelling through the gate oxide because it is too thin, you start getting into a very high on resistance because the channel is too thin, the interconnects start to electro-migrate at 1 volt, etc.
Making small features is only a very small part of making a working chip.
A question to the real lawyers that read Slashdot (paging Dr. Hawk....)
Paetec has a clear statement in their terms of service that prohibts the use of their service in the furthurance of spam. MonsterHut agreed to that TOS as part of their contract, with the obvious intent of violating that TOS. Does not that mean they entered into the contract in bad faith? Does not that mean that MonsterHut committed a tort of fraud? Does not that mean Paetec can bring countersuit?
I have been a long time advocate of ISPs, "free" e-mail services and "free" web hosting sites adding lines to the contracts stating spam is verboten, and then bringing fraud (charges|civil suit) against spammers. I've read on/. that some ISPs try this, but find it difficult to follow through because the spammer just disputes the credit card charge, and the ISP gets in trouble with the credit card company. However, this seems to me to be a deliberate, premeditated violation of a contract on the part of the spammer, and an act of criminal fraud. Especially if the ISP makes the fine large enough, wouldn't that be felony fraud?
OK, so it was several questions. And I know, that any practicing lawyer no more wishes to give out free advice than I wish to give out free computer service, but.... How about a little non-binding, pro bono, off the cuff, YMMV opinion?
Of the three interviewees, Hans knew more about the other guys, he was better able answer what was better about the others then his, and how his was better than the others. The others came off as suits, he came off as an engineer.
I read the "fixed for Netscape" link. It doesn't mention Netscape at all. Is the implication that the contents of the link are fixed for Netscape? One would think that an Open Source development group would understand how to write proper HTML that would render on everything. What, did the main announcement only work on Konquerer?
The big problem with supersonic or better flight for commercial use isn't the fuel economy, it's the fact that many countries (the US being the first that leaps to my mind) don't allow commercial aircraft to fly supersonic over their land at any altitude. Therefor, you either have to land the scramjet at New York, and then fly subsonic aircraft to the rest of the US (assuming you are coming from Europe), or you have to cruse the scramjet subsonic (this is especially true if you are flying from, say, London to Saint Louis) over land.
Also, just because of the stresses involved, a supersonic aircraft will need to be much stronger than a subsonic craft like a 7[47]7. More strength == more cost and more weight (== still more cost).
Also, most scramjets are designed to burn hydrogen, not kerosene (like a commercial jet). Hydrogen requires cryogenic tanks, and has the nasty habit of migrating into the metal, finding any weakness, and setting up shop (a process called hydrogen embrittlement). While hydrogen has a much higher impulse than kerosene per unit weight, it is also more expensive.
Don't get me wrong - I'm looking at going from the US to the UK for a business trip soon, and I'd love to do it in less than eight hours. But I shan't postpone my trip until these things are flying....
In addition, Linux provides better support for new features, which are not supported by the custom OS such as running multiple potentially hostile applications on the same 4758 coprocessor card....
This rather defeats the whole purpose: if you allow a "hostile app" (read: an application you don't control, don't have the source for, and don't trust implicitly (e.g. Windows)) to run on this card, you have just thrown the security of the card out the window. The whole idea is that the crypto functions take place in a secure environment where everything can be trusted. If you want to run Realplayer or something, run it on the host CPU, not the card!
Second, the nit. I work with secure comms products, and the term "zeroize" has always grated on my ears: You zero the keys, you randomize the keys, but you don't "zeroize" them. This is a typical case of the government type making up a word because it makes him sound more important. Yes, I know full well that "zeroize" is the accepted term in secure comms, but it still sounds stupid!
And I agree with several of the posters - I'd like to see this sort of thing work its way into a box next to the computer.
Take this bad boy, a four channel programmable down converter - 4 radios on a chip. You feed in 1 to 4 IF data streams, and this guy will decode them - about 2 billion operations per second, on a chip the size of your thumbnail (micro-ball-grid array). I work with its little brother, the 50214, on my project, and I can't wait until I get past the big stuff and get some time to play.
That's the sick thing about soft radios: you do one down conversion from RF to IF, then digitize it, and from there on it's all math. When you are a ham operator, a math geek, and a software engineer, and you get paid to play with these, well, life is good.
Sat phone airtime will always be expensive. Let me compare sat phones with regular cellphones to show why. First, cell phones. I'll use AMPS (the standard used for cellular service in the US, but GSM isn't that much different for the purposes of this discussion).
A cell base station costs about US$1M. That's the controller, the amplifiers, the tower, the site, and setup.
A base station has up to 1024 channels, at least one of which must be a control channel. Also, no base station uses all the channels: neighboring sites use different channels to prevent interference at the borders. So a site can support roughly 300 simultanious calls (GSM can support about 600 since it uses compression on the voice channel to allow 1 channel to handle 3 to 6 conversations.)
The coverage area for a site is roughly a circle of 1 to 10 miles radius from the site (ignoring geographic features), and can be adjusted by how tall the tower is, how much power the site puts out, etc.
The burden rate (number of user/number of users actually talking) is between 10 to 100 to one. Run too high a burden rate, and customers get "no channel available" when they try to dial. Then they get a new service provider.
So, you need to make a site service about 3000 people, for an initial outlay of US$1M, for a roughly US$300/person outlay. That's not hard to recover
Now, let's look at sat phones:
The cost of a "site" is about US$300M or more. This includes the cost of the bird, the cost of launch, and the cost of failures to launch. You usually don't have the truck delivering the base station to a terrestrial site explode as it leaves the factory.
The number of channels isn't that much different - it's a factor of how complex the receiver and transmitter on the bird is, and the simple physics of radio waves: there are just so many hertz of bandwidth that are suitable for use. So about 300 users at one time per bird.
The coverage radius for a bird is many hundreds of miles in radius. This is a factor of the orbital altitude and the antenna design of the bird.
As for cellular, you want to keep the burden rate down. As a result, you can only have about 3000 subscribers per 100 mile radius, as opposed to the 300 subscribers per 1 mile radius of cellular. You can support a population density of less than one ten-thousandth that of cellular.
Therefor, you now have a cost of US$300M/3000 users, or US$300k per user, a thousand times more costly.
And remember, any advances in vocoder technology, modulation technology, or transmitter technology will benefit both terrestrial cellular and sat phones equally. Except that it is a lot easier to upgrade a terrestrial site than a bird in LEO.
As a result, there will always be far fewer sat phone users than cell phone users. All the non-recurring engineering costs, all the fixed costs of manufacture, all the fixed costs of service will have to borne by fewer users.
Who in their right minds allows for password authentication over SSH? That's one of the first things I disable when setting up SSHD.
If you don't have a private/public key pair, and if your public key isn't in the authorized_keys file of the target machine, then you don't deserve to log on. Tunneling passwords over the system is neither needed nor safe, and not just because of this article's hack.
If you allow SSH to do password authentication, then SSH is little better than Telnet in terms of protecting you from a poorly chosen password. While a sniffer might not be able to extract the password, you can still try a dictionary attack.
Force your users to use a keypair. Force them to put a passphrase on the keypair so that just stealing the key isn't enough.
Remember, the best security is something you are (restriction by host IP), something you have (posession of the private key), and something you know (the passphrase for the key.)
It would have been nice if the article had described what, exactly, the HP additions are supposed to do. We get some vague platitudes about "tightly controlling communications" and "detecting attacks". This could be anything from a well-written iptables setup and a syslog monitor to a full-blown, user-space stateful filtering/SNMP and "page-the-sysop-we-are-being-DDOSed" application.
Does anybody have any REAL info on what HP is doing that is so wonderful?
Does Reiser have something like xfs_fsr? xfs_fsr is a program you throw into a cron job and it will optimize the file system: it copies a file to a contiguous space, then swaps the inodes over. It lets you defrag a file system and move the data around for best access.
I have no direct experience with the battery backed up drives, but here is a typical link:
http://www.buymemory.com/mr35.htm
These things aren't cheap, but they aren't marketed toward your average Joe. However, if I ever get the cash to get a Firewire camcorder, I'd want to do my video editing on a journaled system with the journal on something like this.
Re:I can't wait until XFS is standard...
on
2.4.9 Kernel Released
·
· Score: 3, Informative
My only experience with ReiserFS was on an SMP machine, and it blew chunks (corrupted file system, bad data, kernel panics). I tried XFS and it worked quite well. I've not given Reiser another shot since then (haven't had time). Perhaps they've fixed this bug.
I like the fact that growing an XFS volume to take up more space is simple, and does not require unmounting the volume (in fact, you CANNOT grow an unmounted XFS volume, you MUST mount it first).
So, in a system with hot-swap drive bays, you can add a physical volume to the logical volume group, and just tell XFS to grow. Presto - more space.
I also like the fact that you can move the journal over to another block device. If "you feel the need, the need for speed" you can use a 10MB SCSI battery-backed up SRAM drive for the journal, and a big RAID array for the main storage. Speed and safety in one.
I can't wait until XFS is standard...
on
2.4.9 Kernel Released
·
· Score: 5, Interesting
I can't wait until SGI gets XFS merged into the main tree. I'm running XFS on all my systems, and so I have to wait until SGI gets the changes merged back into their port.
XFS (especially when combined with LVM) is great. No fscks, big files, ACLs, and you can grow a mounted file system (great with LVM and hot-swap drives).
It looks like the/. team learned an important lesson from the first trial of Banjo: never create a list that you get to the top of just by posting.
The amount of journal whoring (posting inane crap to your journal just to get to the top of the journal list) was almost unbelievable. It looks like they've disabled that list.
Of course, I have to wonder what the utility of the journal is, given that I could create a thread at any time on the current slashdot just by entering a URL. I guess that making it an eaiser feature will increase it's use. I'm just not sure that is such a good thing.
Slashdot Mirror
433 MHz is right in the middle of the US amateur radio band. As an FCC authorized user of that band, this device and it's kin had best not interfere with me, or I will get them shut down. They are part 15, I am part 97, I win!
What's pathetic is that there was MORE character development and story development (even unto having a story arc over the whole season) on Buffy than on Voyager.
Just think: if five years ago I'd told you that a show based on the movie Buffy the Vampire Slayer would have better writing than a show based on Star Trek....
Upon consideration, I can thing of exactly one case in which I would accept TimeTraveling Baddies From An Alternate Universe® in the Star Trek Universe.
However, this is somewhat unlikely to happen until CGI gets much better at rendering teeth and curls....
I fevently hope this article is pure BS! I am so damn tired of every Star Drek show being TimeTraveling Baddies From An Alternate Universe®. I was hoping, from the trailers, that Enterprise was going to be more like the STTOS. If this article is even half correct, then it's time to take the Star Trek universe and put a stake through its heart, fill its mouth with garlic bulbs, cut its head off with a gravedigger's shovel, and bury it at a crossroads in blessed ground.
The problem with USB in general that I can see is that the USB design does not have the idea of "standard types".
Consider SCSI: any SCSI hard disk ID's itself as a SCSI mass storage device, any SCSI CDROM ID's itself as a CDROM, any SCSI CDR as a CDR (with the new standards....), etc. I don't have to have a special driver to connect my Quantum Fireball to my SCSI bus.
Now look at USB: I have a USB mass storage device (the docking bay for my NEO-35), a SCSI over USB based scanner, and a USB serial port. Do any of those things have drivers under Linux? Only the serial port. Why? Because there is no standard for USB to SCSI adapters, no standard for USB mass storage devices, no standards IN GENERAL.
The USB design committee basically said "Here's how you read a unique ID from the device. From there, you look in C:\Windows\System, A:; and D: for your DLL". In other words, they basically did half the job of coming up with a standard, taking the "Yer gonna use the Winders Drivers, right?" attitude.
Why don't they establish some standards for devices: Any USB mass storage adaptor must provide these commands, any USB CDR must provide these commands, any USB scanner must provide these commands, any USB to SCSI bridge must provide these commands, etc.
Also, on the subject of the USB HID (human interface device): this is nothing but a big MGI (mogolian group intercourse) - an HID is a thing that does stuff. That's about the extent of the USB spec. How about specifying that an HID must provide a descriptor list in a well defined format (XML, anyone?) that defines what inputs and outputs the device has?
Sorry, but until the various standards committees accept that "Supply a GUID, and the rest is up to Windows" is not enough, things like USB, Firewire, Bluetooth, etc. will not be supportable by anything other than Windows.
As an embedded systems developer, I am disgusted by having to either waste my time writing a million drivers for the things people want to hang off my box, or having to embed Windows.
I would disagree with your statement that "prior art is dead" - the biggest issue is to make sure that your prior art is well established and incontrivertable. The best thing would be to start a section on a high profile location, like your journal here or on Sourceforge, as well as trying to get a story in an appropriate trade journal.
Since we are talking about software radio, I'd suggest writing up your idea, and submitting it to QST (http://www.arrl.org). ANYBODY in the radio profession will read QST (and QEX), and that makes it very hard for a would-be patent scum to say "I didn't see that!".
I'm glad you took my response correctly - I was afraid you'd think I was blowing you off, rather than covering my own ass. If I owned the company, it might be different (hence why if I ever did strike out on my own, I would avoid letting my company become publicly traded: as soon as you become publicly traded, you no longer own the company.).
While I am of the personal belief that any sane individual opposes the DMCA and the trial of Dmitri, I also am opposed to a teacher telling his students they must protest an action. What if some student in your class feels that the DMCA is a good thing, and that Dmitri should "... be torn into little bisty pieces and buried alive!"?
Offer writing letters to the CongressDrone either for or against as an option, or allow them to present a short speech about their thoughts on the case.
Well, as far as telling you more about my project... I'd feel very uncomforable going into any greater detail than the marketing data I pointed to in the main post - there are issues of disclosure.
As for hearing about your idea - same thing. If your idea is close to something we are already working on, then it opens up a huge can of worms. If your idea ISN'T something we are working on, but pertains to what we do, then it's not just a can, it's a barrel.
Basically, if you don't feel comfortable detailing it in a post to Slashdot, then I don't feel comfortable discussing it without running past Legal. Sucks, but that's life in the twenty-first century.
Actually, not as funny as the number of "Overrateds" I get. Just goes to show that Metamoderation really isn't doing as much as it might to keep the moderators honest...
Being able to make "features" as small as 13 um (and remember, "as small as" means this is a lower limit, and includes all sizes larger than this, up to Ringworld and beyond....) does not translate into working transistors at this size. You start getting into quantum tunnelling through the gate oxide because it is too thin, you start getting into a very high on resistance because the channel is too thin, the interconnects start to electro-migrate at 1 volt, etc.
Making small features is only a very small part of making a working chip.
A question to the real lawyers that read Slashdot (paging Dr. Hawk....)
/. that some ISPs try this, but find it difficult to follow through because the spammer just disputes the credit card charge, and the ISP gets in trouble with the credit card company. However, this seems to me to be a deliberate, premeditated violation of a contract on the part of the spammer, and an act of criminal fraud. Especially if the ISP makes the fine large enough, wouldn't that be felony fraud?
Paetec has a clear statement in their terms of service that prohibts the use of their service in the furthurance of spam. MonsterHut agreed to that TOS as part of their contract, with the obvious intent of violating that TOS. Does not that mean they entered into the contract in bad faith? Does not that mean that MonsterHut committed a tort of fraud? Does not that mean Paetec can bring countersuit?
I have been a long time advocate of ISPs, "free" e-mail services and "free" web hosting sites adding lines to the contracts stating spam is verboten, and then bringing fraud (charges|civil suit) against spammers. I've read on
OK, so it was several questions. And I know, that any practicing lawyer no more wishes to give out free advice than I wish to give out free computer service, but.... How about a little non-binding, pro bono, off the cuff, YMMV opinion?
Of the three interviewees, Hans knew more about the other guys, he was better able answer what was better about the others then his, and how his was better than the others. The others came off as suits, he came off as an engineer.
I read the "fixed for Netscape" link. It doesn't mention Netscape at all. Is the implication that the contents of the link are fixed for Netscape? One would think that an Open Source development group would understand how to write proper HTML that would render on everything. What, did the main announcement only work on Konquerer?
The big problem with supersonic or better flight for commercial use isn't the fuel economy, it's the fact that many countries (the US being the first that leaps to my mind) don't allow commercial aircraft to fly supersonic over their land at any altitude. Therefor, you either have to land the scramjet at New York, and then fly subsonic aircraft to the rest of the US (assuming you are coming from Europe), or you have to cruse the scramjet subsonic (this is especially true if you are flying from, say, London to Saint Louis) over land.
Also, just because of the stresses involved, a supersonic aircraft will need to be much stronger than a subsonic craft like a 7[47]7. More strength == more cost and more weight (== still more cost).
Also, most scramjets are designed to burn hydrogen, not kerosene (like a commercial jet). Hydrogen requires cryogenic tanks, and has the nasty habit of migrating into the metal, finding any weakness, and setting up shop (a process called hydrogen embrittlement). While hydrogen has a much higher impulse than kerosene per unit weight, it is also more expensive.
Don't get me wrong - I'm looking at going from the US to the UK for a business trip soon, and I'd love to do it in less than eight hours. But I shan't postpone my trip until these things are flying....
This rather defeats the whole purpose: if you allow a "hostile app" (read: an application you don't control, don't have the source for, and don't trust implicitly (e.g. Windows)) to run on this card, you have just thrown the security of the card out the window. The whole idea is that the crypto functions take place in a secure environment where everything can be trusted. If you want to run Realplayer or something, run it on the host CPU, not the card!
Second, the nit. I work with secure comms products, and the term "zeroize" has always grated on my ears: You zero the keys, you randomize the keys, but you don't "zeroize" them. This is a typical case of the government type making up a word because it makes him sound more important. Yes, I know full well that "zeroize" is the accepted term in secure comms, but it still sounds stupid!
And I agree with several of the posters - I'd like to see this sort of thing work its way into a box next to the computer.
Take
this bad boy, a four channel programmable down converter - 4 radios on a chip. You feed in 1 to 4 IF data streams, and this guy will decode them - about 2 billion operations per second, on a chip the size of your thumbnail (micro-ball-grid array). I work with its little brother, the 50214, on
my project, and I can't wait until I get past the big stuff and get some time to play.
That's the sick thing about soft radios: you do one down conversion from RF to IF, then digitize it, and from there on it's all math. When you are a ham operator, a math geek, and a software engineer, and you get paid to play with these, well, life is good.
Now, let's look at sat phones:
And remember, any advances in vocoder technology, modulation technology, or transmitter technology will benefit both terrestrial cellular and sat phones equally. Except that it is a lot easier to upgrade a terrestrial site than a bird in LEO.
As a result, there will always be far fewer sat phone users than cell phone users. All the non-recurring engineering costs, all the fixed costs of manufacture, all the fixed costs of service will have to borne by fewer users.
Who in their right minds allows for password authentication over SSH? That's one of the first things I disable when setting up SSHD.
If you don't have a private/public key pair, and if your public key isn't in the authorized_keys file of the target machine, then you don't deserve to log on. Tunneling passwords over the system is neither needed nor safe, and not just because of this article's hack.
If you allow SSH to do password authentication, then SSH is little better than Telnet in terms of protecting you from a poorly chosen password. While a sniffer might not be able to extract the password, you can still try a dictionary attack.
Force your users to use a keypair. Force them to put a passphrase on the keypair so that just stealing the key isn't enough.
Remember, the best security is something you are (restriction by host IP), something you have (posession of the private key), and something you know (the passphrase for the key.)
It would have been nice if the article had described what, exactly, the HP additions are supposed to do. We get some vague platitudes about "tightly controlling communications" and "detecting attacks". This could be anything from a well-written iptables setup and a syslog monitor to a full-blown, user-space stateful filtering/SNMP and "page-the-sysop-we-are-being-DDOSed" application.
Does anybody have any REAL info on what HP is doing that is so wonderful?
Does Reiser have something like xfs_fsr? xfs_fsr is a program you throw into a cron job and it will optimize the file system: it copies a file to a contiguous space, then swaps the inodes over. It lets you defrag a file system and move the data around for best access.
I have no direct experience with the battery backed up drives, but here is a typical link:
http://www.buymemory.com/mr35.htm
These things aren't cheap, but they aren't marketed toward your average Joe. However, if I ever get the cash to get a Firewire camcorder, I'd want to do my video editing on a journaled system with the journal on something like this.
My only experience with ReiserFS was on an SMP machine, and it blew chunks (corrupted file system, bad data, kernel panics). I tried XFS and it worked quite well. I've not given Reiser another shot since then (haven't had time). Perhaps they've fixed this bug.
I like the fact that growing an XFS volume to take up more space is simple, and does not require unmounting the volume (in fact, you CANNOT grow an unmounted XFS volume, you MUST mount it first).
So, in a system with hot-swap drive bays, you can add a physical volume to the logical volume group, and just tell XFS to grow. Presto - more space.
I also like the fact that you can move the journal over to another block device. If "you feel the need, the need for speed" you can use a 10MB SCSI battery-backed up SRAM drive for the journal, and a big RAID array for the main storage. Speed and safety in one.
I can't wait until SGI gets XFS merged into the main tree. I'm running XFS on all my systems, and so I have to wait until SGI gets the changes merged back into their port.
XFS (especially when combined with LVM) is great. No fscks, big files, ACLs, and you can grow a mounted file system (great with LVM and hot-swap drives).
It looks like the /. team learned an important lesson from the first trial of Banjo: never create a list that you get to the top of just by posting.
The amount of journal whoring (posting inane crap to your journal just to get to the top of the journal list) was almost unbelievable. It looks like they've disabled that list.
Of course, I have to wonder what the utility of the journal is, given that I could create a thread at any time on the current slashdot just by entering a URL. I guess that making it an eaiser feature will increase it's use. I'm just not sure that is such a good thing.
Now, I wonder when Vmware will fully support XFree86 V4.x.x - without it running WinNT under Vmware is really slow on any graphics operation.