A more substantial problem is that diffraction limits the effective resolution of an optical system to well above the size of each of these pixels. This is a problem with current sensors at narrow apertures; lenses exhibit a measurable loss of sharpness, typically f/11 and up, because the airy disks expand as the aperture contracts. With hugely dense sensors like this, though... plugging some numbers into a website that explains the whole situation suggests that you'd need to shoot with apertures than f/1.8 to get circles of confusion smaller than the size of a single pixel.
That's right--even "fast" f/2.8 lenses are limited by physics to never being able to project detail onto individual pixels. You could potentially add a deconvolution stage in software to recover additional sharpness, but not in hardware.
Another thing. Do the math: the pixels are 2.1 micrometers square. Compare to trichromatic human vision, which detects red light peaking at 564 nanometers, 0.564 micrometers. The size of a pixel is within a factor of four of the wavelengths they measure. Staggering.
Glass isn't the problem. We need new laws of nature, since we're near the edges of the ones we have now.
Why not pick up the landing gear on the way back? Let's investigate.
Recall: Apollo's flight plan was an initial burn to get into earth orbit, another burn to leave orbit on course for the moon (trans-lunar injection), another burn to get in orbit of the moon, and another burn to leave orbit on course for earth (trans-earth injection). That's it. They didn't return to orbit after leaving the moon. They left the moon, coasted for a couple days, hit their entry interface, then hit the Pacific.
Why? Going back into orbit requires adding two more burns: one to enter Earth orbit, and another to leave it. Adding a rendezvous with the ISS (or any other floating payload) means an additional 1-2 burns to match the orbital planes, an additional burn to raise or lower your orbit, and God knows how long until the orbits of the two vehicles sync. Look at the space shuttle: even with matching the orbital planes and scheduling launch for an ideal rendezvous profile, it takes them 36-48 hours to catch up with the space station.
Trans-earth injection is complicated enough without adding all that. Extra burns means extra propellant, which means extra weight, which is exactly what you're trying to avoid. Not to mention, each of those steps is another opportunity for failure, and how do you abort if you don't have landing gear?
The voter may use a DRE/EBP (DRE/electronic ballot printer) to create and print her multi-ballot see Section 9.3. The voter enters her choices on a touch-screen. The DRE controls the random allocation of marks in each row.
ThreeBallot can be used directly, or as an auditable paper trail for an otherwise electronic system. It doesn't need to be any more complicated for the voters, but it provides a way to check that votes are being tallied correctly.
ThreeBallot does come close but the paper in which it is outlined says right up front that it is susceptible to vote buying schemes and as such is not a practical solution.
The paper also discusses a modification of ThreeBallot that uses exchanged receipts. Again, check it out:
However, the best approach to the problem may derive from thinking about the functions of the receipts a bit more carefully.
The receipt is used in two ways: it is compared by the voter against its corresponding ballot before the ballot is cast, and it is used when the voter checks to see that the bulletin board contains a corresponding ballot.
The voter should check that her receipt actually matches the corresponding ballot that she will be casting, before she casts her three ballots. Only the voter can do this check, and she needs to have her own receipt and her own ballot in hand to do this comparison.
The reconstruction attack only works for an adversary, however, if the voter is known to be bringing a copy of her own ballot home as a receipt....
This last approach, of enabling or requiring exchanges of ballot copies, say by using the Farnel protocol, seems the best. I'm optimistic that it can be implemented in such a way as to prevent an adversary from effectively bribing or coercing voters, even if the adversary could figure out some valid triples of ballots from the bulletin board.
He doesn't need to suggest anything, since others already have. The most intriguing to me is Ron Rivest's ThreeBallot, which I've written an article about. Quoting myself:
The properties of an ideal election system are contradictory. Voters should be able to verify that their votes are counted correctly, but should be able to have their choices kept completely private--in fact, some would say that voters should not be able to prove they voted a certain way, even if they wanted to. So, can both of these goals realistically be achieved without sacrificing each other?
Turns out, yes. This is possible with a simple paper system: no complicated cryptography, no complicated machines, no complicated rules. It satisfies both of the required properties (privacy and verification) and is in every way more tamper-resistant than current elections. It's called ThreeBallot, and it works like this....
Note that electronic "touch-screen" voting systems could also be employed, such that the voter chooses candidates once, and the machine prints a suitable set of paper ballots, without requiring the voter to think about the mechanics of the system.
Check it out. This isn't quite a solved problem in the mathematical sense, but ThreeBallot comes pretty darn close.
The real question is: why is it that the powers that bill will not consider reforming the election process? However, when you think about it, it kind of answers itself.
Okay, who thought it was a good idea to put solar arrays so fragile that they can't withstand small rockets firing on a station that is equipped with those rockets?
Don't believe everything you hear on Slashdot.
ISS is not in imminent danger. First off, it can hold attitude indefinitely on two of four gyros. Second, the solar arrays can withstand the RCS thrusters firing, they just need to lock down the assemblies that rotate the solar arrays first. Therein lies the rub.
The next shuttle mission brings up more parts and re-wires a large section of the ISS's power grid. This means bringing some systems offline for the duration of a spacewalk, reconfiguring them, and bringing them back up shortly thereafter. Naturally, during this process, the ISS will be running on less redundancy than it is now. One of the spacewalks is slated to bring down two of the gyros, on the assumption that the other two can maintain attitude, while running off the new solar arrays which must rotate in order to generate the specified amount of power. Without the other gyro, RCS firings might be necessary, which make the solar cells unhappy.
This is a nontrivial but solvable problem. Solutions currently being proposed:
Bring up the failing gyro for the duration of the spacewalk. It didn't up and die one day -- it's just vibrating a lot, and might do the trick.
Leave the failing gyro off, and be prepared to bring it up only if the one operational gyro can't maintain attitude.
Lock the solar array into a suboptimal orientation, and fire the RCS thrusters as necessary.
Bring up a replacement gyro. They're about 800 pounds and aren't simple to install, which is a lot to be adding to a mission three weeks from launch, so this is unlikely.
Remarkably, that's not how the Oracle reps explained it to me. I went around with then for quite some time trying to figure out a way to get that to happen properly and they kept telling me that there was not a way to protect against a SAN device failure.
When was this? I'm fairly certain that much of what I described won't work on anything older than 10g, and it's really, really painful to attempt this using ASM. This only becomes practical with OCFS2, which (as I recall) is currently supported only by SLES9 SP2, released a few months ago.
As for availability on mysql, The switch limitation is an OS issue. I choose to run an OS that can't handle multiple interfaces per subnet, though that issue has been fixed in the latest version.
Spanning tree protocol is your friend. It's not generally used to provide redundancy all the way to the host (as few operating systems support it), but it works great under Linux. Just make sure that priorities are set correctly -- you don't want a database server becoming the favorite path between switches.
Yep, Oracle RAC requires a quorum disk (CRS calls it a "voting disk"). However, if you use OCFS2 to store the data files (including the voting disk) the solution above cannot produce split-brain. Putting the data files in OCFS2 puts the responsibility of guarding the shared storage in the filesystem, which solves the problem as follows.
Each node in an OCFS2 cluster updates a special file every two second and maintains a TCP connection to its neighbors. If this process doesn't work (i.e. writes are failing, are backlogged, or for whatever reason don't hit the disks in a timely fashion), the node will fence itself. Likewise, if the node starts on fire, it will naturally stop updating the heartbeat data. Either way, other nodes are aware of who is up and who is down, even if the IP network dies. If a node's access to the storage system dies, OCFS2 won't be able to successfully read back its own heartbeat timestamp, and the node fences itself.
Note that this heartbeat procedure happens on the same block device that the data files are on. There's no way to reach the data files unless a node is in agreement with every other node, thus no way to cause "split-brain".
Say, somehow, a series of failures occur all simultaneously that results in Array 1 being connected only to nodes 1-4 and Array 2 being connected only to nodes 5-8. Each node keeps heartbeating, and after a little bit, Node 5 notices that Node 1 hasn't updated its timestamp, but that Node 1 just said that it did (over Ethernet). OCFS2 notices this immediately, much inter-node communication happens, and nodes 5-8 decide to fence themselves, leaving 1-4 as the only nodes allowed to touch either disk array. Still working as advertised.
Let's examine that failure. First, you'd have to terminate the links between both fibre channel switches. Then, you'd have to break uplink 2 on array 1 and uplink 1 on array 2. Then, you'd have to take out the second HBA on nodes 1-4 and the first HBA on nodes 5-8. Simultaneously. And the system handles this gracefully.
Now, what happens when the network goes out too, you ask? Remember that each node has one connection to both switches. Say we lose a switch -- all the nodes fail over to the other one. Hmm. Say we unplug nodes 1-4 from switch 2 and unplug nodes 5-8 from switch 1 -- both switches are connected together directly, and thanks to VLAN trunking, all the nodes can still reach each other. Darn. Say we also unplug that link. Well, both switches are plugged into the rest of the network, right? Assuming you also set up VLAN trunking there, the switches will be able to reach each other through a third switch. Hmm. What if we unplug those, too?
Congratulations! Split-brain! Nodes 1-4 proceed on Array 1 and Switch 1, and nodes 5-8 proceed on Array 2 and Switch 2. You only had to unplug 22 different cables -- eight Ethernet cables and eight FC cables from the nodes to the switches, two inter-switch links (one Ethernet and one FC), two disk array uplinks (one from each array to each switch), and two Ethernet uplinks (one from each Ethernet switch) to the rest of the network -- simultaneously.
Name a DB from a 'big guy' that doesn't require a shared resource. Oracle? Nope. RAC requires a shared storage solution. Lose your single storage device device and you lose access to your db. ... The only time I will EVER have to take my cluster down is to add more storage space or to replace my switch.
Sorry, what? You're bashing Oracle for having a system with a single point of failure, then add two of your own?
"Shared storage" doesn't mean "not highly available". If you're serious about building a database that cannot go down, you get multiple servers, each with two Ethernet interfaces and two Fibre Channel cards. Get two Fibre Channel switches, and two Ethernet switches. Get two Fibre Channel disk arrays. Hook together as follows.
Both disk arrays have one or more uplinks to both FC switches. Each server has one HBA connected to each switch. Then, use Linux multipathing to provide automatic failover in case either switch dies or either HBA dies, and use Oracle ASM or Linux MD to mirror the data so you're good even if you unplug the shared storage.
Set up the servers to use 802.1q VLAN tagging. (Remember, it's a good idea to keep your inter-node communication separate from client-to-server communication.) Create two Ethernet bridges, using the Linux bridging driver, binding eth0.2/eth1.2 to one and eth0.3/eth1.3 to the other. Take the two switches, set up 802.1q on the ports going to your database servers, and connect them together (preferably using high-speed uplinks, but channel bonding works fine). Enable spanning tree on the switches and on the bridges. Connect both switches to the rest of your network.
Now, if a switch starts on fire, spanning tree on the servers will fail over to the other one automatically. If a network cable gets cut or a network card goes out on one node, that one node will fail over all traffic to the remaining interface, and the inter-switch trunk will make everything keep working. Suddenly, you've got a robust network.
So, we've got network and storage covered. What about the database software? Neither MySQL nor Postgres can use this sort of configuration, but Oracle RAC can. Add a dash of TAF, and suddenly, any component -- network switch, database server, SAN switch, disk array -- can fail in the middle of a SELECT and the application won't notice. That is highly available.
Yes, this solution costs more. Our data -- more accurately, the cost of it not being accessible -- justifies the expense. But don't tell me that shared storage is a weakness.
I guess that reception in Europe and elsewhere would depend on how they have their satellites positioned and what kind of orbits they are in.
The Sirius satellites are in inclined, eccentric orbits similar to those used by the Soviet Molniya satellites thirty years ago. They pass low and fast over the southern hemisphere, and spend a long time "hovering" high above the northern hemisphere. This gives a solid line-of-sight pretty much constantly for anywhere north of the equator, even with only three satellites. This sort of orbit also has other advantages, such as a comparatively high ratio of sunlight to eclipse, allowing for smaller/lighter/cheaper batteries.
Given this, Sirius could somewhat easily blanket most of Europe with satellite radio feeds. However, if they aren't selling devices in those markets yet... regardless of where their birds are, they can always choose to turn off the transmitters.
Multicase passwords do HUGE things to the statistics of the problem.
That's why Microsoft's LM hashing algorithm is so cool -- it uppercases your password before hashing. With this algorithm, multicase passwords do nothing to the statistics.
I think I'm okay for a while.
You're okay for about 2 hours and 34 minutes: that's how long it takes to traverse every possible alphanumeric input on the author's test rig. Additionally, the article suggests that tables including every possible LM hash for [A-Z0-9] would occupy only 1.2 TB of space, meaning that these lookups could be done in a matter of milliseconds instead.
From the article, referring to Munich's choosing open-source software over substantially discounted Microsoft offerings:
"Is that a threat to our business? Well, as much as we didn't get that sale or make that customer happy, yes," he answered. "Is it a threat to our overall business? No. There's lots of customers out there and I would hope that we're making all of them happy so they keep coming back."
I find it interesting that Windows is so widely deployed, yet so few people are truly "in love" with the operating system. You'll find people willing to die for Mac OSX, for OpenBSD, for BeOS, for Amiga, for Gentoo, or for any number of other systems -- but to date, I've never met a single person that was truly satisfied with Windows, much less happy or fanatical about it.
People use Microsoft for a number of reasons, none of them at all related to customer satisfaction. Corporate desktops are assumed to be running Windows with Office unless stated otherwise. Data centers are assumed to be running some Windows server edition, to let the admins use Group Policy and other platform-dependent tools that almost make managing those desktops bearable. People use Microsoft because of their monopoly, and Microsoft exploits this.
And remember, no one got fired for choosing Microsoft.
Parsec: A deathmatch space combat game reminiscient of a streamlined Freespace. It packs beautiful visuals and excellent sound effects (including full voiceover and original music). The gameplay isn't bad either [...]
Yeah, other than... there isn't any. The project has been completely adrift (har har) for nearly a year -- the last news entry, dated 5/5/2003, states:
"It is however work-in-progress, and not suitable for end-users. This is purely a developer release, and therefore some things are broken, incomplete or just plain missing. If you just want to play Parsec you will need to wait a bit longer. Compiling this release will not yield the long awaited Parsec Internet version."
The most recent build is from November 2001, and while users are able to connect to each other, it cannot be called a "game" by any stretch of the imagination. Sorry to any Parsec developers (if they still exist) -- while I'd love a new king of the 3d-space shooter genre, Parsec isn't it... not now, and by the way the project looks, not ever.
Blaster disabled a system, but it was fixable. This one can make a total mess.
Oh, whatever.
Several months ago, Microsoft CHKDSK effectively destroyed one of my NTFS partitions -- it managed to screw up $MFT (which points to the location of the Master File Table) and the copy of $MFT within $MFTMirr (which is supposed to be used if $MFT is broken). Anyway, long story short, I spent a couple weeks staring at hex dumps and printouts of the Linux-NTFS project's NTFS documentation. After consuming inordinate amounts of caffeine, I came up with SalvageNTFS, an open-source NTFS data recovery tool that got back all the data I wanted. Assuming the physical media is intact (as in, all read requests to the disk are successful), SalvageNTFS can retrieve data if there is even a single record of the MFT intact.
If the first few sectors of the disk are overwritten, you'll lose the MBR, the partition table, and maybe the boot sector of your first partition. However, the filesystem of that partition is likely to be largely or completely intact. Think: in a few weeks with no prior knowledge of NTFS internals, I created a tool that can continue to operate in this environment. I'd hardly call that a "total mess".
The key difference here is that when something gets posted to Slashdot, people often have the ability to grab and post mirrors. Like this one, for instance.
What's even weirder is, that before the groklaw post, www.sco.com was down, but ftp.sco.com (next IP address) was just fine, which invalidated SCO's claims of a DDoS attack.
Right now, www.sco.com (216.250.128.12) and ftp.sco.com (216.250.128.13) -- both mentioned in the Groklaw post -- are down. I can second your observation that ftp.sco.com was up prior to this hitting the press, implying that something fishy is happening.
Even more fishy: ftp.dev.caldera.com (216.250.128.14) was not mentioned in the post, but is on the same subnet as www and ftp.sco.com. Guess what? It's quite responsive at refusing anonymous logins. Plus, ftp.beta.caldera.com (.15), ftp.iso.caldera.com (.16) work just fine:
$ time wget ftp://ftp.iso.caldera.com/MIRRORS -O/dev/null --12:58:08-- ftp://ftp.iso.caldera.com/MIRRORS
=> `/dev/null' Resolving ftp.iso.caldera.com... done. Connecting to ftp.iso.caldera.com[216.250.128.16]:21... connected. Logging in as anonymous... Logged in! [lameness filter] ==> PORT... done. ==> RETR MIRRORS... done. Length: 792 (unauthoritative)
12:58:09 (773.44 KB/s) - `/dev/null' saved [792]
real 0m0.893s user 0m0.005s sys 0m0.006s
That's a 0.9-second FTP session. Guess what else? Despite.15 and.16 being up, ftp2.sco.com (.17) is down, presumably from the same DDoS.
You think effectively breaking SSL on all of those workstations is a good form of revenge for this sitefinder crap?
I didn't say I would do it; rather, I want to know if using the ceritifcates qualifies as a "Verisign service". Also, dropping the.com/.net domains and going with a different TLD isn't particularly practical, since most of them are many years old and see an absurd amount of daily traffic.
However, the PayFlow account can be closed within a couple weeks, and new certificates can be issued from a different root pretty quickly. Those are the cash cows for Verisign, and the more significant and more likely of the four actions that I may take. Plus, in all of my future e-commerce dealings (like one that's on the table right now), I can inist on using a different merchant account provider, which is another loss for Verisign.
I'm going to call them some more tomorrow -- still no response from Verisign legal. I want someone to know that they will lose business as a result of SiteFinder.
Slashdot Mirror
A more substantial problem is that diffraction limits the effective resolution of an optical system to well above the size of each of these pixels. This is a problem with current sensors at narrow apertures; lenses exhibit a measurable loss of sharpness, typically f/11 and up, because the airy disks expand as the aperture contracts. With hugely dense sensors like this, though... plugging some numbers into a website that explains the whole situation suggests that you'd need to shoot with apertures than f/1.8 to get circles of confusion smaller than the size of a single pixel.
That's right--even "fast" f/2.8 lenses are limited by physics to never being able to project detail onto individual pixels. You could potentially add a deconvolution stage in software to recover additional sharpness, but not in hardware.
Another thing. Do the math: the pixels are 2.1 micrometers square. Compare to trichromatic human vision, which detects red light peaking at 564 nanometers, 0.564 micrometers. The size of a pixel is within a factor of four of the wavelengths they measure. Staggering.
Glass isn't the problem. We need new laws of nature, since we're near the edges of the ones we have now.
Me too!
Why not pick up the landing gear on the way back? Let's investigate.
Recall: Apollo's flight plan was an initial burn to get into earth orbit, another burn to leave orbit on course for the moon (trans-lunar injection), another burn to get in orbit of the moon, and another burn to leave orbit on course for earth (trans-earth injection). That's it. They didn't return to orbit after leaving the moon. They left the moon, coasted for a couple days, hit their entry interface, then hit the Pacific.
Why? Going back into orbit requires adding two more burns: one to enter Earth orbit, and another to leave it. Adding a rendezvous with the ISS (or any other floating payload) means an additional 1-2 burns to match the orbital planes, an additional burn to raise or lower your orbit, and God knows how long until the orbits of the two vehicles sync. Look at the space shuttle: even with matching the orbital planes and scheduling launch for an ideal rendezvous profile, it takes them 36-48 hours to catch up with the space station.
Trans-earth injection is complicated enough without adding all that. Extra burns means extra propellant, which means extra weight, which is exactly what you're trying to avoid. Not to mention, each of those steps is another opportunity for failure, and how do you abort if you don't have landing gear?
This is why they are Rocket Scientists(TM).
ThreeBallot can be used directly, or as an auditable paper trail for an otherwise electronic system. It doesn't need to be any more complicated for the voters, but it provides a way to check that votes are being tallied correctly.
Check it out. This isn't quite a solved problem in the mathematical sense, but ThreeBallot comes pretty darn close.
The real question is: why is it that the powers that bill will not consider reforming the election process? However, when you think about it, it kind of answers itself.
ISS is not in imminent danger. First off, it can hold attitude indefinitely on two of four gyros. Second, the solar arrays can withstand the RCS thrusters firing, they just need to lock down the assemblies that rotate the solar arrays first. Therein lies the rub.
The next shuttle mission brings up more parts and re-wires a large section of the ISS's power grid. This means bringing some systems offline for the duration of a spacewalk, reconfiguring them, and bringing them back up shortly thereafter. Naturally, during this process, the ISS will be running on less redundancy than it is now. One of the spacewalks is slated to bring down two of the gyros, on the assumption that the other two can maintain attitude, while running off the new solar arrays which must rotate in order to generate the specified amount of power. Without the other gyro, RCS firings might be necessary, which make the solar cells unhappy.
This is a nontrivial but solvable problem. Solutions currently being proposed:
- Bring up the failing gyro for the duration of the spacewalk. It didn't up and die one day -- it's just vibrating a lot, and might do the trick.
- Leave the failing gyro off, and be prepared to bring it up only if the one operational gyro can't maintain attitude.
- Lock the solar array into a suboptimal orientation, and fire the RCS thrusters as necessary.
- Bring up a replacement gyro. They're about 800 pounds and aren't simple to install, which is a lot to be adding to a mission three weeks from launch, so this is unlikely.
They are rocket scientists, you know.Spanning tree protocol is your friend. It's not generally used to provide redundancy all the way to the host (as few operating systems support it), but it works great under Linux. Just make sure that priorities are set correctly -- you don't want a database server becoming the favorite path between switches.
Yep, Oracle RAC requires a quorum disk (CRS calls it a "voting disk"). However, if you use OCFS2 to store the data files (including the voting disk) the solution above cannot produce split-brain. Putting the data files in OCFS2 puts the responsibility of guarding the shared storage in the filesystem, which solves the problem as follows.
Each node in an OCFS2 cluster updates a special file every two second and maintains a TCP connection to its neighbors. If this process doesn't work (i.e. writes are failing, are backlogged, or for whatever reason don't hit the disks in a timely fashion), the node will fence itself. Likewise, if the node starts on fire, it will naturally stop updating the heartbeat data. Either way, other nodes are aware of who is up and who is down, even if the IP network dies. If a node's access to the storage system dies, OCFS2 won't be able to successfully read back its own heartbeat timestamp, and the node fences itself.
Note that this heartbeat procedure happens on the same block device that the data files are on. There's no way to reach the data files unless a node is in agreement with every other node, thus no way to cause "split-brain".
Say, somehow, a series of failures occur all simultaneously that results in Array 1 being connected only to nodes 1-4 and Array 2 being connected only to nodes 5-8. Each node keeps heartbeating, and after a little bit, Node 5 notices that Node 1 hasn't updated its timestamp, but that Node 1 just said that it did (over Ethernet). OCFS2 notices this immediately, much inter-node communication happens, and nodes 5-8 decide to fence themselves, leaving 1-4 as the only nodes allowed to touch either disk array. Still working as advertised.
Let's examine that failure. First, you'd have to terminate the links between both fibre channel switches. Then, you'd have to break uplink 2 on array 1 and uplink 1 on array 2. Then, you'd have to take out the second HBA on nodes 1-4 and the first HBA on nodes 5-8. Simultaneously. And the system handles this gracefully.
Now, what happens when the network goes out too, you ask? Remember that each node has one connection to both switches. Say we lose a switch -- all the nodes fail over to the other one. Hmm. Say we unplug nodes 1-4 from switch 2 and unplug nodes 5-8 from switch 1 -- both switches are connected together directly, and thanks to VLAN trunking, all the nodes can still reach each other. Darn. Say we also unplug that link. Well, both switches are plugged into the rest of the network, right? Assuming you also set up VLAN trunking there, the switches will be able to reach each other through a third switch. Hmm. What if we unplug those, too?
Congratulations! Split-brain! Nodes 1-4 proceed on Array 1 and Switch 1, and nodes 5-8 proceed on Array 2 and Switch 2. You only had to unplug 22 different cables -- eight Ethernet cables and eight FC cables from the nodes to the switches, two inter-switch links (one Ethernet and one FC), two disk array uplinks (one from each array to each switch), and two Ethernet uplinks (one from each Ethernet switch) to the rest of the network -- simultaneously.
As I said, no single point of failure.
"Shared storage" doesn't mean "not highly available". If you're serious about building a database that cannot go down, you get multiple servers, each with two Ethernet interfaces and two Fibre Channel cards. Get two Fibre Channel switches, and two Ethernet switches. Get two Fibre Channel disk arrays. Hook together as follows.
Both disk arrays have one or more uplinks to both FC switches. Each server has one HBA connected to each switch. Then, use Linux multipathing to provide automatic failover in case either switch dies or either HBA dies, and use Oracle ASM or Linux MD to mirror the data so you're good even if you unplug the shared storage.
Set up the servers to use 802.1q VLAN tagging. (Remember, it's a good idea to keep your inter-node communication separate from client-to-server communication.) Create two Ethernet bridges, using the Linux bridging driver, binding eth0.2/eth1.2 to one and eth0.3/eth1.3 to the other. Take the two switches, set up 802.1q on the ports going to your database servers, and connect them together (preferably using high-speed uplinks, but channel bonding works fine). Enable spanning tree on the switches and on the bridges. Connect both switches to the rest of your network.
Now, if a switch starts on fire, spanning tree on the servers will fail over to the other one automatically. If a network cable gets cut or a network card goes out on one node, that one node will fail over all traffic to the remaining interface, and the inter-switch trunk will make everything keep working. Suddenly, you've got a robust network.
So, we've got network and storage covered. What about the database software? Neither MySQL nor Postgres can use this sort of configuration, but Oracle RAC can. Add a dash of TAF, and suddenly, any component -- network switch, database server, SAN switch, disk array -- can fail in the middle of a SELECT and the application won't notice. That is highly available.
Yes, this solution costs more. Our data -- more accurately, the cost of it not being accessible -- justifies the expense. But don't tell me that shared storage is a weakness.
Given this, Sirius could somewhat easily blanket most of Europe with satellite radio feeds. However, if they aren't selling devices in those markets yet... regardless of where their birds are, they can always choose to turn off the transmitters.
Of course, none of that really matters, since the images are on a different server that neither Coral nor the original site are able to access.
I've got a mirror of the images building here. The server is dying quickly, but I should be able to complete the collection.
You're okay for about 2 hours and 34 minutes: that's how long it takes to traverse every possible alphanumeric input on the author's test rig. Additionally, the article suggests that tables including every possible LM hash for [A-Z0-9] would occupy only 1.2 TB of space, meaning that these lookups could be done in a matter of milliseconds instead.
I find it interesting that Windows is so widely deployed, yet so few people are truly "in love" with the operating system. You'll find people willing to die for Mac OSX, for OpenBSD, for BeOS, for Amiga, for Gentoo, or for any number of other systems -- but to date, I've never met a single person that was truly satisfied with Windows, much less happy or fanatical about it.
People use Microsoft for a number of reasons, none of them at all related to customer satisfaction. Corporate desktops are assumed to be running Windows with Office unless stated otherwise. Data centers are assumed to be running some Windows server edition, to let the admins use Group Policy and other platform-dependent tools that almost make managing those desktops bearable. People use Microsoft because of their monopoly, and Microsoft exploits this.
And remember, no one got fired for choosing Microsoft.
I managed to grab a mirror before the server was reduced to a smouldering pile of copper and silicon.
Enjoy.
Though, given what happened to the
The most recent build is from November 2001, and while users are able to connect to each other, it cannot be called a "game" by any stretch of the imagination.
Sorry to any Parsec developers (if they still exist) -- while I'd love a new king of the 3d-space shooter genre, Parsec isn't it... not now, and by the way the project looks, not ever.
Fascinating project, if I may say so myself.
Several months ago, Microsoft CHKDSK effectively destroyed one of my NTFS partitions -- it managed to screw up $MFT (which points to the location of the Master File Table) and the copy of $MFT within $MFTMirr (which is supposed to be used if $MFT is broken). Anyway, long story short, I spent a couple weeks staring at hex dumps and printouts of the Linux-NTFS project's NTFS documentation. After consuming inordinate amounts of caffeine, I came up with SalvageNTFS, an open-source NTFS data recovery tool that got back all the data I wanted. Assuming the physical media is intact (as in, all read requests to the disk are successful), SalvageNTFS can retrieve data if there is even a single record of the MFT intact.
If the first few sectors of the disk are overwritten, you'll lose the MBR, the partition table, and maybe the boot sector of your first partition. However, the filesystem of that partition is likely to be largely or completely intact. Think: in a few weeks with no prior knowledge of NTFS internals, I created a tool that can continue to operate in this environment. I'd hardly call that a "total mess".
There ya go.
The key difference here is that when something gets posted to Slashdot, people often have the ability to grab and post mirrors. Like this one, for instance.
(You're welcome.)
Even more fishy: ftp.dev.caldera.com (216.250.128.14) was not mentioned in the post, but is on the same subnet as www and ftp.sco.com. Guess what? It's quite responsive at refusing anonymous logins. Plus, ftp.beta.caldera.com (.15), ftp.iso.caldera.com (.16) work just fine:That's a 0.9-second FTP session. Guess what else? Despite
Something doesn't add up.
I've got a mirror being built from the site as it currently stands. That is, not just the main page, but the linked pages that give information.
:-)
Connections to the server are too slow for most web browsers, but wget handles it just fine.
However, the PayFlow account can be closed within a couple weeks, and new certificates can be issued from a different root pretty quickly. Those are the cash cows for Verisign, and the more significant and more likely of the four actions that I may take. Plus, in all of my future e-commerce dealings (like one that's on the table right now), I can inist on using a different merchant account provider, which is another loss for Verisign.
I'm going to call them some more tomorrow -- still no response from Verisign legal. I want someone to know that they will lose business as a result of SiteFinder.