Also, the part about the motherboard being able to unplug the controllers is pointless, and dangerous, unless coordinated via the command channel anyway.
Being able to send a 'turn yourself off' command is nearly as low power as actually unplugging it (for example, do you have to unplug/remove batteries of most of your electronics when not using them, or can you just hit the power button to have themselves turn on, and do those electronics have significant power draw in their standby state?).
SATA *does* specify a standard for a power connector and location (most still have the standard ATX power connector). You could feed it through the same cable through the motherboard in theory, though that would increase the power draw of the drive controller significantly. This is mainly for the possibility sane backplanes (including longer ground pins than other pins for hot-swap capability.)
Everyone has 1U SCSI servers, so that's no surprise.
They provide compute density (1/2 U for two processors), nothing more. A significant portion of people I know run blades diskless off of ramdisk or NFS where decent systems actually house the storage. In blades, the only mechanical component that is not hot-swappable is the drive, so there is a desire to not rely on it at all for a lot of people I know.
Hideously expensive to get both gigabit NICs connected? Technically speaking, those Ethernet switch modules are each 18 port gigabit switches, so taking that into account, they aren't so expensive.
A passive copper pass through module to use with external switches is described here, making both a non-blocking network configuration possible and getting the comparison between blades and 1U stand-alones closer to comparing apples and apples.
Of course, something on that blade backplane must be decent enough for ~2 Gb throughput, as they support myrinet daughter cards with an optical pass-through module, which provides a really good networking option for the blades if you have tons of cash.
Yeah, I concur. Actually, I've had nothing but headaches out of dealing with Apple directly when I had faulty hardware (the infamous logic board problem, among other things). To the point of being told they would charge me a non-refundable 70 dollar or so fee to determine if there was a warranty-qualified issue, and that was the only path to get them to do warranty service. Ultimately I learned a local non-apple owned repair shop would do it and dealt with me correctly, but when dealing directly with freaking Compaq even I got better direct warranty service.
That is *exactly* the sort of stuff glib was intended for, to wrap system calls on specific platforms and provide a cross-platform API for basic syscalls. It was the low-layer abstraction of cross-platform things GTK/GDK needed, and has grown from there.
Why yes, it can, guess you learn something every day. In Intel, it's called 'SpeedStep' and is used for power consumption. Of course, if you RTFA, it tells you the same thing. My processor can clock all the way down to 200 MHz (1.7 GHz normally) if I want. My wife's Athlon goes to 400 MHz (1.4 GHz nomally), but that's controlled via 'PowerNow'.
Some good points, but saying a person better have a PhD in Industrial Design before calling an Apple product ugly? That is ridiculous. It is an opinion anyone has, and if the 'experts' came up with a design they thought would be populer and >95% of the population thought differently, guess whose opinion matters more, the 'experts' or the customer market?
Not saying that the opinion *is* widespread, just that dismissing opinions not accompanied by a PhD with respect to aesthetics is kinda silly. I personally think it looks a bit odd myself and not particularly smooth, and that will be my opinion. The link between it and iPod (the apparent marketing goal) is weak to me, aside from both being square, and white.
Wow, you must really lack some real-world experience to make such a cocky declaration. 1. You are right, it isn't hard to write bug-free code, it is nearly impossible for all but the simplest of projects. It is possible to acheive an at least apparently bug-free state, but only in relatively simple applications dealing with a relatively well controlled data set. 2. Point taken that well architected code lends itself well to problem isolation and debug. Most MS software is written in C/C++ still, and those languages can be used well or poorly with respect to modularity. The price to pay for flexibility is that developers can bypass the mechanisms that encourage modular design. Regardless of language a developer can always fail to modularize a design properly, particularly if the application encounters new functional requirements in the middle of a development cycle. 3. Testing an application can be very very hard for even not so complex software. You can of course test a good representative sample of normal operation and likely problematic circumstances, but there are many many variations and those corner cases which they can't know in advance (if so, secure software would be easy...) are where >98% of field problems customers see come out of. 4. Basically the same exact point as 3, of course they do, but, as you say, not all branches of execution are realistically testable, and it is even worse for a commercial entity with limited resource, the problem space is simply too large.
Gig-E network for a lot of parallel applications is horrendus. The throughput isn't too hot, but more importantly the latency is horrid. Myrinet or Infiniband would be a far better choice.
With respect to the complaint about weak processing elements for power/heat considerations, consider that for applications that benefit more from parallelism than fast serial processing, this is a valid approach. Consider IBM BlueGene. It is an extremely high-density processing-element configuration, and each element isn't particularly powerful, and it really has shown to do really well on highly parallel tasks. If you are using many processing elements to solve problems, you are already engineering your problem solving and approach for parallelism. Of course, this requires a *REALLY* good inter-processing element communication network, or it will scale horribly.
So ultimately, it depends on the interconnect between processing elements. If it were a typical SMP system with that many processors, the memory and system resource contention would likely make it highly impractical. If it is a NUMA configuration with really fast interconnects and a well-connected, high speed, low latency mesh network between processing elements, it probably leverages the parallelism well. If on a GigE switch or something like that internally, it will suck badly for all but the most parallel tasks.
System bus: PCI-Express. 10 gigabit/second is about 4x pci-e speed, and systems are coming with 4x, 8x, and 16x slots (though most will be predominantly 1x slots (2.5 gigabit/sec, and 16x will most frequently be reserved for video cards).
With PCIX 64 bit 133MHz you are only at about 8.5 gigabit/sec, so it is true that it won't support...
I can guarantee that by 2010 the state of the art will have moved significantly on.
I like the more specific term simulator sickness to describe motion sickness related to visual perception of movement without inner ear perception.
I know people proned to motion sickness who are fine with games, and people who are bad with games who are fine with being moved without seeing the movement (traditional motionsickness).
A cheapo (~$10) optical mouse I use is here I use the left and right buttons as normal and the thumb button for middle click. The left wheel in the middle can still act like a middle button though...
It would be simple to use whatever system you come across as a linux system. Simply plug in the drive, boot, bootstrap, emerge system, compile a kernel, build some choice packages, wait a few days and voila, instant gentoo box.
Note, Tadpole has been a niche laptop maker for a looong time. I have a Tadpole SPARCbook II lying around (640x480 color screen, slow-ass 32-bit SPARC that was really cool when the laptop was new). They for the early part of their existence made exclusive SPARC architecture laptops running SunOS..
Well, on the ~512 cluster nodes I play with afflicted with reiserfs (SLES8 SP3), I see ever so often in an unclean shutdown the problems mentioned. Sometimes it takes a significant sample size to get good statistical evidence of crappiness. Again, I reiterate my hopes that Reiser4 is architected better and less amatuerish and avoids the problems I've seen plague Reiser3..
They are not saying they cool it *to* 30 degrees F, they are saying *by* 30 degrees F. Dropping the temp by about 30 degrees farenheit is dropping by about 16.7 degrees celsius.
If it worked your way, the can would get colder measuring by farenheit, but get hotter measuring by celsius...
I'm using Reiser on many many systems, >90% on SCSI RAID arrays. Faulty drives, of course, occur sporadically across reiser and non-reiser fs alike, but we replace and rebuild long before we lose two drives.
The difference in circumstance between me and people who swear by reiser is that those who swear by reiser always seem to be in a circumstance to rarely deal with unclean shutdown, whereas in this situation, (testing), we frequently intentionally do unclean shutdowns to simulate events such as power loss, and we have many many systems (~512) that we do such testing on, so problems are maginified by a significant amount.
But here is the reason why I take most Reiser advocates with a grain of salt (beyond my own experience), they always seem to have it on 'important systems', which generally means you are connected to UPS and don't push the system to sudden downtime.
As far as filesystems working when they are allowed to run endlessly or only stopped in an organized unmount or remount read-only, I'm hard-pressed to think of a modern filesystem that has a problem.
However, I administer many many servers, and they are pushed to the limit in many ways. When you have a small, controllable sample to base your views on that is in a really nice situation with respect to uncontrolled shutdown, it isn't a particularly useful circumstance for speaking on reliability. Just for your knowledge, 99% of the systems are hardware-fault tolerant, and the failures follow the reiser filesystem when things are reorganized. Now Reiser4 with the atomic operations may change this if they do what they say, and I'll be interesting to try it out, but I don't hold my hopes too high.
Reiser? Stable? Now those are two words that don't belong in the same sentence.
In dealing with ext3, JFS, and XFS, Reiser has proved the most annoying because first, I have to do a full fsck on it most frequently, and second, a quarter of the time it is the root fs and needs rebuild-tree, which is annoying as freaking hell because you can't even have it mounted read-only. XFS I've had issues with two, but never having to completely umount to fsck. JFS has issues where it's journalling doesn't seem to catch something and it later in the middle of operating, figures out it is inconsistant and remounts read-only for fsck, which is also highly annoying. In all cases, get ready to dig through lost+found and figure out what filenames those inodes used to be associated with.
If you seek stablity (which is extremely key for filesystems), the only way I've found to work is ext3. It is a real slug (a *real* slug), but I would trust it much more readily than any other fs.
Slashdot Mirror
Also, the part about the motherboard being able to unplug the controllers is pointless, and dangerous, unless coordinated via the command channel anyway.
Being able to send a 'turn yourself off' command is nearly as low power as actually unplugging it (for example, do you have to unplug/remove batteries of most of your electronics when not using them, or can you just hit the power button to have themselves turn on, and do those electronics have significant power draw in their standby state?).
SATA *does* specify a standard for a power connector and location (most still have the standard ATX power connector). You could feed it through the same cable through the motherboard in theory, though that would increase the power draw of the drive controller significantly. This is mainly for the possibility sane backplanes (including longer ground pins than other pins for hot-swap capability.)
Cooking Engineers....
Cooking *For* Engineers....
Cooking *Forty* Engineers....
Cooking *For* Forty Engineers....
Everyone has 1U SCSI servers, so that's no surprise.
They provide compute density (1/2 U for two processors), nothing more. A significant portion of people I know run blades diskless off of ramdisk or NFS where decent systems actually house the storage. In blades, the only mechanical component that is not hot-swappable is the drive, so there is a desire to not rely on it at all for a lot of people I know.
Hideously expensive to get both gigabit NICs connected? Technically speaking, those Ethernet switch modules are each 18 port gigabit switches, so taking that into account, they aren't so expensive.
A passive copper pass through module to use with external switches is described here, making both a non-blocking network configuration possible and getting the comparison between blades and 1U stand-alones closer to comparing apples and apples.
Of course, something on that blade backplane must be decent enough for ~2 Gb throughput, as they support myrinet daughter cards with an optical pass-through module, which provides a really good networking option for the blades if you have tons of cash.
Yeah, I concur. Actually, I've had nothing but headaches out of dealing with Apple directly when I had faulty hardware (the infamous logic board problem, among other things). To the point of being told they would charge me a non-refundable 70 dollar or so fee to determine if there was a warranty-qualified issue, and that was the only path to get them to do warranty service. Ultimately I learned a local non-apple owned repair shop would do it and dealt with me correctly, but when dealing directly with freaking Compaq even I got better direct warranty service.
That is *exactly* the sort of stuff glib was intended for, to wrap system calls on specific platforms and provide a cross-platform API for basic syscalls. It was the low-layer abstraction of cross-platform things GTK/GDK needed, and has grown from there.
Why yes, it can, guess you learn something every day. In Intel, it's called 'SpeedStep' and is used for power consumption. Of course, if you RTFA, it tells you the same thing. My processor can clock all the way down to 200 MHz (1.7 GHz normally) if I want. My wife's Athlon goes to 400 MHz (1.4 GHz nomally), but that's controlled via 'PowerNow'.
Oh, that's easy, it must log into P2P networks and download songs for you without ever offering to share anything....
Some good points, but saying a person better have a PhD in Industrial Design before calling an Apple product ugly? That is ridiculous. It is an opinion anyone has, and if the 'experts' came up with a design they thought would be populer and >95% of the population thought differently, guess whose opinion matters more, the 'experts' or the customer market?
Not saying that the opinion *is* widespread, just that dismissing opinions not accompanied by a PhD with respect to aesthetics is kinda silly. I personally think it looks a bit odd myself and not particularly smooth, and that will be my opinion. The link between it and iPod (the apparent marketing goal) is weak to me, aside from both being square, and white.
Wow, you must really lack some real-world experience to make such a cocky declaration.
1. You are right, it isn't hard to write bug-free code, it is nearly impossible for all but the simplest of projects. It is possible to acheive an at least apparently bug-free state, but only in relatively simple applications dealing with a relatively well controlled data set.
2. Point taken that well architected code lends itself well to problem isolation and debug. Most MS software is written in C/C++ still, and those languages can be used well or poorly with respect to modularity. The price to pay for flexibility is that developers can bypass the mechanisms that encourage modular design. Regardless of language a developer can always fail to modularize a design properly, particularly if the application encounters new functional requirements in the middle of a development cycle.
3. Testing an application can be very very hard for even not so complex software. You can of course test a good representative sample of normal operation and likely problematic circumstances, but there are many many variations and those corner cases which they can't know in advance (if so, secure software would be easy...) are where >98% of field problems customers see come out of.
4. Basically the same exact point as 3, of course they do, but, as you say, not all branches of execution are realistically testable, and it is even worse for a commercial entity with limited resource, the problem space is simply too large.
Gig-E network for a lot of parallel applications is horrendus. The throughput isn't too hot, but more importantly the latency is horrid. Myrinet or Infiniband would be a far better choice.
With respect to the complaint about weak processing elements for power/heat considerations, consider that for applications that benefit more from parallelism than fast serial processing, this is a valid approach. Consider IBM BlueGene. It is an extremely high-density processing-element configuration, and each element isn't particularly powerful, and it really has shown to do really well on highly parallel tasks. If you are using many processing elements to solve problems, you are already engineering your problem solving and approach for parallelism. Of course, this requires a *REALLY* good inter-processing element communication network, or it will scale horribly.
So ultimately, it depends on the interconnect between processing elements. If it were a typical SMP system with that many processors, the memory and system resource contention would likely make it highly impractical. If it is a NUMA configuration with really fast interconnects and a well-connected, high speed, low latency mesh network between processing elements, it probably leverages the parallelism well. If on a GigE switch or something like that internally, it will suck badly for all but the most parallel tasks.
You forgot 'longer' (even the full 'longer lasting' makes sense). Ah the juvenille humor potential..
I am constantly bombarded about emails promising 'longer lasting hard drives' something about pills or herbs, this is nothing new.
System bus: PCI-Express. 10 gigabit/second is about 4x pci-e speed, and systems are coming with 4x, 8x, and 16x slots (though most will be predominantly 1x slots (2.5 gigabit/sec, and 16x will most frequently be reserved for video cards).
With PCIX 64 bit 133MHz you are only at about 8.5 gigabit/sec, so it is true that it won't support...
I can guarantee that by 2010 the state of the art will have moved significantly on.
Story that REALLY needed the '... in Japan' subject.
See here if you don't find this funny (search for 'in japan').
I like the more specific term simulator sickness to describe motion sickness related to visual perception of movement without inner ear perception.
I know people proned to motion sickness who are fine with games, and people who are bad with games who are fine with being moved without seeing the movement (traditional motionsickness).
A cheapo (~$10) optical mouse I use is here
I use the left and right buttons as normal and the thumb button for middle click.
The left wheel in the middle can still act like a middle button though...
It would be simple to use whatever system you come across as a linux system. Simply plug in the drive, boot, bootstrap, emerge system, compile a kernel, build some choice packages, wait a few days and voila, instant gentoo box.
-Note: this is a joke.
Note, Tadpole has been a niche laptop maker for a looong time. I have a Tadpole SPARCbook II lying around (640x480 color screen, slow-ass 32-bit SPARC that was really cool when the laptop was new). They for the early part of their existence made exclusive SPARC architecture laptops running SunOS..
Well, on the ~512 cluster nodes I play with afflicted with reiserfs (SLES8 SP3), I see ever so often in an unclean shutdown the problems mentioned. Sometimes it takes a significant sample size to get good statistical evidence of crappiness. Again, I reiterate my hopes that Reiser4 is architected better and less amatuerish and avoids the problems I've seen plague Reiser3..
They are not saying they cool it *to* 30 degrees F, they are saying *by* 30 degrees F. Dropping the temp by about 30 degrees farenheit is dropping by about 16.7 degrees celsius.
If it worked your way, the can would get colder measuring by farenheit, but get hotter measuring by celsius...
How is that strange? 24>3 and 24>9 is strange to you?
I'm using Reiser on many many systems, >90% on SCSI RAID arrays. Faulty drives, of course, occur sporadically across reiser and non-reiser fs alike, but we replace and rebuild long before we lose two drives.
The difference in circumstance between me and people who swear by reiser is that those who swear by reiser always seem to be in a circumstance to rarely deal with unclean shutdown, whereas in this situation, (testing), we frequently intentionally do unclean shutdowns to simulate events such as power loss, and we have many many systems (~512) that we do such testing on, so problems are maginified by a significant amount.
But here is the reason why I take most Reiser advocates with a grain of salt (beyond my own experience), they always seem to have it on 'important systems', which generally means you are connected to UPS and don't push the system to sudden downtime.
As far as filesystems working when they are allowed to run endlessly or only stopped in an organized unmount or remount read-only, I'm hard-pressed to think of a modern filesystem that has a problem.
However, I administer many many servers, and they are pushed to the limit in many ways. When you have a small, controllable sample to base your views on that is in a really nice situation with respect to uncontrolled shutdown, it isn't a particularly useful circumstance for speaking on reliability. Just for your knowledge, 99% of the systems are hardware-fault tolerant, and the failures follow the reiser filesystem when things are reorganized. Now Reiser4 with the atomic operations may change this if they do what they say, and I'll be interesting to try it out, but I don't hold my hopes too high.
Reiser? Stable? Now those are two words that don't belong in the same sentence.
In dealing with ext3, JFS, and XFS, Reiser has proved the most annoying because first, I have to do a full fsck on it most frequently, and second, a quarter of the time it is the root fs and needs rebuild-tree, which is annoying as freaking hell because you can't even have it mounted read-only. XFS I've had issues with two, but never having to completely umount to fsck. JFS has issues where it's journalling doesn't seem to catch something and it later in the middle of operating, figures out it is inconsistant and remounts read-only for fsck, which is also highly annoying. In all cases, get ready to dig through lost+found and figure out what filenames those inodes used to be associated with.
If you seek stablity (which is extremely key for filesystems), the only way I've found to work is ext3. It is a real slug (a *real* slug), but I would trust it much more readily than any other fs.