Unfortunately, the book review sounds like the book is missing information on one of my pet peeves:
Fully dynamic websites will crush your server.
Dynamic websites may be easy for beginners with this book, but introduce (a) a large amount of data or (b) a large amount of traffic (e.g. slashdot effect), and your server will fall over faster than a debutante in her first set of heels.
I was on the team that helped set up cnn.com, back in the "early days" of the Web. And more recently, during the U.S. presidential debates, I convinced FactCheck.org that their server would stop falling over, if they just exported their article database as static HTML files, rather than being 100% dynamic. (that indeed fixed the problem)
Dynamic content has its place, but too many newbies make the assumption that a fully dynamic website is a good idea. For content that does not change frequently, it is often more wise to use triggers to export the data as static HTML than to continually query and generate the same dynamic content over and over again. Database query caches help, but not a whole lot. Static HTML pages, and dynamic pages that provide the HTTP cache/expire/etag info are much more friendly to the web caching infrastructure in your browser and at your ISP.
nvidia wrote the SATA driver that's current in the Linux kernel, and has generally been helpful in addressing problems that arise in it.
Although the ethernet driver ("forcedeth") was indeed reverse-engineered, nvidia eventually lent their support behind the effort: they contributed gigabit ethernet support to the driver.
heh, not two hours ago I posted a blog entry in my investing blog about TiVo and cable companies in general.
Overall, I see that TiVo is consistently first in marketing a particular DVR feature, but since it's commodity software running on commodity hardware, the cable companies can quickly replicate any good ideas. TiVo does all the hard work, but the cable companies are the ones who will reap the benefits long-term.
Since TiVo's subscription service isn't 100% integrated with your cable service, it will always be inferior to what your cable service will give you with the basic package. The "box" is the interesting part of what TiVo produces, but not interesting and innovative enough to pull many customers away from just-use-the-cable-box.
The reason why XML is so darned handy is that is captures the essence of what makes a computer useful: data structures. XML standardizes parsing (never write a text parser again), leaving only the task of grok'ing data structures to the programmer.
XMPP takes that a step further: a standardized way two programs may exchange data structures.
To me, this has all sorts of useful implications, particularly in enterprise installations. Now engineers can stop rolling their own TCP protocols just to get two custom applications to communicate with each other; they can now use XMPP, and exchange data structures.
It's worth pointing out that XMPP is not just for instant messaging.
XMPP standardizes a method for exchanging structured information streams between autonomous entities -- by they human or automated agent.
Thus, when you (as an engineer) need to set up a network of programs that all communicate with each other, you don't have to roll your own protocol, XMPP can do it for you.
Although IRC "botnets" have existed for quite some time, they are typically very primitive and exist mostly in the realm of script kiddies. Further, IRC is unformatted, unstructured, un-standardized text, making it very difficult to parse reliably.
XMPP allows networks programs to communicate with each other in a "native" language -- data structures -- rather than attempting to glean information from a line of IRC ASCII.
I'm currently using XMPP for several local applications: backup agents communicating with each other, sending and receiving mon monitors and alerts, an improved (RSS-like) syndication system, and more.
Hurricane Electric and others offer tunnel broker services, which are static IPv4<->IPv6 tunnels. Note that most tunnel brokers refuse to forward IRC traffic.
Certainly some ISPs are starting to roll out IPv6 service, and if that's available in your area, take advantage of it. But if not, there are useful options (I recommend 6to4).
A reverse proxy server (http accelerator) must be open to the public.
However, that does not mean the server is an "open proxy"... the proxy configuration only proxies for the specific web sites listed in the configuration file.
No, 6to4 is really that bad - it relies on custom tunnels and special ISP support rather than just specifying it on the routers.
Actually 6to4 Just Works(tm) in most cases. You can't get much easier than that. That is the purpose of 6to4: the special anycast prefix guarantees that you do not need special configuration or special ISP support.
I've played with ipv6 in the past, but after so many years it's still a very long way from useful. Since nobody has ipv6 machines and you need ISP support (which ISPs don't provide) putting up an ipv6 website is a sure-fire way to get zero hits.
Putting up an IPv6-only website would be pointless. The idea is for IPv6 transition to be seamless: a web server admin adds IPv6 to an existing website, and nobody except the IPv6 users will notice a difference.
My own website supports IPv6, and it gets a few hits daily from IPv6 users. It also supports IPv4, of course. And neither set of users ever need know, or care, about my web server setup. It Just Works(tm), and will continue Just Working as the world moves to IPv6.
It doesn't help that proxies eg. squid don't support it yet..
Apache does proxy caching and http acceleration quite nicely, and has stable IPv6 support.
I agree that squid lags behind, but overall you picked a poor example. Most of the core Internet software, both client and server, either has production-stable IPv6 support, or is close to it.
Setting up IPv6 is actually quite easy these days.
For Fedora Core users stuck without a direct IPv6 connection (read: most of the world), I wrote a quick IPv6 6to4 setup guide.
6to4 is "automatical tunnelling", which in layman's terms means you don't have to bother your ISP or a tunnel broker in order to set up IPv6 on your network.
Most OS's these days (not only Linux but *BSD and Windows) fully support basic IPv6, including 6to4.
Here's an abbreviated list from my Linux SATA status report:
(all this info has been public for quite a while) 3ware: RAID Adaptec 1210: non-RAID Adaptec AAR*, various others: RAID Silicon Image 3112/3114/3124: non-RAID Intel ICH5/ICH5R: non-RAID Intel ICH6/ICH6R: non-RAID SiS: non-RAID VIA: non-RAID nVidia: probably non-RAID (don't know for sure) Promise: RAID accelerator
This is a list of hardware capabilities only.
In case you're curious, "RAID" these days typically means a small, general-purpose CPU (a microcontroller) on the RAID card itself.
"non-RAID" means just what it implies: the hardware provides zero RAID functionality.
Being the person implementing Serial ATA for Linux...
Most "SATA RAID" is a bunch of marketing malarkey. It is provided by the BIOS and OS, not the hardware.
There are a few "true" hardware RAID controllers, such as 3ware or some of the more advanced Adaptec controllers.
In the middle is Promise, which produces controllers what I call "RAID offload" features -- not true RAID, but faster than non-RAID if you use Promise-specific features.
Finally, the third group of SATA controllers is vast majority -- no RAID support whatsoever, but they are being sold as RAID.
Any benchmark of SATA RAID simply benchmarks the OS- or vendor-provided software RAID driver.
> Wrong. Backporting drivers has been fantastically
> useful to me.
Right. And let me guess. You use all sorts of specialty hardware.
Wrong. The drivers and subsystems I maintain in the Linux kernel are all for the most commonly used hardware.
When you do something like port just the per block device locking from the 2.6 SCSI mid-layer back to 2.4 for your vendor specific release and don't put as much as a release note or a long file name on the patch in your source tree, all the while making something that's incompatable with both versions, you make it very difficult for outside companies to write interoperable drivers.
First, this was documented in both release notes and the rpm changelog.
Second, this specific feature is entirely optional. An upstream 2.4 block, scsi, or net driver drops into RHEL kernels with zero modifications. I do this all the time, with all three of these classes of drivers (block/scsi/net). It is a hardware vendor's choice to create 2.4-backport-specific modifications to their driver, with the additional maintenance that entails.
You're whining about optional, performance-enhancing features that you don't have to use. You are free to pretend that Red Hat kernel looks like the upstream 2.4 kernel, from a block and SCSI perspective, and things Just Work(tm).
If you wrote drivers for linux, you'd know this,
Tee hee. Apparently you have no clue who writes Linux device drivers.
> Backporting 2.6 features helps everyone because it > subjects those features to more testing, meaning > that 2.6 will be better as a result.
Unlikely. Testing of features that have been hacked back into an older kernel won't provide representative results.
Wrong. Backporting drivers has been fantastically useful to me. It gives my drivers much more testing than they would otherwise receive. RHEL bug reports have often appeared long before the community notices the bug.
RedHat's backports are notorious for changing things in the driver interfaces.
I suppose your definition of "notorious" includes upstream 2.6 driver interfaces, and driver interfaces jointly developed by SuSE and Red Hat (such as varyio).
The real effect of backporting features is that it scares off third party developers.
Wrong. It exposes new features to more users. Making drivers available to more users means that Linux hardware support is more widely deployed.
Just imagine if Red Hat and SuSE did not ship my Serial ATA driver. Linux users would be given the "opportunity" to either run 2.6.x kernels, or have their hardware not work.
In order to provide a balanced documentary, please examine the foreign companies that are "in-sourcing" labor -- shifting labor from overseas into the United States.
I just heard on the radio (no source mentioned) that last quarter the number of in-sourced jobs was larger than the number of out-sourced jobs.
Further, please examine the ramifications of protectionist policies, and ask economists about their long term ramifications. There is way too much "outsourcing is evil" or "outsourcing is great" without balance or attribution.
HP's Graham Smith says:
"Without TCP/IP, it has no real error-recovery mechanism or guarantee that packets get delivered."
But that is wrong. There is error checking in the ethernet hardware and in the SCSI stack. It seems Smith needs to review the basic material,
Sorry, Daniel:) As Linux's network driver maintainer and author of a Serial ATA stack which goes through the Linux kernel SCSI layer... as well as being someone who reviewed ATA-over-ethernet...
I can say that ethernet hardware and the Linux SCSI stack does not handle retranmits that are needed at the ethernet layer. HP's Graham Smith is precisely correct. As some other slashdotters pointed out, the HyperSCSI code includes logic to handle retransmits and failures -- as it must.
Tee hee. I love this topic when it comes up, because inevitably both sides are wrong. It's horribly off-topic, but I can't help it... I blame whoever modded up the response:)
Television evangelist Pat Robertson was overheard stating that the process of natural evolution was impossible, given that it's findings lie outside the idea of Christian creation dogma. All the while scientists the world over continue to compile and test bodies of evidence for it's many intricate workings. Despite all of the evidence to the contrary, Pat Robertson's opinion remains firm.
Evolution is fairly obvious on a micro scale, but few people seem to admit it has serious problems at a macro scale. If you look at evolution of all species over time, a lot of statistical anomalies appear. Some special evolve simultaneously, rather than participate in an evolutionary arms race that "pure evolution" would imply. Other species have evolved in statistically abnormal ways -- in statistically significant numbers.
So. When considered from a statistical perspective, both pure creationism and pure evolution are both implausible. Chew on that.
A parting shot. When I mentioned this to a die-hard creationist, he related to me the ultimate loophole: God makes the rules. Therefore, God can (did?) create a universe where evolution is considered fact rather than theory.
Jabber (or, Who cares about 100+ plugins?)
on
AOL Bridges AIM and ICQ
·
· Score: 2, Insightful
A bit of a sarcastic subject, but nonetheless, I think the "my client supports N protocols/plugins" is not something to brag about, it's describing a sad state of affairs.
The world doesn't need more plugins, the world needs fewer protocols. I read the "AOL bridges AIM and ICQ" from the perspective of hoping the AOL was moving towards the use of the Jabber protocol as a common baseline for instant messaging.
Jabber is a nice superset of existing instant messaging and chat functionality, from the programmer's perspective. It is, IMO, technically superior to ICQ, MSN, IRC, and other chat/IM protocols. The main thing that prevents it from dominating is really acceptance/buy-in from the big IM providers: AOL, MSN, ICQ,...
Jeff
More on inodes (was Re:My understanding)
on
XFS merged in Linux 2.5
·
· Score: 3, Informative
AFAIK in ReiserFS inodes are not used the way they're in traditional FS'. You certainly need to present the inode layer to the OS, but. They use Balanced trees for block allocation. AFAIK you do not end up with a fixed number of "inodes" after ReiserFS is created.
You're mixing filesystem features up. To clear things up a bit,
Individual inode records need not be of a fixed size.
The inode table (total number of inodes) need not be a fixed size, and it can even be moved around, and spread across, various physical locations on the disk.
The inode table can either have a special-cased storage method (ext2/3), or simply be stored using the filesystem's own block allocation methods -- in effect treating the inode table as a "normal
file" (jfs, ntfs, several others) This second method has the property of being very flexible: just as it is trivial to extend the length of a normal file [i.e. append], it is trivial to add new inodes to an inode table that the filesystem treats internally as a "normal file."
There are wild and varied ways to store inodes. But ReiserFS definitely has them.:)
but in multiple drive machines where IDE drives share controllers, SCSI will always be faster.
Look at "TCQ" -- Tagged Command Queueing -- that has been worked on by
Andre Hedrick in the past, and is currently going into the Linux 2.5.x kernel series
due to the work of Jens Axboe.
TCQ is where SCSI gets a lot of its speed, by allowing multiple
device commands to be outstanding on the bus at any given time.
TCQ really levels the playing field for IDE and SCSI... assuming your
IDE driver supports it (most do not).
Mozilla browser is pretty decent, though it still has rendering problems I occasionally run into.
Mozilla Mail is a different story. Functional, but very unpolished and not ready for heavy use. I should know, I've been using it heavily for the past two weeks as a trial run. Basically it needs a UI guy to go over it and flesh out the bugs.
Scrollbar insanity. If your message has attachments (this occur sometimes in other conditions, too) you have no scrollbars. Or to be more accurate, the scrollbars are present but completely obscured and inaccessible.
Blank messages. Crossing folders when going to the next unread message, the message text doesn't appear at all. One must highlight another message in the folder, then return to the chosen message.
Problems with large selections and large attachments. UI freezes for a looong time, and occasionally crashes.
Multi-folder navigation. "Next unread message" and similar commands take you to the next unread message... but still leave the folder highlighted. Read the message, hit delete, and you just deleted a folder.
Constant subwindow resizing. Going from a message with attachments to one without causes multiple redraws of the same window... at different window sizes.
Crashes once per day, typically.
...and more. If you live and die by your email, as I do:) there are other buglets you run into as well.
In short, works but definitely not ready for prime time.
Slashdot Mirror
Fully dynamic websites will crush your server.
Dynamic websites may be easy for beginners with this book, but introduce (a) a large amount of data or (b) a large amount of traffic (e.g. slashdot effect), and your server will fall over faster than a debutante in her first set of heels.
I was on the team that helped set up cnn.com, back in the "early days" of the Web. And more recently, during the U.S. presidential debates, I convinced FactCheck.org that their server would stop falling over, if they just exported their article database as static HTML files, rather than being 100% dynamic. (that indeed fixed the problem)
Dynamic content has its place, but too many newbies make the assumption that a fully dynamic website is a good idea. For content that does not change frequently, it is often more wise to use triggers to export the data as static HTML than to continually query and generate the same dynamic content over and over again. Database query caches help, but not a whole lot. Static HTML pages, and dynamic pages that provide the HTTP cache/expire/etag info are much more friendly to the web caching infrastructure in your browser and at your ISP.
We're just waiting on SCSI to finalize its "ATA passthru" drafts before the patch can go to mainline.
nvidia SATA status and other Linux SATA info.
nvidia wrote the SATA driver that's current in the Linux kernel, and has generally been helpful in addressing problems that arise in it.
Although the ethernet driver ("forcedeth") was indeed reverse-engineered, nvidia eventually lent their support behind the effort: they contributed gigabit ethernet support to the driver.
The video stuff is still closed, of course.
Somebody mod the parent up, please.
This person actually seems to have real info (shocking, I know) about Internap.
heh, not two hours ago I posted a blog entry in my investing blog about TiVo and cable companies in general.
Overall, I see that TiVo is consistently first in marketing a particular DVR feature, but since it's commodity software running on commodity hardware, the cable companies can quickly replicate any good ideas. TiVo does all the hard work, but the cable companies are the ones who will reap the benefits long-term.
Since TiVo's subscription service isn't 100% integrated with your cable service, it will always be inferior to what your cable service will give you with the basic package. The "box" is the interesting part of what TiVo produces, but not interesting and innovative enough to pull many customers away from just-use-the-cable-box.
To elaborate a bit further...
The reason why XML is so darned handy is that is captures the essence of what makes a computer useful: data structures. XML standardizes parsing (never write a text parser again), leaving only the task of grok'ing data structures to the programmer.
XMPP takes that a step further: a standardized way two programs may exchange data structures.
To me, this has all sorts of useful implications, particularly in enterprise installations. Now engineers can stop rolling their own TCP protocols just to get two custom applications to communicate with each other; they can now use XMPP, and exchange data structures.
It's worth pointing out that XMPP is not just for instant messaging.
XMPP standardizes a method for exchanging structured information streams between autonomous entities -- by they human or automated agent.
Thus, when you (as an engineer) need to set up a network of programs that all communicate with each other, you don't have to roll your own protocol, XMPP can do it for you.
Although IRC "botnets" have existed for quite some time, they are typically very primitive and exist mostly in the realm of script kiddies. Further, IRC is unformatted, unstructured, un-standardized text, making it very difficult to parse reliably.
XMPP allows networks programs to communicate with each other in a "native" language -- data structures -- rather than attempting to glean information from a line of IRC ASCII.
I'm currently using XMPP for several local applications: backup agents communicating with each other, sending and receiving mon monitors and alerts, an improved (RSS-like) syndication system, and more.
This ain't your grandfather's IM protocol.
Well for starters, you can set up 6to4 automatic tunnelling on your network, without having to bother your ISP at all.
Hurricane Electric and others offer tunnel broker services, which are static IPv4<->IPv6 tunnels. Note that most tunnel brokers refuse to forward IRC traffic.
Certainly some ISPs are starting to roll out IPv6 service, and if that's available in your area, take advantage of it. But if not, there are useful options (I recommend 6to4).
Silly people.
A reverse proxy server (http accelerator) must be open to the public.
However, that does not mean the server is an "open proxy"... the proxy configuration only proxies for the specific web sites listed in the configuration file.
Actually 6to4 Just Works(tm) in most cases. You can't get much easier than that. That is the purpose of 6to4: the special anycast prefix guarantees that you do not need special configuration or special ISP support.
Putting up an IPv6-only website would be pointless. The idea is for IPv6 transition to be seamless: a web server admin adds IPv6 to an existing website, and nobody except the IPv6 users will notice a difference.
My own website supports IPv6, and it gets a few hits daily from IPv6 users. It also supports IPv4, of course. And neither set of users ever need know, or care, about my web server setup. It Just Works(tm), and will continue Just Working as the world moves to IPv6.
Apache does proxy caching and http acceleration quite nicely, and has stable IPv6 support.
I agree that squid lags behind, but overall you picked a poor example. Most of the core Internet software, both client and server, either has production-stable IPv6 support, or is close to it.
For Fedora Core users stuck without a direct IPv6 connection (read: most of the world), I wrote a quick IPv6 6to4 setup guide.
6to4 is "automatical tunnelling", which in layman's terms means you don't have to bother your ISP or a tunnel broker in order to set up IPv6 on your network. Most OS's these days (not only Linux but *BSD and Windows) fully support basic IPv6, including 6to4.
Here's an abbreviated list from my Linux SATA status report:
(all this info has been public for quite a while)
3ware: RAID
Adaptec 1210: non-RAID
Adaptec AAR*, various others: RAID
Silicon Image 3112/3114/3124: non-RAID
Intel ICH5/ICH5R: non-RAID
Intel ICH6/ICH6R: non-RAID
SiS: non-RAID
VIA: non-RAID
nVidia: probably non-RAID (don't know for sure)
Promise: RAID accelerator
This is a list of hardware capabilities only.
In case you're curious, "RAID" these days typically means a small, general-purpose CPU (a microcontroller) on the RAID card itself.
"non-RAID" means just what it implies: the hardware provides zero RAID functionality.
Being the person implementing Serial ATA for Linux...
Most "SATA RAID" is a bunch of marketing malarkey. It is provided by the BIOS and OS, not the hardware.
There are a few "true" hardware RAID controllers, such as 3ware or some of the more advanced Adaptec controllers.
In the middle is Promise, which produces controllers what I call "RAID offload" features -- not true RAID, but faster than non-RAID if you use Promise-specific features.
Finally, the third group of SATA controllers is vast majority -- no RAID support whatsoever, but they are being sold as RAID.
Any benchmark of SATA RAID simply benchmarks the OS- or vendor-provided software RAID driver.
Right. And let me guess. You use all sorts of specialty hardware.
Wrong. The drivers and subsystems I maintain in the Linux kernel are all for the most commonly used hardware.
When you do something like port just the per block device locking from the 2.6 SCSI mid-layer back to 2.4 for your vendor specific release and don't put as much as a release note or a long file name on the patch in your source tree, all the while making something that's incompatable with both versions, you make it very difficult for outside companies to write interoperable drivers.
First, this was documented in both release notes and the rpm changelog.
Second, this specific feature is entirely optional. An upstream 2.4 block, scsi, or net driver drops into RHEL kernels with zero modifications. I do this all the time, with all three of these classes of drivers (block/scsi/net). It is a hardware vendor's choice to create 2.4-backport-specific modifications to their driver, with the additional maintenance that entails.
You're whining about optional, performance-enhancing features that you don't have to use. You are free to pretend that Red Hat kernel looks like the upstream 2.4 kernel, from a block and SCSI perspective, and things Just Work(tm).
If you wrote drivers for linux, you'd know this,
Tee hee. Apparently you have no clue who writes Linux device drivers.
> Backporting 2.6 features helps everyone because it
> subjects those features to more testing, meaning
> that 2.6 will be better as a result.
Unlikely. Testing of features that have been hacked back into an older kernel won't provide representative results.
Wrong. Backporting drivers has been fantastically useful to me. It gives my drivers much more testing than they would otherwise receive. RHEL bug reports have often appeared long before the community notices the bug.
RedHat's backports are notorious for changing things in the driver interfaces.
I suppose your definition of "notorious" includes upstream 2.6 driver interfaces, and driver interfaces jointly developed by SuSE and Red Hat (such as varyio).
The real effect of backporting features is that it scares off third party developers.
Wrong. It exposes new features to more users. Making drivers available to more users means that Linux hardware support is more widely deployed.
Just imagine if Red Hat and SuSE did not ship my Serial ATA driver. Linux users would be given the "opportunity" to either run 2.6.x kernels, or have their hardware not work.
In order to provide a balanced documentary, please examine the foreign companies that are "in-sourcing" labor -- shifting labor from overseas into the United States.
I just heard on the radio (no source mentioned) that last quarter the number of in-sourced jobs was larger than the number of out-sourced jobs.
Further, please examine the ramifications of protectionist policies, and ask economists about their long term ramifications. There is way too much "outsourcing is evil" or "outsourcing is great" without balance or attribution.
Sorry, Daniel :) As Linux's network driver maintainer and author of a Serial ATA stack which goes through the Linux kernel SCSI layer... as well as being someone who reviewed ATA-over-ethernet ...
I can say that ethernet hardware and the Linux SCSI stack does not handle retranmits that are needed at the ethernet layer. HP's Graham Smith is precisely correct. As some other slashdotters pointed out, the HyperSCSI code includes logic to handle retransmits and failures -- as it must.
This is old news ;-) Back in May, baard.com reported on this.
I thought the Personal Server was so neat, I wrote my own article based on the baard.com info, Science Fiction becomes science-fact.
Television evangelist Pat Robertson was overheard stating that the process of natural evolution was impossible, given that it's findings lie outside the idea of Christian creation dogma. All the while scientists the world over continue to compile and test bodies of evidence for it's many intricate workings. Despite all of the evidence to the contrary, Pat Robertson's opinion remains firm.
Evolution is fairly obvious on a micro scale, but few people seem to admit it has serious problems at a macro scale. If you look at evolution of all species over time, a lot of statistical anomalies appear. Some special evolve simultaneously, rather than participate in an evolutionary arms race that "pure evolution" would imply. Other species have evolved in statistically abnormal ways -- in statistically significant numbers.
So. When considered from a statistical perspective, both pure creationism and pure evolution are both implausible. Chew on that.
A parting shot. When I mentioned this to a die-hard creationist, he related to me the ultimate loophole: God makes the rules. Therefore, God can (did?) create a universe where evolution is considered fact rather than theory.
The world doesn't need more plugins, the world needs fewer protocols. I read the "AOL bridges AIM and ICQ" from the perspective of hoping the AOL was moving towards the use of the Jabber protocol as a common baseline for instant messaging.
Jabber is a nice superset of existing instant messaging and chat functionality, from the programmer's perspective. It is, IMO, technically superior to ICQ, MSN, IRC, and other chat/IM protocols. The main thing that prevents it from dominating is really acceptance/buy-in from the big IM providers: AOL, MSN, ICQ, ...
You're mixing filesystem features up. To clear things up a bit,
- Individual inode records need not be of a fixed size.
- The inode table (total number of inodes) need not be a fixed size, and it can even be moved around, and spread across, various physical locations on the disk.
- The inode table can either have a special-cased storage method (ext2/3), or simply be stored using the filesystem's own block allocation methods -- in effect treating the inode table as a "normal
file" (jfs, ntfs, several others) This second method has the property of being very flexible: just as it is trivial to extend the length of a normal file [i.e. append], it is trivial to add new inodes to an inode table that the filesystem treats internally as a "normal file."
There are wild and varied ways to store inodes. But ReiserFS definitely has them.Regards,
Even NTFS has inodes, they simply call them "MFT records."
Look at "TCQ" -- Tagged Command Queueing -- that has been worked on by Andre Hedrick in the past, and is currently going into the Linux 2.5.x kernel series due to the work of Jens Axboe.
TCQ is where SCSI gets a lot of its speed, by allowing multiple device commands to be outstanding on the bus at any given time. TCQ really levels the playing field for IDE and SCSI... assuming your IDE driver supports it (most do not).
Mozilla Mail is a different story. Functional, but very unpolished and not ready for heavy use. I should know, I've been using it heavily for the past two weeks as a trial run. Basically it needs a UI guy to go over it and flesh out the bugs.
In short, works but definitely not ready for prime time.
The Plan 9 operating system already supports a lot of the concepts quoted in the Slashdot story summary.