I've had disks fail almost all at the same time before.
It's really annoying when the following happens:
- Disk 1 dies in a RAID5 set - Hot spare (Disk 4) comes online and starts rebuilding - Disk 2 dies during the rebuild thrashing - Rebuild never completes - Put in 2 new disks - Restore a backup - Disk 3 fails during restoration, pulling in the hot swap (one of the new disks) - A year later, the original hot spare (Disk 4) fails, leading to another rebuild
From my own experiences, the main culprit in these sorts of cases tend to be the bearings. Why they have a tendency to go at the same time, I have no idea. Haven't had it happen lately, but I know I'd rather avoid the problem.
Usually though, it's not the make/model/build date that is the issue, but the batch number (especially for the parts rather than the drive). Parts tend to get allocated in batches, so if you get a batch of say.... bearings, that aren't up to snuff, that batch of drives will probably fail earlier, while others (even ones manufactured on the same date) will be fine.
Note to Hollywood: Please don't remake "The Andromeda Strain" unless you can do a damn good job! Past experience has proven that the chances of this happening (doing a good job) are pretty damn low.
Basically it's a close-range imager for cracks in the tiles, to reduce the need for manual inspection. Little detail in that link, but the question is: Was it was made for the ground crew or the shuttle crew to inspect the tiles?
Still, at least they have the SSPTS (Station-to-Shuttle Power Transfer System) available and working, which gives them a few more days in orbit to evaluate and fix things.
Do #3. On the way, if we get to #2, send them the details (they are not travelling the speed of light, so any message will catch up), and retro-fit en route. And if we get to #1, once again, retro-fit, except this time, you'd be able to catch up and take the parts/details to them!
Even better, with #1, you could simply STOP the arks where they are, and use them as relay points. Turn them into science stations, livable habitats, places for negotiation, whatever.
I do agree though the idea of using one big ark is rather silly, eggs in one basket and stuff. Lots of smaller ones, but not TOO small.
The tests are ok. Sure we need more (like later versions of software, assuming that it runs of course), but at least it's a start. I look at all the green's as a "these bits work ok" and anything worse than yellow as "this needs a lot of work". Beyond that, I wouldn't read anything else into it.
We also need to know what version of the NVidia driver was used, on XP and on Linux, as this will make a huge difference. It'd also be good to know some other stuff about each setup (eg: DirectX version and patch level under XP, kernel version under Linux), etc.
As for these older tests not being significant: Bullcrap! So many games use bits of DirectX and the like that have been in there since well before 2000. While the tests are not the be-all and end-all, they are the building blocks that need to be completed before we jump headlong into the next level. Lets not get ahead of ourselves.
I mailed the guy with a few criticisms and ideas, so maybe we'll see some more info shortly. Note that I did this politely - people tend to listen to polite suggestions, as compared to knee-jerk style frustrated yelling and bitching.
Someone in the LinuxBIOS project wanted to be able to boot other OS's, but needed BIOS emulation.
Bochs already had a BIOS written, but needed a wrapper layer. Such a wrapper now exists and is called ALDO, and is part of the LinuxBIOS V1 source tree. From what is mentioned, it's not in V2 simply because no one wants it currently.
From what I can gather, ALDO is actually just an ELF executable, so it's quite possible that EFI could load it off disk - Viola, you've got a BIOS.
This has been a problem with most systems based on Direct Sequence Spread Spectrum, specifically those with overlapping channels in the 2.4 Ghz band.
Note that the reason the band is supposedly 11 channels (14 are defined, and the number of channels you can use in various countries are restricted, etc etc) dates back to the original 802.11 standard, which had a maximum throughput of 2 Mbps, and a much smaller channel width. With a much smaller channel width, these channels really were non-overlapping. But as the speed goes up, the "spread" of the transmission covers other channels each side of the "main" channel.
The original 802.11 standard however not only covered Direct Sequence stuff, but Frequency Hopping Spread Spectrum devices. You can't talk to FHSS stuff with DSSS stuff, and vice versa, which is a compatibility pain. A lot of FHSS devices are used in warehouses and the like, as FHSS is fairly immune to noise, but had a much lower limit on it's speed (2 Mbps or slightly more if you go vendor specific). Also, in the early days of wireless, FHSS stuff cost a lot more to produce. FHSS uses a hopping set (usually between 1 and 3) and a hopping sequence (usually between 1 and 26) to determine what channels it will use, and in what order. This allows a lot of combinations that try to avoid each other, reducing interference. It's also a lot harder to sniff out a FHSS network, and many of the devices out there don't support monitoring of any sort (ala what programs like kismet rely on), as most stuff is actually done in hardware. That's not to say it's not possible though, and many FHSS networks have very poor security (as they haven't gone further than WEP with 128 bit keys).
It should be noted that the Bluetooth standard uses an FHSS implementation, so the costs have come down quite a bit, though Bluetooth is also a fair bit slower, which makes it cheaper to produce.
Is there any specific location or country you'd like to go to do a show? Mainly to debunk a myth that developed in that region of the world, or even just because you think it's a nice place?
An idea tumbling around in my head is that they should make a much larger rover, but not really like the other rovers. Sure it may have some special sensing equipment that the other rovers wouldn't have (due to size) but it's not to replace the existing rovers, but to augment them.
The small rovers are slow at covering large distances. And they do suffer problems (dogged wheel, getting caught long-term in craters, unknown software glitches leaving them stranded, etc). So why not make a large rover that can:
1. Transport them about over larger distances. This will boost the lifetime of the actual wheels on the existing rovers no end.
2. Retrieve and possibly even service them. Being able to clean them, charge them, and give them software fixes if they're totally dead, etc. You could even do this regularly during a transport opportunity.
3. Be used as a data repeater/processor on the surface. Assemble stuff, remove the redundancy, and only transmit the relevant information. There's satellites that do this, like the one over Singapore that actually has a StrongARM based Linux cluster on it. If power ever becomes a concern, you can always throttle back the number of "machines" in the cluster just by turning them off.
Also, since this thing will be designed for transporting one of the existing rovers, when you send it to Mars, do the obvious thing: Send another rover with it!
There are quite a number of conferences that happen around the Open Source community, and many of the lectures and tutorials are recorded. The Linux Conference of Australia (and it's coming up again btw) is a good resource, and most of the talks that have been sone over the last few years are available in Speex format. You'd have to convert to some other format if whatever you're listening on can't do Speex. Also remember that some of these talks really do require you to look at the slides, so it's probably better aimed at someone with a laptop.
The Internet Storm Centre's "Follow the Bouncing Malware" diary entries (written by Tom Liston) covers passthison.com (which belongs to Spamford). Quite a good read.
At my office I seem to inherit all the hardware that DOESN'T work. It's not that it is actually dead or anything, it's that the company that made it has most likely vanished, and so new drivers are not available. When I plug these devices into my faithful Linux laptop, it just works fine. And I'm not exactly talking old hardware (like the SCSI2Go PCMCIA Future Domain SCSI controller, which I've had since about 1996 sometime), but NEW hardware (like a USB-to-Serial adapter that was released in late 2001).
Funnily enough, the only thing that I have hardware-wise that doesn't work with Linux is a Mustek gSmart 350 digital camera, and that has experimental support now with gphoto2, so I'm not too fussed. With any luck it'll be working soon.
Not sure about the download, but I'm pushing out around a steady 150 kBytes/sec (wavers between 130-175 kB/s on average, and managed to peak it at 198 kBytes/sec.
Averaging around about 100-110 tcp connections (both directions), peaked at about 120 when I was doing 198 Kb/s.
They could upgrade the Access Points, yes. For the LAPD however, if I was running the show, I'd be waiting till 802.11g is a proven technology, and that Symbol could produce decent equipment around the 802.11g standard.
Other things of note:
Symbol Technologies have not released an 802.11g capable device (Hand Held or Access Point) yet. The Symbol devices are very rugged, and they need a very long battery life if they are to be used in the field for any length of duration. Changing anything, including the radio card, could increase the drain on the battery. It's no use if you can get things 3-4 times faster if your battery only lasts 1/8th the time.
Wideband WAN stuff will require special cards in the units, which once again will be a battery drain. An alternative option of course is to have Wideband from the patrol car to the network, while still using 802.11b/g from the patrol car to the Hand Held unit. A number of logistic companies use this sort of system (using systems capable of mobile data, such as GSM and GPRS), though many connect the device serially in the vehicle instead of via RF.
Since they mention they are using the Symbol units, I feel I should mention something about the Symbol Access Points (and their units).
Firstly, Symbol now support a system they call Keyguard(tm) that basically adds TKIP (Temporal Key Integrity Protocol). This uses the inital wep key that is programmed into the units as an initalisation vector (or as set by some other authentication method, like Kerberos), and only as a data transport for key management when there is no other key. The keys are automatically rotated after a specific time limit (definable on the Access Point), and each MAC level device gets a different key.
Secondly, Symbol supports EAP, 802.11x and Kerberos for authentication onto the network. With Kerberos rather than Radius (which is also supported by the Access Points), you get faster authentication times, and propagation across the Access Points, authorising access to the network (which in this case, is considered a service).
They could always use Xcellenet (a management utility, works with Palm and WinCE based devices), which allows you set up the device to be wiped cleaner than an egg if they ever reconnect to the network once they have been marked stolen.
Given the way TurboPower ships most of it's components, I'd actually think this will not be much of a problem.
Pretty much when you bought a license of one of their components (such as AsyncPro), you got the source. One of my friends found a few bugs in AsyncPro, worked out how to fix them, and then alerted TurboPower about the bug and the fix. So the source has previously had a number of eyes outside of TurboPower actually reviewing it.
Plus (as I mention elsewhere) TurboPower have already got quite a number of their components working under Kylix, and seem pretty clueful on the whole. They seemed to have an attitude of "well, we need this, so lets write it ourselves!" rather than always resorting to high level API's or 3rd party modules.
Slashdot Mirror
I've had disks fail almost all at the same time before.
It's really annoying when the following happens:
- Disk 1 dies in a RAID5 set
- Hot spare (Disk 4) comes online and starts rebuilding
- Disk 2 dies during the rebuild thrashing
- Rebuild never completes
- Put in 2 new disks
- Restore a backup
- Disk 3 fails during restoration, pulling in the hot swap (one of the new disks)
- A year later, the original hot spare (Disk 4) fails, leading to another rebuild
From my own experiences, the main culprit in these sorts of cases tend to be the bearings. Why they have a tendency to go at the same time, I have no idea. Haven't had it happen lately, but I know I'd rather avoid the problem.
Usually though, it's not the make/model/build date that is the issue, but the batch number (especially for the parts rather than the drive). Parts tend to get allocated in batches, so if you get a batch of say.... bearings, that aren't up to snuff, that batch of drives will probably fail earlier, while others (even ones manufactured on the same date) will be fine.
Oh wait, they already have....
The Andromeda Strain (1971)
Note to Hollywood: Please don't remake "The Andromeda Strain" unless you can do a damn good job! Past experience has proven that the chances of this happening (doing a good job) are pretty damn low.
Only just before this mission (STS-118).
r eless_scanner.html
http://www.nasa.gov/mission_pages/shuttle/news/wi
Basically it's a close-range imager for cracks in the tiles, to reduce the need for manual inspection. Little detail in that link, but the question is: Was it was made for the ground crew or the shuttle crew to inspect the tiles?
Still, at least they have the SSPTS (Station-to-Shuttle Power Transfer System) available and working, which gives them a few more days in orbit to evaluate and fix things.
RTFA!
It's RICHMOND, VA, CANADA! Not Redmond! And definitely NOT the US.
I'm in Australia (miles away from either), and even I know that's wrong!
PS: I'm sure someone really had Microsoft on the brain here!
"Downtown" doesn't really give much indication of where. Especially for those of us not in the states. :P
As an aside, I'm guessing that people in Boston would have never seen one of these post boxes, except mebbe as pieces of exploding shrapnel.
Do #3. On the way, if we get to #2, send them the details (they are not travelling the speed of light, so any message will catch up), and retro-fit en route. And if we get to #1, once again, retro-fit, except this time, you'd be able to catch up and take the parts/details to them!
Even better, with #1, you could simply STOP the arks where they are, and use them as relay points. Turn them into science stations, livable habitats, places for negotiation, whatever.
I do agree though the idea of using one big ark is rather silly, eggs in one basket and stuff. Lots of smaller ones, but not TOO small.
Tom Liston, a handler at SANS ISC well known for his various takes on Malware problems has a good take on this entitled Phollow the Phlopping Phish on the ISC Handler diary. Covers what it looks like to a user, and why it all falls down.
The tests are ok. Sure we need more (like later versions of software, assuming that it runs of course), but at least it's a start. I look at all the green's as a "these bits work ok" and anything worse than yellow as "this needs a lot of work". Beyond that, I wouldn't read anything else into it.
We also need to know what version of the NVidia driver was used, on XP and on Linux, as this will make a huge difference. It'd also be good to know some other stuff about each setup (eg: DirectX version and patch level under XP, kernel version under Linux), etc.
As for these older tests not being significant: Bullcrap! So many games use bits of DirectX and the like that have been in there since well before 2000. While the tests are not the be-all and end-all, they are the building blocks that need to be completed before we jump headlong into the next level. Lets not get ahead of ourselves.
I mailed the guy with a few criticisms and ideas, so maybe we'll see some more info shortly. Note that I did this politely - people tend to listen to polite suggestions, as compared to knee-jerk style frustrated yelling and bitching.
Many good answers elsewhere, but if you DO pay for any training yourself, check to see if you can get tax concessions/rebates.
Sames applies to things like magazine subscriptions, club subscriptions, conferences, etc.
Hey, if you DO have to pay for it yourself, you may as well get something back if you are entitled to it!
Note: This will entirely depend on your tax laws, and I can't comment on your situation, as IANAA (I am not an American).
Someone in the LinuxBIOS project wanted to be able to boot other OS's, but needed BIOS emulation.
Bochs already had a BIOS written, but needed a wrapper layer. Such a wrapper now exists and is called ALDO, and is part of the LinuxBIOS V1 source tree. From what is mentioned, it's not in V2 simply because no one wants it currently.
From what I can gather, ALDO is actually just an ELF executable, so it's quite possible that EFI could load it off disk - Viola, you've got a BIOS.
The Security Enhanced Bootloader for Operating Systems - Phase 2 page covers detail on how it all works (not a detailed explanation).
This has been a problem with most systems based on Direct Sequence Spread Spectrum, specifically those with overlapping channels in the 2.4 Ghz band.
Note that the reason the band is supposedly 11 channels (14 are defined, and the number of channels you can use in various countries are restricted, etc etc) dates back to the original 802.11 standard, which had a maximum throughput of 2 Mbps, and a much smaller channel width. With a much smaller channel width, these channels really were non-overlapping. But as the speed goes up, the "spread" of the transmission covers other channels each side of the "main" channel.
The original 802.11 standard however not only covered Direct Sequence stuff, but Frequency Hopping Spread Spectrum devices. You can't talk to FHSS stuff with DSSS stuff, and vice versa, which is a compatibility pain. A lot of FHSS devices are used in warehouses and the like, as FHSS is fairly immune to noise, but had a much lower limit on it's speed (2 Mbps or slightly more if you go vendor specific). Also, in the early days of wireless, FHSS stuff cost a lot more to produce. FHSS uses a hopping set (usually between 1 and 3) and a hopping sequence (usually between 1 and 26) to determine what channels it will use, and in what order. This allows a lot of combinations that try to avoid each other, reducing interference. It's also a lot harder to sniff out a FHSS network, and many of the devices out there don't support monitoring of any sort (ala what programs like kismet rely on), as most stuff is actually done in hardware. That's not to say it's not possible though, and many FHSS networks have very poor security (as they haven't gone further than WEP with 128 bit keys).
It should be noted that the Bluetooth standard uses an FHSS implementation, so the costs have come down quite a bit, though Bluetooth is also a fair bit slower, which makes it cheaper to produce.
Is there any specific location or country you'd like to go to do a show? Mainly to debunk a myth that developed in that region of the world, or even just because you think it's a nice place?
An idea tumbling around in my head is that they should make a much larger rover, but not really like the other rovers. Sure it may have some special sensing equipment that the other rovers wouldn't have (due to size) but it's not to replace the existing rovers, but to augment them.
The small rovers are slow at covering large distances. And they do suffer problems (dogged wheel, getting caught long-term in craters, unknown software glitches leaving them stranded, etc). So why not make a large rover that can:
1. Transport them about over larger distances. This will boost the lifetime of the actual wheels on the existing rovers no end.
2. Retrieve and possibly even service them. Being able to clean them, charge them, and give them software fixes if they're totally dead, etc. You could even do this regularly during a transport opportunity.
3. Be used as a data repeater/processor on the surface. Assemble stuff, remove the redundancy, and only transmit the relevant information. There's satellites that do this, like the one over Singapore that actually has a StrongARM based Linux cluster on it. If power ever becomes a concern, you can always throttle back the number of "machines" in the cluster just by turning them off.
Also, since this thing will be designed for transporting one of the existing rovers, when you send it to Mars, do the obvious thing: Send another rover with it!
There are quite a number of conferences that happen around the Open Source community, and many of the lectures and tutorials are recorded. The Linux Conference of Australia (and it's coming up again btw) is a good resource, and most of the talks that have been sone over the last few years are available in Speex format. You'd have to convert to some other format if whatever you're listening on can't do Speex. Also remember that some of these talks really do require you to look at the slides, so it's probably better aimed at someone with a laptop.
The Internet Storm Centre's "Follow the Bouncing Malware" diary entries (written by Tom Liston) covers passthison.com (which belongs to Spamford). Quite a good read.
Following the Bouncing Malware: Part I
http://isc.sans.org/diary.php?date=2004-07-23
Following the Bouncing Malware: Part II
http://isc.sans.org/diary.php?date=2004-08-23
Following the Bouncing Malware: Part III
http://isc.sans.org/diary.php?date=2004-11-04
Following the Bouncing Malware: Part IV
http://isc.sans.org/diary.php?date=2004-11-24
At my office I seem to inherit all the hardware that DOESN'T work. It's not that it is actually dead or anything, it's that the company that made it has most likely vanished, and so new drivers are not available. When I plug these devices into my faithful Linux laptop, it just works fine. And I'm not exactly talking old hardware (like the SCSI2Go PCMCIA Future Domain SCSI controller, which I've had since about 1996 sometime), but NEW hardware (like a USB-to-Serial adapter that was released in late 2001).
Funnily enough, the only thing that I have hardware-wise that doesn't work with Linux is a Mustek gSmart 350 digital camera, and that has experimental support now with gphoto2, so I'm not too fussed. With any luck it'll be working soon.
Ahhh, morse. The way to deal with a single key keyboard. All this just to save on desk space. Where will it end?
Uploads have dropped to less than 50kB/s for me, and I've gotta go home, so the client goes bye bye. No outbound data charges here fortunately!
Notes:
Link: 2 Mbit fibre (UEComm, Australia)
Max Upload: 198 kBps
Max TCP connections: 123
Outbound data transferred: 570+ MiB
Using BitTorrent:
Not sure about the download, but I'm pushing out around a steady 150 kBytes/sec (wavers between 130-175 kB/s on average, and managed to peak it at 198 kBytes/sec.
Averaging around about 100-110 tcp connections (both directions), peaked at about 120 when I was doing 198 Kb/s.
So who else thought "Someone has gone and made the 'Earth' program out of Snow Crash", when they first saw the article?
Then again, the software has been around for a while. I wonder if the people who wrote it got the idea out of Snow Crash?
All I wanna know is, where is Hiro, and who is playing the part of Raven?
They could upgrade the Access Points, yes. For the LAPD however, if I was running the show, I'd be waiting till 802.11g is a proven technology, and that Symbol could produce decent equipment around the 802.11g standard.
Other things of note:
Symbol Technologies have not released an 802.11g capable device (Hand Held or Access Point) yet. The Symbol devices are very rugged, and they need a very long battery life if they are to be used in the field for any length of duration. Changing anything, including the radio card, could increase the drain on the battery. It's no use if you can get things 3-4 times faster if your battery only lasts 1/8th the time.
Wideband WAN stuff will require special cards in the units, which once again will be a battery drain. An alternative option of course is to have Wideband from the patrol car to the network, while still using 802.11b/g from the patrol car to the Hand Held unit. A number of logistic companies use this sort of system (using systems capable of mobile data, such as GSM and GPRS), though many connect the device serially in the vehicle instead of via RF.
Since they mention they are using the Symbol units, I feel I should mention something about the Symbol Access Points (and their units).
Firstly, Symbol now support a system they call Keyguard(tm) that basically adds TKIP (Temporal Key Integrity Protocol). This uses the inital wep key that is programmed into the units as an initalisation vector (or as set by some other authentication method, like Kerberos), and only as a data transport for key management when there is no other key. The keys are automatically rotated after a specific time limit (definable on the Access Point), and each MAC level device gets a different key.
Secondly, Symbol supports EAP, 802.11x and Kerberos for authentication onto the network. With Kerberos rather than Radius (which is also supported by the Access Points), you get faster authentication times, and propagation across the Access Points, authorising access to the network (which in this case, is considered a service).
They could always use Xcellenet (a management utility, works with Palm and WinCE based devices), which allows you set up the device to be wiped cleaner than an egg if they ever reconnect to the network once they have been marked stolen.
I think he's still on the ballot in Florida.
Given the way TurboPower ships most of it's components, I'd actually think this will not be much of a problem.
Pretty much when you bought a license of one of their components (such as AsyncPro), you got the source. One of my friends found a few bugs in AsyncPro, worked out how to fix them, and then alerted TurboPower about the bug and the fix. So the source has previously had a number of eyes outside of TurboPower actually reviewing it.
Plus (as I mention elsewhere) TurboPower have already got quite a number of their components working under Kylix, and seem pretty clueful on the whole. They seemed to have an attitude of "well, we need this, so lets write it ourselves!" rather than always resorting to high level API's or 3rd party modules.