Actually, no. SCSI is a group of standards, including a command set and signalling. The protocol would be SCSI-1, SCSI-2, SAS, iSCSI, etc. What you're talking about is the SCSI command set, which runs over a number of signalling protocols on a variety of physical interconnects. You spoke of "attaching" disks which implies (to me, at least) interconnect (from physical connection up through device signalling).
Wrong. There are movies in both formats on a single disc even.
None of the studios is producing for both formats.
Wrong. Warner and Paramount are producing for both formats.
Especially for formats that require hi-def tvs to notice a difference, which aren't even remotely near a 10% install base yet.
Wrong. About one is six households has a high definition set.
Still too early to make a call in the "format wars" though. Current sales numbers of Blu-ray players are inflated by the PS3 (counting only standalone players there's 200k HD-DVD, 30k Blu-ray) and disc sales are skewed by vouchers and rebates bundled with the PS3.
Re:Any advantages over having only one connector?
on
eSATA Connectors
·
· Score: 1
Aside from every drive controller being ATA (with PATA vanishing over time).
There's really not a market for putting anything but commodity drives on firewire - if performance is a concern, you'll hook SCSI, SAS or FC up to SCSI, SAS or FC.
No. But some variant of the patches are in trunk for the next release. It really just adds a config option though. Not as big a deal as the brouhaha would suggest.:)
Really? I couldn't find any on their website and have never heard of IA-32/64 architecture being pushed that far. According to their products site only their POWER based machines are 64-way, their Intel/AMD units are four socket (16 cores at most).
To be fair, the aging bus archiecture of the current Xeons is definitely a hinderance onec you move beyond commodity servers. In terms of widely available machines, you're still generally looking at 16 core (four quad core Xeon or eight dual core Opterons). Howver, Intel is set to debut CSI (Common System Interface) to replace the front side bus and AMD is set to transition to Hypertransport 3.0, both of which will support at least sixteen quad core CPUs.
The Cell is being looked at by large banks and they are sufficiently interested to set up specialist teams to see how the architecture can be best used.
I never said it wasn't being looked at. So was the Itanium.:)
The Niagara is a toy with laughable floating point performance; the example unit we got sent ended up as a foot-rest.
A product isn't suitable for applications it wasn't designed for? Shock.
Rock is much more useful (each of the four cores having a dedicated FPU) but the IC design has only just been finalised and the first servers won't be shipping for another year.
There's also a FPU per-core in the UltraSparc T2, which should be available soon. Neither of the Niagara CPUs are a good replacement for the mainstream UltraSparc line, though, since they suffer from the same "weakness" as the Cell - they're good for the subset of problems they're deigned to solve, but mediocre to bad at things they're not designed for.
There's also the problem that it's an extension of the UltraSparc architecture rather than "cool" and new like the Cell. Sadly this is often the deciding factor with IT managers at the very large banks.
And the Cell is just an extension of the PowerPC architecture (yes, I know the SPE implements a new ISA, but that sort of nuance is lost on pointy-hairs) rather than "cool" and new like the Niagara. I mean, come on, the UltraSparc T2 can handle 64 simultaneous threads and the Cell can handle a piddling eight. Big numbers sell just as well as novelty (often better, since novelty comes with free "new and scary").
The Cell's designed, with one PPE and a number of SPEs is very suited to a number of pricing calculations. Many instruments are priced in an iterative manner or by use of monte-carlo. The lack of DMA for the SPEs is not really a problem in these cases as the inputs for each iteration/simulation don't change that much and (in most cases) could be wedged in to the 256K available to each element. You're assertion that Cell is best deployed only for a limited task set is correct, but banking contains such tasks and the Cell appears to be well suited to the role.
Ah, I read "The Cell processor is attracting a lot of attention as a potential replacement for Sparc and requires specialist development machines." as more of a general statement rather than being applicable specifically to banking. Would explain some of the disagreement.
I'm not intimately familiar with financial software, but I was under the impression fixed point arithmetic is generally prefered. I have no idea how the Cell would perform for that makes the performance hit of IEEE-754 mode out of the picture.:)
Youtube is just a site which stores and transfers flash video format files to you, it's not a media player by any means. The media player is stored locally, and its name is "Macromedia Flash Player".
Flash is no more a video player than a java or visual basic runtime is. The virtual machine does include the codecs for displaying the video, but a codec is not a media player.
What if you want to encrypt data on your hard disk?
FTP is a protocol. YouTube is a service providing hosting, indexing, searching, and streaming of media files to users without the need to install any client-side application. I think one is maybe just a teensy bit closer than the other.
Implement a media player on the "software as a service" model.
Umm... YouTube?
Now implement a cryptography library on the "software as a service" model. Oops, you're sending plain text data through the cables...
Encryption of the communication channel is part of the stack (TLS). In a "software as a service" model, data storage would be server-side, so a crypt library beeyond that is pointless. It's like asking where you put the port hole on a bicycle.
Now implement a real time application on the "software as a service" model.
This is one area where it makes sense. Just because a model doesn't serve every niche doesn't mean there's not a trend toward it in the industry.
Now implement a high-end game on the "software as a service" model.
High end games may not be, but look at the explosion of web-based games.
Intel architecture can't provide more than 16 cores.
IBM sells a 64 core Intel based system.
The Cell processor is attracting a lot of attention as a potential replacement for Sparc and requires specialist development machines.
Unlikely. The Cell is PPC, not Sparc. And Sun already has their own highly parallel designs - Niagara (eights cores) and Rock (four cores with four processing engines each).
As much talk as there is about Cell's potential, I'm not convinced. It's not a particularly good general CPU - most of the die space is dedicated with SIMD instructions, which are only useful for a certain class of application. The most obvious market outside real-time video processing would be scientific applications, but the Cell throughput drops from a claimed 218 gigaflops to about 26 gigaflops when you put it in double percision mode (which also enables IEEE standard rounding). Still fairly impressive but you'll only reach that number if you're doing strictly vector math.
Unix revenue was about five billion dollars of the fifteen billion dollar server market in the last quarter of 2006. Yes, Virginia, there are still people working with Solaris, HP/UX and AIX.
Do you have any numbers on this? Sure, the VC and XBoxLive do sell stuff, but I think a large part of that is because it is cheap, not because the games are old rehashes.
Microsoft's latest numbers show 25 million downloads from XBox Live Arcade. Nintendo's last released numbers were 1.5 million downloads from the Virtual Console channel, and that was back in January - only a couple months after launch and before most of the top tier titles (Mario Kart 64, LoZ: Ocarina of Time, Super Mario World, etc).
It's still a silly decision to try to use Macs for mission-critical business machines for just this reason. In my business, if I have a machine go down, I either run down to my local parts store to get the part I need, or I run down to the thrift store and pick up another used beige box for $50. Having a machine down for weeks in not an option. Having a machine down for days, even, is unacceptable in my small business.
You'd run a mission critical application on a $50 used machine? Personally I much prefer having good spare hardware on hand and a same or next business day service contract.
I'd really like to see a source for that. Anecodotal, but in good volume - I have a friend who's been a notebook repair tech for about years and Sony pretty much tops his list for being consistently low quality, with Apple not too far behind (particularly with first revs of new models).
Hard to obtain how exactly? Go to ftp.redhat.com, look at a directory listing. RHEL5 isn't up yet, because it's not released, but there have been publicly available beta ISOs for months, so approximate versions are widely known. For example, distro watch has a table listing versions of the major packages.
I should say that I didn't buy or install this box. It was bought for a biological research institution and the guy who made the purchasing decision chose it because it was Dell's recommended choice. RHEL3 may be ancient, but it came on a fairly new machine, bought in early 2006, so they were obviously still selling it.
That seems a bit off. By early 2006 any current Dell would have been certified for RHEL4 (which itself was released early 2005). As a aside, license for RHEL are valid for any currently supported version, so even if it came imaged with RHEL3 you had right to install RHEL4.
It's fair enough that they focus on rock solid stability over new packages. However, it's a bit disappointing that my employers were still paying a support contract on this box but the package updates that were part of this contract were more than 3 years old.
The updates are not three years old. There was a new update published this morning. The base versions are old, but that's a feature, not a bug. When you're running production systems you want a stable platform with a reasonable deployment cycle, which is where RHEL excels.
I don't think it's too much to expect a little flexibility when you're paying for it.
When you pay for one of the enterprise platforms you're paying for stability not flexibility. It's actually more work for them to backport fixes to older versions than to blindly package newer ones, but new versions mean new bugs and incompatible changes. Some of us pay good money to avoid it, and RPM is flexible and easy enough for the few cases we actually need a newer version than what Red Hat ships stock.
You seem to have the buffer cache and inode cache confused. The former is what deals with filesystem blocks, the later caches file and directory lookups. Anything that's commonly accessed is going to be a cache hit regardless of what your filesystem structure looks like. With less common lookups if the difference between a scan through a half dozen entries and a dozen entries is going to be noise. The only times I've seen a real bottleneck related to directory size are applications where you see hundreds to thousands of files (news feeds, message-per-file mailboxes, etc) and even that's largely a Solved Problem with more modern filesystem designs; see the h-tree index used in ext3 to avoid multi-block directory scans.
Re:Backronym.
on
Define - /etc?
·
· Score: 2, Insightful
Actually, no. SCSI is a group of standards, including a command set and signalling. The protocol would be SCSI-1, SCSI-2, SAS, iSCSI, etc. What you're talking about is the SCSI command set, which runs over a number of signalling protocols on a variety of physical interconnects. You spoke of "attaching" disks which implies (to me, at least) interconnect (from physical connection up through device signalling).
SANs rarely use SCSI as an interconnect (even if it uses SCSI drives). Most often fiber channel (as seems to be the case here), increasingly ethernet.
But yeah, with a SAN you're talking about something that provides a block level interface to storage. Fragmentation is a filesystem level issue.
I don't believe any movie is on both formats.
Wrong. There are movies in both formats on a single disc even.
None of the studios is producing for both formats.
Wrong. Warner and Paramount are producing for both formats.
Especially for formats that require hi-def tvs to notice a difference, which aren't even remotely near a 10% install base yet.
Wrong. About one is six households has a high definition set.
Still too early to make a call in the "format wars" though. Current sales numbers of Blu-ray players are inflated by the PS3 (counting only standalone players there's 200k HD-DVD, 30k Blu-ray) and disc sales are skewed by vouchers and rebates bundled with the PS3.
Aside from every drive controller being ATA (with PATA vanishing over time).
There's really not a market for putting anything but commodity drives on firewire - if performance is a concern, you'll hook SCSI, SAS or FC up to SCSI, SAS or FC.
What gave you the idea that I never heard of FLV? And what does the native container format supported by flash have to do with anything?
It Rhythmbox not a media player because it relies on underlying libraries to do the actual decoding and playback? Or iTunes?
Erm, RHEL didn't even have a desktop variant until 2004. It's a server distribution first and foremost.
If shipping X11 as an option invalidates something as a server distribution, you can write off "OpenBSD, Debian, Slackware, Solaris, etc" as well.
No. But some variant of the patches are in trunk for the next release. It really just adds a config option though. Not as big a deal as the brouhaha would suggest. :)
Rationally, servers should be running OpenBSD, Debian, Slackware, Solaris, etc.
How, exactly, is Red Hat Enterprise not a "rational" choice for a server?
'What's the benefit, support?
A stable platform that will continue receiving security updates until 2014.
Really? I couldn't find any on their website and have never heard of IA-32/64 architecture being pushed that far. According to their products site only their POWER based machines are 64-way, their Intel/AMD units are four socket (16 cores at most).
:)
:)
Try the IBM System x3950. See also the Unisys ES7000/one.
To be fair, the aging bus archiecture of the current Xeons is definitely a hinderance onec you move beyond commodity servers. In terms of widely available machines, you're still generally looking at 16 core (four quad core Xeon or eight dual core Opterons). Howver, Intel is set to debut CSI (Common System Interface) to replace the front side bus and AMD is set to transition to Hypertransport 3.0, both of which will support at least sixteen quad core CPUs.
The Cell is being looked at by large banks and they are sufficiently interested to set up specialist teams to see how the architecture can be best used.
I never said it wasn't being looked at. So was the Itanium.
The Niagara is a toy with laughable floating point performance; the example unit we got sent ended up as a foot-rest.
A product isn't suitable for applications it wasn't designed for? Shock.
Rock is much more useful (each of the four cores having a dedicated FPU) but the IC design has only just been finalised and the first servers won't be shipping for another year.
There's also a FPU per-core in the UltraSparc T2, which should be available soon. Neither of the Niagara CPUs are a good replacement for the mainstream UltraSparc line, though, since they suffer from the same "weakness" as the Cell - they're good for the subset of problems they're deigned to solve, but mediocre to bad at things they're not designed for.
There's also the problem that it's an extension of the UltraSparc architecture rather than "cool" and new like the Cell. Sadly this is often the deciding factor with IT managers at the very large banks.
And the Cell is just an extension of the PowerPC architecture (yes, I know the SPE implements a new ISA, but that sort of nuance is lost on pointy-hairs) rather than "cool" and new like the Niagara. I mean, come on, the UltraSparc T2 can handle 64 simultaneous threads and the Cell can handle a piddling eight. Big numbers sell just as well as novelty (often better, since novelty comes with free "new and scary").
The Cell's designed, with one PPE and a number of SPEs is very suited to a number of pricing calculations. Many instruments are priced in an iterative manner or by use of monte-carlo. The lack of DMA for the SPEs is not really a problem in these cases as the inputs for each iteration/simulation don't change that much and (in most cases) could be wedged in to the 256K available to each element. You're assertion that Cell is best deployed only for a limited task set is correct, but banking contains such tasks and the Cell appears to be well suited to the role.
Ah, I read "The Cell processor is attracting a lot of attention as a potential replacement for Sparc and requires specialist development machines." as more of a general statement rather than being applicable specifically to banking. Would explain some of the disagreement.
I'm not intimately familiar with financial software, but I was under the impression fixed point arithmetic is generally prefered. I have no idea how the Cell would perform for that makes the performance hit of IEEE-754 mode out of the picture.
Youtube is just a site which stores and transfers flash video format files to you, it's not a media player by any means. The media player is stored locally, and its name is "Macromedia Flash Player".
Flash is no more a video player than a java or visual basic runtime is. The virtual machine does include the codecs for displaying the video, but a codec is not a media player.
What if you want to encrypt data on your hard disk?
Then you're a poor market for web services.
FTP is a protocol. YouTube is a service providing hosting, indexing, searching, and streaming of media files to users without the need to install any client-side application. I think one is maybe just a teensy bit closer than the other.
Implement a media player on the "software as a service" model.
Umm... YouTube?
Now implement a cryptography library on the "software as a service" model. Oops, you're sending plain text data through the cables...
Encryption of the communication channel is part of the stack (TLS). In a "software as a service" model, data storage would be server-side, so a crypt library beeyond that is pointless. It's like asking where you put the port hole on a bicycle.
Now implement a real time application on the "software as a service" model.
This is one area where it makes sense. Just because a model doesn't serve every niche doesn't mean there's not a trend toward it in the industry.
Now implement a high-end game on the "software as a service" model.
High end games may not be, but look at the explosion of web-based games.
Not as it's commonly understood, no. 99.9 is commonly refered to as three nines.
Intel architecture can't provide more than 16 cores.
IBM sells a 64 core Intel based system.
The Cell processor is attracting a lot of attention as a potential replacement for Sparc and requires specialist development machines.
Unlikely. The Cell is PPC, not Sparc. And Sun already has their own highly parallel designs - Niagara (eights cores) and Rock (four cores with four processing engines each).
As much talk as there is about Cell's potential, I'm not convinced. It's not a particularly good general CPU - most of the die space is dedicated with SIMD instructions, which are only useful for a certain class of application. The most obvious market outside real-time video processing would be scientific applications, but the Cell throughput drops from a claimed 218 gigaflops to about 26 gigaflops when you put it in double percision mode (which also enables IEEE standard rounding). Still fairly impressive but you'll only reach that number if you're doing strictly vector math.
Unix revenue was about five billion dollars of the fifteen billion dollar server market in the last quarter of 2006. Yes, Virginia, there are still people working with Solaris, HP/UX and AIX.
Do you have any numbers on this? Sure, the VC and XBoxLive do sell stuff, but I think a large part of that is because it is cheap, not because the games are old rehashes.
Microsoft's latest numbers show 25 million downloads from XBox Live Arcade. Nintendo's last released numbers were 1.5 million downloads from the Virtual Console channel, and that was back in January - only a couple months after launch and before most of the top tier titles (Mario Kart 64, LoZ: Ocarina of Time, Super Mario World, etc).
It's still a silly decision to try to use Macs for mission-critical business machines for just this reason. In my business, if I have a machine go down, I either run down to my local parts store to get the part I need, or I run down to the thrift store and pick up another used beige box for $50. Having a machine down for weeks in not an option. Having a machine down for days, even, is unacceptable in my small business.
You'd run a mission critical application on a $50 used machine? Personally I much prefer having good spare hardware on hand and a same or next business day service contract.
I'd really like to see a source for that. Anecodotal, but in good volume - I have a friend who's been a notebook repair tech for about years and Sony pretty much tops his list for being consistently low quality, with Apple not too far behind (particularly with first revs of new models).
Hard to obtain how exactly? Go to ftp.redhat.com, look at a directory listing. RHEL5 isn't up yet, because it's not released, but there have been publicly available beta ISOs for months, so approximate versions are widely known. For example, distro watch has a table listing versions of the major packages.
I should say that I didn't buy or install this box. It was bought for a biological research institution and the guy who made the purchasing decision chose it because it was Dell's recommended choice. RHEL3 may be ancient, but it came on a fairly new machine, bought in early 2006, so they were obviously still selling it.
That seems a bit off. By early 2006 any current Dell would have been certified for RHEL4 (which itself was released early 2005). As a aside, license for RHEL are valid for any currently supported version, so even if it came imaged with RHEL3 you had right to install RHEL4.
It's fair enough that they focus on rock solid stability over new packages. However, it's a bit disappointing that my employers were still paying a support contract on this box but the package updates that were part of this contract were more than 3 years old.
The updates are not three years old. There was a new update published this morning. The base versions are old, but that's a feature, not a bug. When you're running production systems you want a stable platform with a reasonable deployment cycle, which is where RHEL excels.
I don't think it's too much to expect a little flexibility when you're paying for it.
When you pay for one of the enterprise platforms you're paying for stability not flexibility. It's actually more work for them to backport fixes to older versions than to blindly package newer ones, but new versions mean new bugs and incompatible changes. Some of us pay good money to avoid it, and RPM is flexible and easy enough for the few cases we actually need a newer version than what Red Hat ships stock.
You seem to have the buffer cache and inode cache confused. The former is what deals with filesystem blocks, the later caches file and directory lookups. Anything that's commonly accessed is going to be a cache hit regardless of what your filesystem structure looks like. With less common lookups if the difference between a scan through a half dozen entries and a dozen entries is going to be noise. The only times I've seen a real bottleneck related to directory size are applications where you see hundreds to thousands of files (news feeds, message-per-file mailboxes, etc) and even that's largely a Solved Problem with more modern filesystem designs; see the h-tree index used in ext3 to avoid multi-block directory scans.
There's an inode cache for a reason, you know.
It's in /usr/dsylexci/bin
Historical note, the "boot" binary was originally in /etc. :)