There are industrial Core 2 Quad systems out there with ISA slots. I don't know how much power you need on your acquisition platform, but I think that'll probably fit the bill.
The tolerances for a decent low-order detonation aren't *that* tight.
Your post shows that your knowledge of explosives is terribly inadequate for arguing your position.
The implosion detonation sequence does need to be quite tight timing wise, but it uses shaped charge methods and explosive "lensing" effects via combinations of fast and slow detonating explosives. Those charges produce the implosive shockwave, most of the detotative force is projected inward, rather than outward.
A shaped-charge expert could probably figure out what would need to be done quite handily.
The timing parts are taken care of via wires cut to the same length, reliable switches with known timing characteristics, etc.
Explosive lens design is described in a few places, including a couple of patents and is available via the Internet.
The really nifty part is that you can machine metal "blanks" out of whatever dense inert metal you have handy and test these explosive "lens" configurations in whatever handy blast pit you have available. When the blank comes out of the test process the desired size and shape, you know you've probably got the right configuration.
While gun type weapons are not out of reach, implosion type devices are not out of the realm of possibility.
It's nominally on utility line power, through rectifiers, with batteries floating on the bus. There's diesels or gas turbines driving it, so yes, you are correct, there is extensive power backup for these.
But the original poster was right, if the backhauls to the cell-switches go down during a major disaster, which did happen during hurricane Katrina, it's not going to matter how many cell sites have generators. Especially when their parent MTSO (cell switch office) is UNDERWATER, which can and did happen, during Katrina.
It's quite disconcerting to find out that the reason you can't get an office's WAN links restored is because the CO that the office is homed from has a foot or two of water over the roof.
Secondarily, with many ILECs putting in remote terminals (SLCs, DLCs, Litespans, etc, instead of copper back to the CO) in new construction and retrofits for DSL, FIOS and whatnot, the problem actually gets worse. Your phone line may end up terminating on one of those, not run back to the CO. The problem comes in because the RTs only have a few hours of battery, up to 8 hours max, typically. There's generator outlets on a lot of them, but during an outage over an extended area, it's not uncommon for a few to go down as the phone crews can't move the generator trailers around fast enough to keep all of them charged.
Oh, and the T1s to some of these cell sites? Are on remote terminals. Multiple points of failure, anyone?
Is it? Read the extract of the report, below. The way I read it, it was only a series of operations carried out WITHOUT understanding what was happening that saved the reactor vessel - had the vessel not been flooded with water, 20 tons of molten fuel would have breached the vessel.
No, they didn't entirely understand what the water levels and what the exact state of the reactor was. Out of the TMI-2 accident came a whole pile of lessons learned, a lot of which were to require the installation of a heck of a lot more instrumentation on other operating reactors to back up the existing instrumentation. Additionally the control room ergonomics and operating procedures were updated to make information flow a lot more perceptable to the reactor operators, including a audio feedback system that generated ambient noise based on what the plant was doing.
To say "had the vessel not been flooded with water, 20 tons of molten fuel would have breached the vessel." is misleading. The vessel BY DESIGN is supposed to be full of water, and the lack of water is what contributed to the core melting, but there was STILL enough water to quench the molten remains.
Again, even if the vessel had been breached, my original comments still stand regarding containment and the overall defense-in-depth of the containment designs.
The point was that this was supposed to have already been "impossible" - which begs the question - what other unforseen circumstances could have occured if the reactor vessel ruptures?
No, it wasn't considered to be impossible. A lot of the defense-in-depth was designed around a massive primary cooling loop failure consisting of a massive double-ended pipe shear. The containment was overengineered by a couple of factors to take into consideration that not every failure mode could be accommodated, and that the reactor assemblies may have to be contained for quite a while.
Hmm.. People dont realise just how close 3 mile island came to being as bad as Chernobyl - by sheer luck the vessel held the molten glob of reactor fuel. For a little exersize, extrapolate a Chernobyl scale incident to the 3 mile island area..
Frankly, this is bullshit.
What a lot of people don't understand about the TMI-2 incident is that it was very close to being a "worst case" Loss Of Coolant Accident (LOCA), and proved that the safety of the design was VALID.
While the core did fracture and melt, it fell to the bottom of the reactor vessel and was quenched by the residual water in the bottom of the vessel. Sheer luck had nothing to do with, the designs, as created, worked as planned. Even if the vessel had failed, there's a sump below the reactor vessel with over a million gallons of water in it, which would have done the same thing, quenching the material and keeping it covered. Additionally, you have several feet of concrete in the foundation and a few feet of concrete forming the walls of the primary containment. If I recall correctly, during the hydrogen "burn" that happened during the TMI-2 incident, the strain gauges buried in the primary containment walls didn't really show any kind of overstress of the building.
Contrast that to Chernobyl, which was more or less a warehouse holding a graphite pile, where when the reactor (with a flawed design) suffered a steam explosion and caught fire, all that molten graphite and reactor fuel poured down pipe fittings, stairwells and hallways in the building. Then they had to hastily entomb the reactor to keep it from spewing even more contamination.
Compare that to TMI-2, which, in a sense, was already "entombed" BY DESIGN. Some of their first steps after the incident was to put in post-accident radiation monitors, and seal the thing off for a few years until it was safe enough to start the cleanup efforts.
To call it "sheer luck" is misleading and a disservice to those who designed the containment systems.
"Add $3,000-8,000 for 20 24 port switches (trendnet or netgear switches will be fine, 20 of them so that you have some spares)"
Are you freaking kidding me? If you're gonna run a LAN party or a small office, those are fine for switches. They may even work in a totally flat configuration.
The minute you try to do inter-switch VLANs or anything other than "flan LAN", they fall apart. Their management interfacing is also shit.
BTW, switches come in greater than 24 port configurations, these days.
My recommendation would be a set of HP Procurve 2650s for the workstations (48 10/100 + 2 1000BT) + 1 spare, and a pair for 2824s (24 gig ports) for the core of the network and for servers. Lifetime warranty, firmware is free, documentation wasn't written in Engrish.
Other than the fact that it's a really insanely bad idea and IIRC violates the Cat5 spec, you'd be right about cable sharing. In the 10base days, that'd probably work, but 100base is a little more sensitive.
Recent PBX systems also use a digital format for their control and encoding modes. We recently ran across this where a contractor tried to screw us on a new run by splitting pairs off a ethernet cable (our patch panels are side-by-side in the same space) and splicing it behind the racks. We'd requested a new pull to the location for exactly that reason. (They converted a printer area to a desk, hence why there was no voice cable there before).
We don't have much of an on-site IT presence out here, and it took us quite a bit of time for us to put it all together why that workstation was having so many problems.
Never mind that GigE uses all four pairs and is becoming increasingly common these days.
I really hate to tell you this, but Dell's laser printer offerings are really rebadged Lexmark units, with the same shitty utilities. This is assuming, of course, that Lexmark printers are not OEM'd from somewhere else.
We just got done reviewing one. Same shitty printer, same shitty utilities. My boss didn't get it until I was showing him that the NDPS gateway module that needed to be loaded to interface to it was the Lexmark gateway.
He had been arguing that it was a Dell printer, no matter that it looked just like the two Lexmark printers right next to it.
Point being, it's still HP competing against Lexmark, even though it says Dell.
I fail to see how a few open() and close() calls are "practically writing a whole new operating system". Or "writing a new computer programming language".
You have to write code to input data into the system somehow right? Oracle or Postgres isn't going to attach to/dev/audio and read in data, right? You have to present a user interface. Woe is you! You have to write code for weeks! Sob!
I maintain a few large databases and UNIX systems as part of my job. I use these tools all the time. It's never taken "weeks upon weeks" to get my job done. Code modularity has been around for a while now. I suggest you use it.
On the backups: Arcserve, at least, has an online database backup system using agents bolted onto the DBMS. Or, at the very least, the DBMS dumps the data to a filesystem in snapshot format, and that's backed up by Arcserve.
If a shop managing large amounts of data in the multimedia or scientific computing fields can't hire an administrator or two (At less than $75,000, at least around here, public sector pays pretty low compared to private), they deserve whatever foul-ups and data-loss that occurs. If they haven't budgeted for administrators along with all that fancy 64-bit hardware, they're asking for trouble. Who runs the servers? It's a strawman, anyway.
As for rsync and whatnot, most database systems can call external programs from stored procedures.
There's also filesystem clustering, SAN solutions that could tie systems together, SAN mirroring between storage chassis.
In 2004, we shouldn't be worrying about much of this, I agree. The point is, you can either work with it, around it, or write your own operating system with a built-in RDBMS.
The reason that the tube front-end doesn't overload is because it's not as sensitive to begin with.
Most of the rigs out there these days just have shitty bandpass filtering built in, making it seem like the silicon is at fault for the front-end overloading.
When they try to pack in every feature under the sun and then make the rig "DC to daylight", something has to give, otherwise the unit is HUGE. The filters are usually the first to go.
I mean, these are fools^Wpeople who shell out megabucks for a braided silver power cord because it results in a "cleaner sound". And gold plated supertwisted *digital* audio interconnect cables because it "really brings out the highs".
PT Barnum, if alive today, would probably be running a audiofool supply business.
File reference data type? Give me a break. Haven't you used a char or varchar to store a filename before? Or heck, generate the filename using your primary key, if possible.
Arcserve and backup exec will backup all files in a directory hierarchy, at least if the hierarchy is the only thing defined. Otherwise more than a few sysadmins would have to rebuild backup jobs every single day.
Rsync or a shell script can duplicate the data between servers.
I do agree that you should be able to extend datatypes, but you're going to get into cross platform issues no matter what if you define your own datatypes.
It would probably be better to get a RDBMS that's cross platform and take some of the extended functions and datatypes and use those, if you're so intent on storing everything in the database. I agree that it should be pristine SQL, but sometimes you've just got to get the job done.
I'd hate to work where you do if NDPS, of all things, is a friggin' political issue. It's a damned transport, for crying out loud. But I suppose you know this.
IPX is still very easy to turn on. I'm currently migrating 28 sites to NW6 (shortly to be NW6.5) from NW3.2.
Yes, it sucks big, jagged, pointy rocks.
As for the Jetdirect/IPX issue, that's very easily solved with 6+ by the use of NDPS. Using the NDPS Manager and Gateway modules you can print directly to the printers using IP. You also get auto driver deployment, printer installs and updates with it too. (Yes, trolls, I know Win2K/NT has had this for quite some time)
We plan on being IP only by the end of this year.
Re:SCO still packs a punch?
on
SCO SCO SCO!
·
· Score: 1
About to release Netware 6?
Than what's this four-month-old production server doing in my server room running NW 6 SP2?
If you can't figure out how to download a floppy image and do a FTP install, or download the base dir for your arch and burn that to a CD and install, you shouldn't even try.
Hell, you shouldn't even try using anything other than windows, if you want your hand held.
Ooooh, no.isos, it must suck. Get your head out of your ass and reread the docs.
What's the advantage to this over a tradition UPS, other than being built into the case? Switching back and forth from two batteries will actually use more power than using the standard AC-DC-battery float-Inverter configuration that most (if not all) commercial UPS systems use.
It takes more energy to charge a battery to it's capacity than the capacity itself. This is due to various resistances in the charging system itself. With most batteries, you can only charge at a certain replenisment rate, as the chemical changes can happen only so fast, and any excess power during the cycle will be dissipated as heat.
Which, also incidentally, blows away your theory of "much less time to charge a cell than to draw it down". You can do this in small configurations (cellphone charger whilst using the phone at the same time), but I can draw down a deep cycle lead-acid cell faster than I can fast charge it with no load on it.
Well, if you're going to throw a driver into the mix, I see your point very nicely. I was purely coming from a hardware standpoint. The driver telling the controller what to cache on a regular basis would be nice, especially if it's somewhat admin controllable.
Wow, first intelligent conversation I've participated in on slashdot in months. Amazing.
Slashdot Mirror
There are industrial Core 2 Quad systems out there with ISA slots. I don't know how much power you need on your acquisition platform, but I think that'll probably fit the bill.
If you're used to dealing with the AVR, and the C language on the AVR, the Arduino already looks awfully hacker unfriendly.
The tolerances for a decent low-order detonation aren't *that* tight.
Your post shows that your knowledge of explosives is terribly inadequate for arguing your position.
The implosion detonation sequence does need to be quite tight timing wise, but it uses shaped charge methods and explosive "lensing" effects via combinations of fast and slow detonating explosives. Those charges produce the implosive shockwave, most of the detotative force is projected inward, rather than outward.
A shaped-charge expert could probably figure out what would need to be done quite handily.
The timing parts are taken care of via wires cut to the same length, reliable switches with known timing characteristics, etc.
Explosive lens design is described in a few places, including a couple of patents and is available via the Internet.
The really nifty part is that you can machine metal "blanks" out of whatever dense inert metal you have handy and test these explosive "lens" configurations in whatever handy blast pit you have available. When the blank comes out of the test process the desired size and shape, you know you've probably got the right configuration.
While gun type weapons are not out of reach, implosion type devices are not out of the realm of possibility.
Well, if there's no power, the answering machine won't answer, right?
*grin*
It's nominally on utility line power, through rectifiers, with batteries floating on the bus. There's diesels or gas turbines driving it, so yes, you are correct, there is extensive power backup for these.
But the original poster was right, if the backhauls to the cell-switches go down during a major disaster, which did happen during hurricane Katrina, it's not going to matter how many cell sites have generators. Especially when their parent MTSO (cell switch office) is UNDERWATER, which can and did happen, during Katrina.
It's quite disconcerting to find out that the reason you can't get an office's WAN links restored is because the CO that the office is homed from has a foot or two of water over the roof.
Secondarily, with many ILECs putting in remote terminals (SLCs, DLCs, Litespans, etc, instead of copper back to the CO) in new construction and retrofits for DSL, FIOS and whatnot, the problem actually gets worse. Your phone line may end up terminating on one of those, not run back to the CO. The problem comes in because the RTs only have a few hours of battery, up to 8 hours max, typically. There's generator outlets on a lot of them, but during an outage over an extended area, it's not uncommon for a few to go down as the phone crews can't move the generator trailers around fast enough to keep all of them charged.
Oh, and the T1s to some of these cell sites? Are on remote terminals. Multiple points of failure, anyone?
No, they didn't entirely understand what the water levels and what the exact state of the reactor was. Out of the TMI-2 accident came a whole pile of lessons learned, a lot of which were to require the installation of a heck of a lot more instrumentation on other operating reactors to back up the existing instrumentation. Additionally the control room ergonomics and operating procedures were updated to make information flow a lot more perceptable to the reactor operators, including a audio feedback system that generated ambient noise based on what the plant was doing.
To say "had the vessel not been flooded with water, 20 tons of molten fuel would have breached the vessel." is misleading. The vessel BY DESIGN is supposed to be full of water, and the lack of water is what contributed to the core melting, but there was STILL enough water to quench the molten remains.
Again, even if the vessel had been breached, my original comments still stand regarding containment and the overall defense-in-depth of the containment designs.
No, it wasn't considered to be impossible. A lot of the defense-in-depth was designed around a massive primary cooling loop failure consisting of a massive double-ended pipe shear. The containment was overengineered by a couple of factors to take into consideration that not every failure mode could be accommodated, and that the reactor assemblies may have to be contained for quite a while.
Frankly, this is bullshit.
What a lot of people don't understand about the TMI-2 incident is that it was very close to being a "worst case" Loss Of Coolant Accident (LOCA), and proved that the safety of the design was VALID.
While the core did fracture and melt, it fell to the bottom of the reactor vessel and was quenched by the residual water in the bottom of the vessel. Sheer luck had nothing to do with, the designs, as created, worked as planned. Even if the vessel had failed, there's a sump below the reactor vessel with over a million gallons of water in it, which would have done the same thing, quenching the material and keeping it covered. Additionally, you have several feet of concrete in the foundation and a few feet of concrete forming the walls of the primary containment. If I recall correctly, during the hydrogen "burn" that happened during the TMI-2 incident, the strain gauges buried in the primary containment walls didn't really show any kind of overstress of the building.
Contrast that to Chernobyl, which was more or less a warehouse holding a graphite pile, where when the reactor (with a flawed design) suffered a steam explosion and caught fire, all that molten graphite and reactor fuel poured down pipe fittings, stairwells and hallways in the building. Then they had to hastily entomb the reactor to keep it from spewing even more contamination.
Compare that to TMI-2, which, in a sense, was already "entombed" BY DESIGN. Some of their first steps after the incident was to put in post-accident radiation monitors, and seal the thing off for a few years until it was safe enough to start the cleanup efforts.
To call it "sheer luck" is misleading and a disservice to those who designed the containment systems.
"Add $3,000-8,000 for 20 24 port switches (trendnet or netgear switches will be fine, 20 of them so that you have some spares)"
Are you freaking kidding me? If you're gonna run a LAN party or a small office, those are fine for switches. They may even work in a totally flat configuration.
The minute you try to do inter-switch VLANs or anything other than "flan LAN", they fall apart. Their management interfacing is also shit.
BTW, switches come in greater than 24 port configurations, these days.
My recommendation would be a set of HP Procurve 2650s for the workstations (48 10/100 + 2 1000BT) + 1 spare, and a pair for 2824s (24 gig ports) for the core of the network and for servers. Lifetime warranty, firmware is free, documentation wasn't written in Engrish.
MicroBSD ripped off major chunks of the site, docs and disto by stripping the copyright notices and doing other things which violated the BSD license.
They fucked up by essentially doing a s/OpenBSD/MicroBSD/
Check out this Wikipedia link for somewhat more info.
Other than the fact that it's a really insanely bad idea and IIRC violates the Cat5 spec, you'd be right about cable sharing. In the 10base days, that'd probably work, but 100base is a little more sensitive.
Recent PBX systems also use a digital format for their control and encoding modes. We recently ran across this where a contractor tried to screw us on a new run by splitting pairs off a ethernet cable (our patch panels are side-by-side in the same space) and splicing it behind the racks. We'd requested a new pull to the location for exactly that reason. (They converted a printer area to a desk, hence why there was no voice cable there before).
We don't have much of an on-site IT presence out here, and it took us quite a bit of time for us to put it all together why that workstation was having so many problems.
Never mind that GigE uses all four pairs and is becoming increasingly common these days.
Technically you could call a directory a "data store". If so, this is no different than setuid/setgid, right along with sudo.
I really hate to tell you this, but Dell's laser printer offerings are really rebadged Lexmark units, with the same shitty utilities. This is assuming, of course, that Lexmark printers are not OEM'd from somewhere else.
We just got done reviewing one. Same shitty printer, same shitty utilities. My boss didn't get it until I was showing him that the NDPS gateway module that needed to be loaded to interface to it was the Lexmark gateway.
He had been arguing that it was a Dell printer, no matter that it looked just like the two Lexmark printers right next to it.
Point being, it's still HP competing against Lexmark, even though it says Dell.
I fail to see how a few open() and close() calls are "practically writing a whole new operating system". Or "writing a new computer programming language".
/dev/audio and read in data, right? You have to present a user interface. Woe is you! You have to write code for weeks! Sob!
You have to write code to input data into the system somehow right? Oracle or Postgres isn't going to attach to
I maintain a few large databases and UNIX systems as part of my job. I use these tools all the time. It's never taken "weeks upon weeks" to get my job done. Code modularity has been around for a while now. I suggest you use it.
On the backups: Arcserve, at least, has an online database backup system using agents bolted onto the DBMS. Or, at the very least, the DBMS dumps the data to a filesystem in snapshot format, and that's backed up by Arcserve.
If a shop managing large amounts of data in the multimedia or scientific computing fields can't hire an administrator or two (At less than $75,000, at least around here, public sector pays pretty low compared to private), they deserve whatever foul-ups and data-loss that occurs. If they haven't budgeted for administrators along with all that fancy 64-bit hardware, they're asking for trouble. Who runs the servers? It's a strawman, anyway.
As for rsync and whatnot, most database systems can call external programs from stored procedures.
There's also filesystem clustering, SAN solutions that could tie systems together, SAN mirroring between storage chassis.
In 2004, we shouldn't be worrying about much of this, I agree. The point is, you can either work with it, around it, or write your own operating system with a built-in RDBMS.
Oh heck yes.
The reason that the tube front-end doesn't overload is because it's not as sensitive to begin with.
Most of the rigs out there these days just have shitty bandpass filtering built in, making it seem like the silicon is at fault for the front-end overloading.
When they try to pack in every feature under the sun and then make the rig "DC to daylight", something has to give, otherwise the unit is HUGE. The filters are usually the first to go.
Ayup.
I mean, these are fools^Wpeople who shell out megabucks for a braided silver power cord because it results in a "cleaner sound". And gold plated supertwisted *digital* audio interconnect cables because it "really brings out the highs".
PT Barnum, if alive today, would probably be running a audiofool supply business.
File reference data type? Give me a break. Haven't you used a char or varchar to store a filename before? Or heck, generate the filename using your primary key, if possible.
Arcserve and backup exec will backup all files in a directory hierarchy, at least if the hierarchy is the only thing defined. Otherwise more than a few sysadmins would have to rebuild backup jobs every single day.
Rsync or a shell script can duplicate the data between servers.
I do agree that you should be able to extend datatypes, but you're going to get into cross platform issues no matter what if you define your own datatypes.
It would probably be better to get a RDBMS that's cross platform and take some of the extended functions and datatypes and use those, if you're so intent on storing everything in the database. I agree that it should be pristine SQL, but sometimes you've just got to get the job done.
Why the heck do you want to store the data in a RDBMS of all things?
Couldn't you just create a file and reference the file and all other related information from the DB?
Seems that storing and recalling of all that audio information would be fairly inefficient from a DB system.
Then again, I don't know all the angles.
*raises an eyebrow*
I'd hate to work where you do if NDPS, of all things, is a friggin' political issue. It's a damned transport, for crying out loud. But I suppose you know this.
Good luck, mate.
s/an option to replace/the default instead of/
IPX is still very easy to turn on. I'm currently migrating 28 sites to NW6 (shortly to be NW6.5) from NW3.2.
Yes, it sucks big, jagged, pointy rocks.
As for the Jetdirect/IPX issue, that's very easily solved with 6+ by the use of NDPS. Using the NDPS Manager and Gateway modules you can print directly to the printers using IP. You also get auto driver deployment, printer installs and updates with it too. (Yes, trolls, I know Win2K/NT has had this for quite some time)
We plan on being IP only by the end of this year.
About to release Netware 6?
Than what's this four-month-old production server doing in my server room running NW 6 SP2?
Wow, your reading comprehension sucks.
.isos, it must suck. Get your head out of your ass and reread the docs.
If you can't figure out how to download a floppy image and do a FTP install, or download the base dir for your arch and burn that to a CD and install, you shouldn't even try.
Hell, you shouldn't even try using anything other than windows, if you want your hand held.
Ooooh, no
And it's called APRS/Packet radio.
Which also can allow for messages and weather data.
And the associated packet TNCs can allow for low speed data, as one poster asked for.
The lameness filter sucks big pointy rocks.
YHBT HAND...
"All those tubes and wires and careful notes!"
What's the advantage to this over a tradition UPS, other than being built into the case? Switching back and forth from two batteries will actually use more power than using the standard AC-DC-battery float-Inverter configuration that most (if not all) commercial UPS systems use.
It takes more energy to charge a battery to it's capacity than the capacity itself. This is due to various resistances in the charging system itself. With most batteries, you can only charge at a certain replenisment rate, as the chemical changes can happen only so fast, and any excess power during the cycle will be dissipated as heat.
Which, also incidentally, blows away your theory of "much less time to charge a cell than to draw it down". You can do this in small configurations (cellphone charger whilst using the phone at the same time), but I can draw down a deep cycle lead-acid cell faster than I can fast charge it with no load on it.
"All those tubes and wires and careful notes!"
Well, if you're going to throw a driver into the mix, I see your point very nicely. I was purely coming from a hardware standpoint. The driver telling the controller what to cache on a regular basis would be nice, especially if it's somewhat admin controllable.
Wow, first intelligent conversation I've participated in on slashdot in months. Amazing.
"All those tubes and wires and careful notes!"