Re:actually the 1.2GHz ARM is more intresting
on
PowerPC Goes 64 bit
·
· Score: 1
(they say its ARM10 but I think thats wrong and its just ARMv5 complient but that sounds bad in marketing speak so thedy said it
was like an ARM10(I think I am not sure) )
Kind of like RAID5 versus RAID10? I.e. what is called RAID10 would for most of us fall under the definition of RAID5?
POWER != POWER2 != PowerPC ISA, but close
on
PowerPC Goes 64 bit
·
· Score: 2
POWER and PowerPC are mostly the same, but not quite.
Correct. gcc and AIX xlc compilers by default output the common subset - the moral equivalent of -march=486 or so.
IIRC all of those instructions are fairly esoteric supervisor mode
instructions, so they'd likely only affect the OS and not user-space programs.
Mostly extensions, a few dropped or changed facilities. It's worth noting that the PowerPC is much closer to its immediate ancestor the POWER2. Here are some highlights of POWER -> 32-bit PowerPC, taken from The PowerPC Architecture (IBM, 1994):
a few instructions, formerly privileged, are now general-use
two instructions, formerly general-use, are now privileged
34 instructions (only 3 of which were privileged) have been dropped
35 instructions have been added - a few privileged ops, quite a bit of floating point, a few new facilities
many "don't care" conditions have been tightened up to e.g. "reserved, must be 0"
a few facilities changed around - memory management for one, RTC for another (PowerPC uses a new "time base" instead of an RTC - the time base has an implementation-defined tick and sounds more like the Pentium TSC), etc.
The main changes listed for POWER2 -> 32-bit PowerPC seem to be dropping several opcodes for floating point loads/stores, and some semantics of FP <-> int conversions.
I think it is about time that the LSM (or anything similar) was included in the kernel. When it comes to access control, I think
Windows NT/2000 wins hands down against Linux.
Well, Linus has started integrating it, so you'll get your wish.
As to whether NT is superior, it depends on if you measure by flexibility or by ease-of-use. NT ACLs are hella flexible - you can grant or deny a whole range of permissions to anyone you wish. The Unix "read write execute / owner group other" seems horribly primitive by comparison. But it comes at a cost. NT does not come with any sane way to manage permissions. The GUI tool? Puh-leeze. It can't even add / remove users from a tree of files without resetting every file in the tree to the same ACL. It doesn't give access to the "deny" half of an ACL either - everything is "start from zero, and allow". It doesn't seem to have any "summary mode" or search capabilities - you have to click on objects individually to find out their status, which gets pretty old on even a small filesystem.
The command line CACLS.EXE is not much better. It is some better, but still does not have a "search" mode, or an easily greppable output format - there seems to be no equivalent to "find -user" or "find -perm".
Finally, although the order of ACL entries is significant in NT, the tools (both GUI and CACLS.EXE) do not seem to provide access to the ordering. (CACLS lets you view the order, but not change it; the GUI goes so far as to sort the entries alphabetically! - misleading at best.) This is a fatal flaw, and shows that either the tools are inadequate, or the system is overdesigned. (IMHO, both.)
Windows 2000 is a bit better - the GUI at least gives you access to the "deny" half of things, and exposes the "inherit permissions" functionality which can simplify life considerably.
Unix / Linux, on the other hand, may not have ACLs, but frankly, with a few well-chosen groups you usually don't need ACLs anyway. (My evidence: AIX and IRIX do have ACLs, yet in several years of AIX/IRIX administraction, I've never actually used them, or wanted to.) And, thanks to both the simplicity of the scheme and the maturity of the tools, Unix permissions are much easier to manage than NT ACLs, in my experience. (Speaking of which, I may as well admit some serious bias, since I've had a lot more experience managing Unix than NT.)
In any event, it is really unconscionable that XFS isn't being integrated into 2.5.
It is nothing of the sort. For one thing, you should look up the word unconscionable - "I do not think it means what you think it means." For another, if you think it such a great crime, why don't you undertake to integrate it?
Hint: "integrate" does not mean "take the SGI patch and throw it at Linus". It means "comb through SGI's patch, figure out what all was added to the kernel to support XFS, and take it apart feature by feature." Then, for each separate feature:
Produce an independent patch - independent meaning does not require the rest of the XFS patch, does not break the kernel, and actually accomplishes something on its own.
Figure out how to justify its existence in a sufficiently convincing way that Linus knows you're actually trying to improve the kernel, not just throw crap in it so you can have XFS.
If Linus thinks your feature is stupid, poorly designed or poorly implemented, he's probably right. He's pretty amazing that way. You must take his criticism into account to figure out another way to get the needed facility. (If necessary, hash something out on linux-kernel or linux-fsdevel.) Iterate until you get a patch Linus likes, then adapt XFS to use that instead.
Finally, when Linus has merged enough of your patches that XFS has all it needs, send Linus the XFS filesystem code itself. At this point Linus will most likely take it. If Linus has objections to the XFS code itself, work with him to clean it up as necessary. Remember, just because code was good enough for IRIX doesn't mean it's good enough for Linux. (:
Here endeth the XFS Integration Mini-HOWTO.
What? You don't want to be the one who gets to do all that after all? Then quitcher bellyachin'.
Sign, nobody's still answered the question. I assume it *is* possible, but nobody's been bothered.
OK, you asked for it. I'll answer the question. Why is there not an implementation of locate (or slocate, which is much the same thing) which indexes filesystem changes in real time?
Because of the kernel/user split. locate and slocate operate in user mode, getting information from the kernel in bulk, when updatedb is run. File creation / linking / unlinking / renaming happens in the kernel. There is no general interface for the kernel to alert userspace of changes to the filesystem - which means locate has no way of picking up updates short of rescanning the whole filesystem for them, manually. As you'll notice when you run updatedb, this is a laborious process, not suitable for running in real time. (Indeed, if you want real time, use find. locate was invented specifically for its cache - that's the only real advantage it has over find.)
...Which spawns two more questions. One, why can't someone add such a callback, and two, why not do a locate in kernel space?
As to the callback, the concept exists in the form of directory notifications, where an application can request a list of directories its wants to be notified about. The kernel then makes it known when one of these changes in some way - link, unlink, rename. I know this has been implemented for Linux, but I don't believe it has made it into the mainstream kernels. It could be put to good use by a file manager application, or a "desktop icon manager" like the Windows Explorer shell.
Having a similar callback for an entire filesystem - well, apparently nobody has found it necessary yet, and it would probably slow down a lot of filesystem workloads / benchmarks. Richard Gooch's devfs filesystem for device nodes does have this - it's called the devfsd protocol - but of course it's specific to the devfs partition.
(Actually, I just remembered - as of 2.5.27 Linus is in the process of merging LSM. This is a security module framework which presumably would make it fairly easy to provide such filesystem-wide notifications to userspace. I don't yet know any more about it than that, at present.)
So... next question... why not just do locate in kernel space? In short, too little benefit for too much complexity - i.e. it would be seen as bloat.
Add in automounter magic, and TaDa: "Its a userspace problem," albeit one that assumes you are using ext2 as your only file system.
The Linux mount program knows about SGI XFS labels. I'm pretty sure it doesn't parse labels for FAT, HPFS or NTFS (yes they all have them) or whatever other filesystems have labels - probably because nobody really needs to specify label-based FAT mounts in fstab (it's a legacy format anyway). Plus, FAT/HPFS/NTFS labels are much harder to extract than ext2/ext3 and XFS labels, which are in fixed fields in a fixed superblock. (In FAT, the label is a pseudo-file in the root directory.)
do these render farms use any graphics chips or are they done entirely in cpu?
Just the CPU. You want good floating point support [which is why Titanic used 500 dual-Alpha boxes], and memory bandwidth, and of course lots of Hz are always nice.
Theoretically a renderer could use a GPU for a coprocessor, but I believe render software is so complex that any GPU on the market today would be too specialised to be of much use. Hardware acceleration works for games because the game developer can tailor the rendering requirements / algorithms to the capabilities of the hardware (as abstracted by OpenGL and Direct3D, or via vendor extensions to same). Render software, OTOH, is at the mercy of what the modeler / animator / compositor wants, and they are not willing to settle for "whatever the hardware can do the fastest".
I wonder if these guys are actually getting the most bang for the buck. Sure, they are buying the fastest machines, but I sure
wonder if a cluster of 300 Pentium 4 2.0 GHz or even Athlon 1900+ wouldn't be faster.
I agree with you, but to play Devil's Advocate, there are sometimes reasons you want a fast CPU, not just a fast cluster. Our SGI sales guy often tries to make this point, for the obvious reasons, but it's true.
If you are rendering out a large number of frames, you want the most possible aggregate CPU power, because rendering is extremely parallelisable (each frame stands alone). So 50 Athlons is better than 40 Xeons. But if you are just rendering out a 5- or 10-frame test sequence, and the wall is not already overloaded - then you want the 40 Xeons instead, since each one can take a frame and you'll get your result back faster.
There is also the issue of network bandwidth. In some cases you can benefit quite a bit by having fast boxes with as many CPUs per box as possible. This is because there is a non-trivial network burden in sending out the job to be rendered, along with all its textures, images, etc. This can be mitigated by multicasting and caching - but I don't know to what extent Renderman does this - but I know if you don't design it right, it can really slow down your jobs. (We evaluated one render distribution system that relied on Windows SMB file sharing for its I/O. Sending a 200-MB job to each of 10 render crunchers pretty much killed it.)
What I want is multiple CPUs per CPU. Yes, I know that sounds strange.
Done, see the IBM Power4 (basically a 64-bit PowerPC with some extensions, but not peer-compatible with the G3/G4/G5 line from Mot/Apple) which I believe has 2 or 4 logical CPUs per die. The little boys are moving this way too - ever since the Pentium or so, Intel and competitors have been putting multiple pipelines and execution units in a single CPU, to be scheduled as needed by a component known as the "instruction scheduler", which takes responsibility for making sure any parallelism has no side effects - that it behaves as though completely serialised, only faster. The Intel Xenon^WXeon does one better with a feature they call "hyperthreading", whereby the instruction scheduler becomes an actual multi-CPU scheduler, portraying to the OS two logical CPUs per physical CPU, in order to make better use of the redundant execution units.
I think it's fine to expect that from the article itself. To expect that in the summary that's submitted by individuals is akin to
expecting it from from every single person who comments on Slashdot.
You didn't answer his objection: "isn't that what editors are for?" He wasn't talking about Emacs, he was talking about Taco. If editors don't edit, what exactly do they do?
So you're saying these machines are so fast they are rendering the movie in time for me to have seen it several months ago? Xenon processors must use faster-than-light conduits of some sort. (:
I think it more likely that these machines are being used for The Two Towers, and possibly Return of the King, though who knows - they might be used a little in perfecting the extra 30 minutes of FotR that haven't been released yet.
nVidia Linux support has been a bit shoddy (IMHO - although the fact that they have drivers at all is a positive note)
Do they? I know they have drivers for their video chips, but what about the ATA133 IDE? What about the USB 2.0 controller, or the auxilliary USB 1.1 controller to handle USB1 devices? What about the NV Ethernet (not the 3Com one, that'll work for sure)? What about the AGP bridge (not to be confused with the video chip)? What about the audio controller? What about miscellaneous features (if present) such as hardware health sensors, watchdog, random number generator, etc?
Do any of the nForce 2 chipset components, apart from the 3C920, support Linux? According to v2.5 kernel sources, the nForce ATA100 IDE chip is supported (and the ATA133 chip is probably similar, so will be supported soon), and the nForce audio (seems to be covered by the Intel i8xx audio driver - once again, nForce 2 audio is probably similar or identical, but who knows?) but I don't see any mention of the others.
Re:Why two ethernet controllers?
on
nForce2 Preview
·
· Score: 1
I can't think of any
legitimate use for *two* ethernet controllers other than in a broader network application
Token-ring-over-UTP-Ethernet! (:
[OT] Re:Why two ethernet controllers?
on
nForce2 Preview
·
· Score: 1
Works just fine here, although with FreeBSD. I'm sure it would work with Linux too, but don't know how exactly. On FreeBSD one
network interface can have many addresses -- I have one external (assigned by the ISP) and two internal (10.0.1.x).
On Linux, you have to "clone" the interfaces to achieve that (eth0.0, eth0.1 ?)...
You're thinking "eth0:0" etc, and this is true only if you use ifconfig, which doesn't support "advanced" features. With Alexey Kuznetsov's ip utility:
I know view it as options. Albeit, it's a little annoying that you have to do some legwork to be
informed about all your options before you buy anything now;-(
I gave them major cool points for announcing the DVD release plans to the world a few months ago so we wouldn't get suckered into the "buy the same movie n times" gimmick, on which I believe George Lucas has a patent.
I don't think Gandalf knew the balrog would be there (in the book), although it isn't exactly spelled out, and he certainly had
forbodings about Moria.
`Fool of a Took!' Gandalf definitely knew of Durin's Bane, and was quite wary of disturbing the deeps of Moria. He didn't know specifically what the Balrog was:
`I do not know,' answered Gandalf. `But I found myself suddenly faced by something that I have not met before. I could think of nothing to do but to try and put a shutting-spell on the door. I know many; but to do things of that kind rightly requres time, and even then the door can be broken by strength.'... `What it was I cannot guess, but I have never felt such a challenge. The counter-spell was terrible. It nearly broke me.'... `I am afraid Balin is buried deep, and maybe something else is buried there too. I cannot say.'
I think Peter Jackson has shown that
he could give a damn about character development, which is after all subordinate to plot.
Reluctantly have to agree. One of my favorite scenes was where Galadriel made it a point to make Gimli feel at home, to great and lasting effect on Gimli. Obviously not one of Jackson's favorite scenes, though.... I wonder whether Jackson expects us to believe Gimli and Legolas became such close buddies ex nihilo..
Hmmm, they say the Galadriel GIF-giving scene is back, which is good. But what of the rest of Lothlórien? Peter Jackson omitted what may be my favorite passage in the whole book:
`Dark is the water of Kheled-zâram, and cold are the springs of Kibil-nâla, and fair were the many-pillared halls of Khazad-dûm in Elder Days before the fall of mighty kings beneath the stone.' She looked upon Gimli, who sat glowering and sad, and she smiled. And the Dwarf, hearing the names given in his own ancient tongue, looked up and met her eyes; and it seemed to him that he looked suddenly into the heart of an enemy and saw there love and understanding. Wonder came into his face, and then he smiled in answer.
He rose clumsily and bowed in dwarf-fashion, saying: `Yet more fair is the living land of Lórien, and the Lady Galadriel is above all the jewels that lie beneath the earth!'
That is one of the most important bits (IMHO) of character development - it completely redefines Gimli. And if it doesn't show up on the extended DVD, I may never forgive Mr Jackson. (:
I suppose it all depends on your point of view. When I transfer a file via HTTP, it's just as stateless as, say, FTP.
Yeah, I guess it's all about point of view. If the only thing you do with FTP is to transfer a single file, then close the connection - then sure, it's like HTTP 1.0.
However, FTP was designed as a much more interactive protocol - you open the connection, authenticate, browse through the directory tree, get directory listings, upload files, download files, maybe use 'chmod' (an unofficial but commonly supported extension), etc., and finally disconnect. That is what you can't do with HTTP - with HTTP you connect, optionally authenticate, upload or download a single file (or get a single directory listing, or post a single transaction), and automatically disconnect.
Sure, you can emulate one with the other - web browsers usually support FTP and make it look stateless, and the client and server can each cache a connection state handle (aka cookie) to make HTTP seem as though it persists across requests. With HTTP 1.1 you can even reuse a connection for multiple transactions, to mitigate the setup cost of TCP. But under the hood, the protocols are simply designed differently.
they couldn't be bothered to put the full UN-abbridged version of their dictionary on the web? that's truly sad.
Why is that sad? Where is your unabridged dictionary on the web?
I have both the M-W unabridged, and their 10th Collegiate (similar to what is on m-w.com). Guess what - I keep the latter within arm's reach when reading, for when I come across a word I don't know, or want to know more about. My unabridged has sat on its shelf for months. It's nice to have both, sure - but at my education level, very rarely indeed do I come across a word that's only in the unabridged. (William F. Buckley produces one every now and then. His vocabulary is scary, and he is an incorrigible show-off.)
Slashdot Mirror
Kind of like RAID5 versus RAID10? I.e. what is called RAID10 would for most of us fall under the definition of RAID5?
Correct. gcc and AIX xlc compilers by default output the common subset - the moral equivalent of -march=486 or so.
Mostly extensions, a few dropped or changed facilities. It's worth noting that the PowerPC is much closer to its immediate ancestor the POWER2. Here are some highlights of POWER -> 32-bit PowerPC, taken from The PowerPC Architecture (IBM, 1994):
The main changes listed for POWER2 -> 32-bit PowerPC seem to be dropping several opcodes for floating point loads/stores, and some semantics of FP <-> int conversions.
Well, Linus has started integrating it, so you'll get your wish.
As to whether NT is superior, it depends on if you measure by flexibility or by ease-of-use. NT ACLs are hella flexible - you can grant or deny a whole range of permissions to anyone you wish. The Unix "read write execute / owner group other" seems horribly primitive by comparison. But it comes at a cost. NT does not come with any sane way to manage permissions. The GUI tool? Puh-leeze. It can't even add / remove users from a tree of files without resetting every file in the tree to the same ACL. It doesn't give access to the "deny" half of an ACL either - everything is "start from zero, and allow". It doesn't seem to have any "summary mode" or search capabilities - you have to click on objects individually to find out their status, which gets pretty old on even a small filesystem.
The command line CACLS.EXE is not much better. It is some better, but still does not have a "search" mode, or an easily greppable output format - there seems to be no equivalent to "find -user" or "find -perm".
Finally, although the order of ACL entries is significant in NT, the tools (both GUI and CACLS.EXE) do not seem to provide access to the ordering. (CACLS lets you view the order, but not change it; the GUI goes so far as to sort the entries alphabetically! - misleading at best.) This is a fatal flaw, and shows that either the tools are inadequate, or the system is overdesigned. (IMHO, both.)
Windows 2000 is a bit better - the GUI at least gives you access to the "deny" half of things, and exposes the "inherit permissions" functionality which can simplify life considerably.
Unix / Linux, on the other hand, may not have ACLs, but frankly, with a few well-chosen groups you usually don't need ACLs anyway. (My evidence: AIX and IRIX do have ACLs, yet in several years of AIX/IRIX administraction, I've never actually used them, or wanted to.) And, thanks to both the simplicity of the scheme and the maturity of the tools, Unix permissions are much easier to manage than NT ACLs, in my experience. (Speaking of which, I may as well admit some serious bias, since I've had a lot more experience managing Unix than NT.)
It is nothing of the sort. For one thing, you should look up the word unconscionable - "I do not think it means what you think it means." For another, if you think it such a great crime, why don't you undertake to integrate it?
Hint: "integrate" does not mean "take the SGI patch and throw it at Linus". It means "comb through SGI's patch, figure out what all was added to the kernel to support XFS, and take it apart feature by feature." Then, for each separate feature:
Finally, when Linus has merged enough of your patches that XFS has all it needs, send Linus the XFS filesystem code itself. At this point Linus will most likely take it. If Linus has objections to the XFS code itself, work with him to clean it up as necessary. Remember, just because code was good enough for IRIX doesn't mean it's good enough for Linux. (:
Here endeth the XFS Integration Mini-HOWTO.
What? You don't want to be the one who gets to do all that after all? Then quitcher bellyachin'.
OK, you asked for it. I'll answer the question. Why is there not an implementation of locate (or slocate, which is much the same thing) which indexes filesystem changes in real time?
Because of the kernel/user split. locate and slocate operate in user mode, getting information from the kernel in bulk, when updatedb is run. File creation / linking / unlinking / renaming happens in the kernel. There is no general interface for the kernel to alert userspace of changes to the filesystem - which means locate has no way of picking up updates short of rescanning the whole filesystem for them, manually. As you'll notice when you run updatedb, this is a laborious process, not suitable for running in real time. (Indeed, if you want real time, use find. locate was invented specifically for its cache - that's the only real advantage it has over find.)
As to the callback, the concept exists in the form of directory notifications, where an application can request a list of directories its wants to be notified about. The kernel then makes it known when one of these changes in some way - link, unlink, rename. I know this has been implemented for Linux, but I don't believe it has made it into the mainstream kernels. It could be put to good use by a file manager application, or a "desktop icon manager" like the Windows Explorer shell.
Having a similar callback for an entire filesystem - well, apparently nobody has found it necessary yet, and it would probably slow down a lot of filesystem workloads / benchmarks. Richard Gooch's devfs filesystem for device nodes does have this - it's called the devfsd protocol - but of course it's specific to the devfs partition.
(Actually, I just remembered - as of 2.5.27 Linus is in the process of merging LSM. This is a security module framework which presumably would make it fairly easy to provide such filesystem-wide notifications to userspace. I don't yet know any more about it than that, at present.)
So ... next question ... why not just do locate in kernel space? In short, too little benefit for too much complexity - i.e. it would be seen as bloat.
The Linux mount program knows about SGI XFS labels. I'm pretty sure it doesn't parse labels for FAT, HPFS or NTFS (yes they all have them) or whatever other filesystems have labels - probably because nobody really needs to specify label-based FAT mounts in fstab (it's a legacy format anyway). Plus, FAT/HPFS/NTFS labels are much harder to extract than ext2/ext3 and XFS labels, which are in fixed fields in a fixed superblock. (In FAT, the label is a pseudo-file in the root directory.)
Well, we know God Mode won't work, since God doesn't play dice with the universe.
And you believe this why, Mr Chamberlain?
Just the CPU. You want good floating point support [which is why Titanic used 500 dual-Alpha boxes], and memory bandwidth, and of course lots of Hz are always nice.
Theoretically a renderer could use a GPU for a coprocessor, but I believe render software is so complex that any GPU on the market today would be too specialised to be of much use. Hardware acceleration works for games because the game developer can tailor the rendering requirements / algorithms to the capabilities of the hardware (as abstracted by OpenGL and Direct3D, or via vendor extensions to same). Render software, OTOH, is at the mercy of what the modeler / animator / compositor wants, and they are not willing to settle for "whatever the hardware can do the fastest".
I agree with you, but to play Devil's Advocate, there are sometimes reasons you want a fast CPU, not just a fast cluster. Our SGI sales guy often tries to make this point, for the obvious reasons, but it's true.
If you are rendering out a large number of frames, you want the most possible aggregate CPU power, because rendering is extremely parallelisable (each frame stands alone). So 50 Athlons is better than 40 Xeons. But if you are just rendering out a 5- or 10-frame test sequence, and the wall is not already overloaded - then you want the 40 Xeons instead, since each one can take a frame and you'll get your result back faster.
There is also the issue of network bandwidth. In some cases you can benefit quite a bit by having fast boxes with as many CPUs per box as possible. This is because there is a non-trivial network burden in sending out the job to be rendered, along with all its textures, images, etc. This can be mitigated by multicasting and caching - but I don't know to what extent Renderman does this - but I know if you don't design it right, it can really slow down your jobs. (We evaluated one render distribution system that relied on Windows SMB file sharing for its I/O. Sending a 200-MB job to each of 10 render crunchers pretty much killed it.)
Done, see the IBM Power4 (basically a 64-bit PowerPC with some extensions, but not peer-compatible with the G3/G4/G5 line from Mot/Apple) which I believe has 2 or 4 logical CPUs per die. The little boys are moving this way too - ever since the Pentium or so, Intel and competitors have been putting multiple pipelines and execution units in a single CPU, to be scheduled as needed by a component known as the "instruction scheduler", which takes responsibility for making sure any parallelism has no side effects - that it behaves as though completely serialised, only faster. The Intel Xenon^WXeon does one better with a feature they call "hyperthreading", whereby the instruction scheduler becomes an actual multi-CPU scheduler, portraying to the OS two logical CPUs per physical CPU, in order to make better use of the redundant execution units.
You didn't answer his objection: "isn't that what editors are for?" He wasn't talking about Emacs, he was talking about Taco. If editors don't edit, what exactly do they do?
So you're saying these machines are so fast they are rendering the movie in time for me to have seen it several months ago? Xenon processors must use faster-than-light conduits of some sort. (:
I think it more likely that these machines are being used for The Two Towers, and possibly Return of the King, though who knows - they might be used a little in perfecting the extra 30 minutes of FotR that haven't been released yet.
Do they? I know they have drivers for their video chips, but what about the ATA133 IDE? What about the USB 2.0 controller, or the auxilliary USB 1.1 controller to handle USB1 devices? What about the NV Ethernet (not the 3Com one, that'll work for sure)? What about the AGP bridge (not to be confused with the video chip)? What about the audio controller? What about miscellaneous features (if present) such as hardware health sensors, watchdog, random number generator, etc?
Do any of the nForce 2 chipset components, apart from the 3C920, support Linux? According to v2.5 kernel sources, the nForce ATA100 IDE chip is supported (and the ATA133 chip is probably similar, so will be supported soon), and the nForce audio (seems to be covered by the Intel i8xx audio driver - once again, nForce 2 audio is probably similar or identical, but who knows?) but I don't see any mention of the others.
Token-ring-over-UTP-Ethernet! (:
You're thinking "eth0:0" etc, and this is true only if you use ifconfig, which doesn't support "advanced" features. With Alexey Kuznetsov's ip utility:
(Meaning should be obvious..)
How about a few more flashbacks of the ring being cut off Sauron's hand?
I gave them major cool points for announcing the DVD release plans to the world a few months ago so we wouldn't get suckered into the "buy the same movie n times" gimmick, on which I believe George Lucas has a patent.
`Fool of a Took!' Gandalf definitely knew of Durin's Bane, and was quite wary of disturbing the deeps of Moria. He didn't know specifically what the Balrog was:
Reluctantly have to agree. One of my favorite scenes was where Galadriel made it a point to make Gimli feel at home, to great and lasting effect on Gimli. Obviously not one of Jackson's favorite scenes, though.... I wonder whether Jackson expects us to believe Gimli and Legolas became such close buddies ex nihilo..
Hmmm, they say the Galadriel GIF-giving scene is back, which is good. But what of the rest of Lothlórien? Peter Jackson omitted what may be my favorite passage in the whole book:
That is one of the most important bits (IMHO) of character development - it completely redefines Gimli. And if it doesn't show up on the extended DVD, I may never forgive Mr Jackson. (:
Am I the only one who read the article title as a paraphrase for "Microsoft invades Peru for Lebensraum"?
Yeah, I guess it's all about point of view. If the only thing you do with FTP is to transfer a single file, then close the connection - then sure, it's like HTTP 1.0.
However, FTP was designed as a much more interactive protocol - you open the connection, authenticate, browse through the directory tree, get directory listings, upload files, download files, maybe use 'chmod' (an unofficial but commonly supported extension), etc., and finally disconnect. That is what you can't do with HTTP - with HTTP you connect, optionally authenticate, upload or download a single file (or get a single directory listing, or post a single transaction), and automatically disconnect.
Sure, you can emulate one with the other - web browsers usually support FTP and make it look stateless, and the client and server can each cache a connection state handle (aka cookie) to make HTTP seem as though it persists across requests. With HTTP 1.1 you can even reuse a connection for multiple transactions, to mitigate the setup cost of TCP. But under the hood, the protocols are simply designed differently.
Why is that sad? Where is your unabridged dictionary on the web?
I have both the M-W unabridged, and their 10th Collegiate (similar to what is on m-w.com). Guess what - I keep the latter within arm's reach when reading, for when I come across a word I don't know, or want to know more about. My unabridged has sat on its shelf for months. It's nice to have both, sure - but at my education level, very rarely indeed do I come across a word that's only in the unabridged. (William F. Buckley produces one every now and then. His vocabulary is scary, and he is an incorrigible show-off.)