You may be right, but I think the design is functional. There are lots of ways this kind of setup would be very convenient.
You could keep the document you are working on in the main screen, and your agenda or objectives on the small one. You could have a shared whiteboard in the main screen, and a webcam feed on the small screen. Or, if you were a PHB, you could keep the powerpoint slide you are working on in the main screen and the slide sorter on the side screen.
That said, I don't think this is the best way to do it. I'd prefer a separate LCD unit with its own stand.
Well, I'd agree in that the operating system choice doesn't give you any measure of security.
The sub is not closed, however. Not all the time. Before and after it is on patrol it is vulnerable.
WRT tot he man on the team... yes. However a fundamental aspect of security which we should all have learned from our accounting forbears is to arrange things under your control so that misdeeds require conspiracies, as large and elaborate as possible. One person should not be able to do something bad; he should need an accomplice.
Going from one to two people in a conspiracy is a vast jump in difficulty.
Indeed. My wife's cousins have an old farmstead that almost a mile long and maybe two hundred yards wide; all the farms are huddled along the river for access, stretch across the valley and up the mountain (for timber).
This is quite insightful. Division in half, or multiplication by two is almost always very easy. You can divide weights in half with a balance scale; you can measure twice a given weight using a balance scale using a simple procedure. Dividing a length in two is very simple. Dividing a volume in two is achieved by three halvings of length.
In fact, traditional English or Imperial units tend to follow base two ratios within sequences used for a purpose. The most common mass units go up by ratios of 16 (dram, ounce, pound) . Liquid measures, which are harder to do, go up in units of two (ounce, gill, cup, pint,quart, [skipped], gallon). Completely arbitrary ratios come up in situations where conversions to more common units are rare. If you are measuring a powder charge for a firearm, dry ounces are too imprecise. It doesn't matter that a 90 grain charge weighs 0.2057 ounces. Rounding to 0.2 ounces introduces an error of a full two and a half grains.
The US fluid ounce is less than 5% larger than an Imperial ounce. This means that a US gallon is equal to about 133 imperial ounces rather than 128 US ounces. An imperial gallon is 160 imperial ounces or 154 US ounces.
An imperial gallon is almost exactly 1.2 US gallons; since a US gallon weighs exactly eight US pounds, it follows that an imperial gallon weighs 9.6 US pounds, or 10 US pounds rounded to the nearest whole pound. The US and UK use the same pound since 1959; prior to that the avoirdupois and Imperial pounds varied by less than two parts in a million.
The reality you talk of is why metric is a better system -- for modern users.
The differences in body size aren't really that important, especially if you measure what you need and what you buy with the same hand. Merchants, of course, have to have precise, standardized rulers for pricing purposes. But for the purposes of reckoning the amount needed, precision was seldom important in a low tech economy. It's not like you are purchasing a standardized screw that has to mate with a standard thread pitch.
When you buy a pound of modern 10 penny nails, you get 41 precisely. Back in the days when these were hand forged by a blacksmith, you might get 39 or 43. It wouldn't have mattered. You might bend or break more of the lighter nails, either way you'd get roughly the same amount of fastening done. By the way they're called 10 penny nails because in the 1620s, when the sizes were standardized, you paid 10p for a 100 nails. This, by the way, meant that pound sterling bought 58 and half pounds of nails.
(1) My point is people are in position. (2) Having source code doesn't mean anything unless you build from it.
It's not that I think there is a problem. I'm just pointing out that if it were my job to be paranoid, then I would build from source code -- ideally audited source code. If you wanted to put a back door into source code, you wouldn't put a hundred lines of comment describing the back door and how to use it. Ideally, you'd need to add up several pieces of code in different places to figure that out.
The point of the system being... unsystematic, is that you define units appropriate to a task. If you do this, many ratios in your system will be conveniently defined, but some ratios in your system that are completely arbitrary.
By contrast, under the metric system all the ratios are chosen in order to make decimal calculations as simple as they might be. Aside from that all the ratios are from a practical purpose arbitrary: they're all various powers of ten.
The ratio 10 ensures that units are really a bit more far apart than is practical.
A good compromise would be to use a base four or eight system. This would be quite useful in that division into two is usually a very easy operation: either bisection of a line or division into two equal weights. D
By the way, ever wonder why a dozen is twelve and not ten? Well, 12 has the interesting and convenient property that it is evenly divisible into 2,3 or 4 parts. This makes a dozen of anything readily dividable between two, three or four parties. An interesting mathematical question is this: what other numbers have this property? For example, 12 is divisible by 1,2,3 and 4, but not 5. What numbers are divisible by all integers [1,5] or [1,7]?
In any case, a mile is exactly eight furlongs, and eight being a power of two is very useful indeed. A furlong, if you are an agriculturalist, can be conveniently measured as forty rods, or if you are surveyor as ten chains. Thus either way, a furlong is readily measurable, and is easily extendable to a mile; a mile is readily divided into easily measurable subunits. The yard is not meant to particularly figure into this, but if you must a rod is 5.5 yards. Five rods are measured, as is a half rod which is a simple bisection. Thus you can construct a rod without difficulty from a yard. It is easier, however, to construct a surveyor's chain, which is 22 yards, and from that a furlong, which is 220 yards.
So to fit yard into this, it's not the ratio of the mile to yard that matters, but to a useful intermediate measure: the furlong. The furlong is not only 220 yards, it is 1/(2^8) miles or about 1 sqrt(acre). Of course, metric does this too, and more precisely in terms of area conversions; note even metric is somewhat arbitrary though. The basic unit of area isn't a m^2 it is an hecatre, or 10,000 m^2. Why 10,000? It's a convenient area for many round measurements that happens to be a power of 10.
you my good sir obviously have not taken a class in statistics, as clearly, measuring 24 times would make for a huge margin of error. Better to grab a 2m "yardstick" and measure twice, and cut at a total of 2.5146 m
The statistical error could in principle add up. In practice it doesn't very much. The expected error (counting over and under) over a large number of trials is zero, since we're talking a random walk in one dimension. The expected value of the square of the error is proportional to the number of trials, therefore the expected distance from the true measurement is proportional to the square root of the number of measurements you make.
It therefore follows that the error you make after twenty four measurements is less than five times the error you make after making one measurement. Since this is likely to amount to less than an inch, a simple expedient of buying 25 hands of rope rather than 24 hands, three thumbs will ensure adequate rope is purchased at the cost of around 1 inch of rope.
It's true I've never taken a course in statistics, unless you count MIT's Stochastic Processes course with the late, great G.C. Rota.
By the way, I'd love to see a picture of your yardstick. I've never seen one calibrated in hundredths of a cm.
Depends on what you mean by "runs the whole ship". The application in question probably was related to engine control, since a technician working on a fuel valve entering the offending zero. That makes a loss of engine power easy to explain: the system that controlled the engines was offline.
None of the public descriptions of the Yorktown incident are entirely satisfactory. For example, it is often said that the faulty data caused the LAN to down. Why would that be? And why would that stop the engines?
Reading between the lines, I bet it worked something like this. I'll bet that design of the engine control system used multiple servers connected over a LAN to ensure that engine power was not lost in the case of any single computer being lost in battle. However, the servers must share data in order to make sure any one of them can take over the engines if the others are out. This makes the shared data itself a single point of failure.
Personally, I think it is unconscionable that the ship was not navigable under manual control. It may be that in such circumstances, the ship could not perform its combat functions, but it still should be able to move out of danger if at all physically possible.
With respect to whether Microsoft has any role in the incident, that is impossible to say. Why did it take so long to bring the system back online? Well, one of the aspects of SQL Server is that it lacks workable log utilities. It is impractical without such utilities to quickly bring a complex database back up to some arbitrary point in time, or to undo the consequences of a single problematic transaction unless you know exactly what the state of the system was before that point. For that reason, while that product has its good points, it's not really something I'd use where recovering data after some kind of problem is an important requirement.
They would be accessed by an operative prior to installation on board or during servicing in port. The most practical initial objective would be to gather information about submarine operations and the use of IT on the subs.
A league is about the distance a healthy man can walk on a good road in one hour. A fathom is about the height of a tall man; it is about eighteen hand widths (fingers closed). A US gallon is the volume of eight pounds of water. An imperial gallon (i.e. the UK gallon) is the volume of ten pounds of water.
One interesting thing about weights. The system of dram/ounce/pound is base 16, which makes division by two a practical measuring operation. Take a pound of something readily dividable, divide it into two equal portions (using a balance scale). Then repeat the process four times. The result is one ounce.
This shows the offsetting virtues of traditional units. While they are difficult to calculate with, they are convenient for measuring things -- especially when it come to quantifying things for sale.
For example, consider length: 1 inch = approximately the width of a thumb 1 hand = 4 inches = width of a hand with fingers closed 1 ft = 3 hands 1 yard = 3 ft 1 fathom = 2 yards 1 rod = 5.5 yards = length of ox goad 1 chain = 22 yards = 100 links in standard survey chain 1 furlong = 10 chains = distance ox team can plow without rest 1 mile = 880 fathoms
Notice that if you lay out a square field such that an ox team can plow one furrow across then rest, you get a square with sides of exactly one furlong or 660 ft. The area of that field 43,600 square feet, which is nearly exactly one acre (43,560 ft).
For purposes of round measurement (no fractions), such as you would use in commerce, traditional measurement is far more convenient. If I'm buying liquor, the following units exhaust all the practical measures to which I might wish to round a purchase:
In such a system of measurement, you never, ever have to deal with fractions. Breaking down into smaller units is simply a matter of dividing a whole into two equal parts. So if you want to buy things without having to specify fractions, traditional units are the bee's knees (equal to 1 / 128 of an inch... no just kidding). That's not so important in a world with calculators -- you just calculate a unit price.
Still, if you want to buy eight feet, three inches of rope, you can measure out twenty-four hands and three thumbs and come rather close.
There are much better ways to spend your money if you want the thrill of flight. There are probably better ways of spending your money if you want the thrill of space flight. I'm presuming its the thrill of operating a piece of history that is the relevant question here. That's a lot more subjective.
Sure. But dealing learning to deal with structures which enforce scope before you need them is easier than learning to deal with them after you need them.
On top of that, your example conflates the interpretive/compiled environment distinction with the language. The whole point of the original "hello world" program is to introduce you to the things you'll need to build a compilable program. That includes invoking the compiler and linker, and giving the compiler the information it needs through header inclusion.
In an interpreted environment, you don't have those concerns. For example, "hello, world" in groovy is: println "hello, world!"
In truth, for useful programs the equivalent BASIC program is going to be as or more complex than the Java program. If you were to write the equivalent of, say, the Apache Derby database in BASIC, it would be much more complex.
For example, lots of people have a checking account, savings account, credit card, poersonal line of credit, HELOC, brokerage account, and more. I see absolutely no reason why a single account could not offer all those features.
Neither did advocates of banking deregulation in the 1990s.
One of the reasons for this "redundancy" is (or used to be) that different rules apply to each kind of account. You used to have have commercial banks, investment banks, and insurance companies, and each did something different under different rules. Then the rules that had been in place since the Great Depression were repealed by Gramm-Leach-Bliley, and suddenly the legal boundaries between these kinds of financial services was gone.
Subsequently, we are facing the greatest economic crisis since the Great Depression. Coincidence? I'm not entirely sure, but surely some of the problem is that practices and attitudes that were normal in investment banking suddenly started to crop up in other businesses.
Although Hank Paulson is actually, in my opinion, one of the more decent individuals as a person in the administration, he's very much the wrong man at the wrong time. One of the things he did as head of Goldman Sachs was to convince the SEC to get rid of the "net capital rule". That was the rule that required banks to maintain a certain level of cash on hand to cover cash demands in unusual situations. This is obviously extremely expensive for companies who had to keep huge volumes of cash on hand, losing mind boggling amounts of value even against modest inflation.
Had the rule been kept in place, we might not have had to pony up seven hundred billion dollars to bail out Wall Street.
You didn't have a very good social studies curriculum then, or at least not enough to cover things like the history of electrification, or the subsidization of universal telephone service through government granted monopolies.
The advantage of possessing a monopoly is the ability to gain higher than normal profits, or (equivalently) lower profits at reduced risk. When such a monopoly is gained through private action, it is almost always a problem for the public, which is why we have regulatory restrictions on anti-competitive practices. On the other hand, the public sometimes creates or grants regulated monopolies as part of a quid pro quo.
I actually think that technology history is a very interesting topic.
For example, in 1684 Robert Hooke presented a scheme to the Royal Society for setting up lines of towers to relay semaphore signals over long distances. This was an eminently practical suggestion. In fact the Royal Navy in the following century developed the capability of coordinating complex land and sea operations using semaphore. Still it wasn't until over a hundred years later that an attempt was made to make a practical land based network. By that time, the first practical demonstrations of electrical telegraphy had already taken place. Electrical telegraphy was both cheaper and nearly 8x as fast. Once electrical telegraphy was possible, semaphore was doomed.
What's interesting about semaphore is that it is intrinsically low tech. It's most efficient with some kind of mechanical shutter system, but you can make do with a pair of flags. The Romans certainly had the engineering ability to connect their empire with a series of semaphore towers; the only thing wanting was the idea. You can imagine how history would have been different if it had occurred to them. At the very least, the slow and easily intercepted nature of semaphore might have lead to many computer science and cryptography ideas being discovered thousand of years earlier.
A pneumatic tube system, on the other hand, is only possible for a civilization that has at least stem engine technology. Such systems were unlikely to scale beyond local service in any case. It's an interesting concept, but not nearly as potentially revolutionary as semaphore might have been.
Actually, I'd say it's too early to say that the Semantic Web has failed. What has clearly failed for now is the vision for how the technology was to be used.
For one thing, it turned out that really, really clever textual matching is a lot more powerful than anybody thought possible. Twenty years or so ago, you'd have thought that you'd need to have some kind of sophisticated metadata to do the kinds of stuff we take for granted in Google today. I turns out that a technology that turns a needle in a haystack into a box of needles with some straw mixed in is pretty darned useful. Human intelligence picks the needle of meaning from the straw of superficial matches pretty effectively.
But what about non-human intelligence?
Well, here is another failure of the vision. Clearly, a semantic web is much more friendly to non-human agents. However, the whole agent philosophy of software design is extremely failure prone. A project which makes a resource easier to use for people is a safer bet than one which tries to replace human reason.
That said, you have the wrong end of the stick, philosophically. It is because meaning is not an attribute of data that we need semantic technology, It might be less contentious and pretentious if we simply call it "metadata".
If I want to find the rate of a certain disease in each county, the numerator is quite easy: I count all the instances of the disease. But the denominator turns out to be tricky, because of what I call the curious case of the dog barking in the night: some counties don't report any cases because they don't have any, others lack the technical capability to detect it.
Consider a county that can't detect the disease. I ought to exclude that county from the denominator in my rate calculations. On the other hand, a county which can detect ought to be included in the denominator, even if it reports no cases. However, since it found no cases, what we usually have is an absence of data which looks identical to the absence in counties that aren't capable.
You have to have the metadata to tell these cases apart. You have to have a model saying such and such a lab protocol is capable of detecting such and so set of infectious agents, and then you need metadata linking each data set to the appropriate model. You can do it by hand, manually discarding the data for counties you know you can't use, but this is really quite awkward when you cosider that the situation can change from year to year, or even within a year.
The model aspect presents a considerable can of worms. For any purpose, you want enough model, but no more than that. This is akin to the situation of novice designers who set out to create object frameworks before the have defined the software application. For us to share data we have to have some common model of things (although our terminology may differ). On the other hand it is certain our models disagree with each other; we want enough shared model to work together without forcing our entire model on each other, which is impractical.
The point is that you can't guess all the kinds of uses that future users as yet unknown might want to put data to, what kind of meaning they might extract from it. That's why search engine technology works so well: you put your stuff on the web and it gets spidered by Google: no guesswork needed. The Semantic Web, on the other hand, requires anticipating how the data will be used, which limits its usefulness. The "limits" here are, however ones of scope; the Semantic Web can't do everything, it certainly can't take the place of Google. Within the scope of its potential applications, it could be very useful indeed.
The essential point here is this: the election going against the winner of the popular vote is not a failure of the electoral college, because that is what the electoral college is designed to make possible. If that were not the case, then there would be no reason to use any system but the popular vote.
This makes the vote proper. However, "proper" is by no means the same thing as "just". One can hold that awarding the election to the winner of the popular vote is more just than counting electoral votes, so that where the results diverge, the college results are unjust. However, that's far from the only injustice in the system. Plurality voting has its own built in injustices to third party candidates.
The best thing about the electoral college is that it simplifies the concept of legitmacy. The scenario Atilla above spun out is a gross simplification of the 200 Florida situation. In fact the recount proposals on both sides, it turned out, would have backfired. Given the closeness of the race, the policies and laws under which it took place, and the number of questionable ballots, the recount could have gone on forever. The Supreme Court's ruling, although rather weak from a legal standpoint, reduced the question of legitimacy to a single question: where the electors from Florida were legitimate. You don't have to examine thousands of ballots and decide if they were proper or spoiled.
"Just" is a tricky term, but I think that all just results must in some way be rational. By any reasonable standard, the race in Florida was a statistical tie, and the arguments were all self-interested attempts to color the kind of statistical noise that got included in the result. Therefore, throwing the entire state's vote one way or the other is not rationally defensible, at least if we assume that reflecting the intent of the electorate is necessary for the result to be reasonable.
Personally, I think the best course in such cases of statistical ties would be to split the electoral vote; candidates winning a clear majority could still take all. This doesn't reduce the chance of a controversy, since it simply moves the dividing line from, say, a 0% margin to a 5% margin. However, since the number of electoral votes in question would be half, a controversy is less likely to swing the entire election (although it would have in 2000).
The structure of a government body or an electoral process is a technology. These are artifacts that are designed to meet certain requirements. There are rich fields of mathematics describing what it and is not possible, and various designs (such as proportional representation or approval voting) which represent different tradeoffs between incompatible ends.
The electoral college is a case in point. The original idea was to moderate public passions by filtering them through elected representatives from each state. However once you do that, you are presented with a problem: under such a system, residents of less populous states would, in effect, have no say in an election that was entirely determined by a few large states. So they tweaked the weight of each state's vote to provide what, at the time, amounted to an equalization of power between residents of different states (as well as ensuring that no drastic measures were taken at the Federal level which would damage economies dependent on slave importation).
Of course, this leads to the "old lady who swallowed the fly" scenario: while ensuring equalization of influence between states of different sizes, it creates severe imbalances of influence between safe states and battleground states.
And that's a hallmark of an engineering problem: you can't have everything because fixes in one place create problems in other places.
Slashdot Mirror
You may be right, but I think the design is functional. There are lots of ways this kind of setup would be very convenient.
You could keep the document you are working on in the main screen, and your agenda or objectives on the small one. You could have a shared whiteboard in the main screen, and a webcam feed on the small screen. Or, if you were a PHB, you could keep the powerpoint slide you are working on in the main screen and the slide sorter on the side screen.
That said, I don't think this is the best way to do it. I'd prefer a separate LCD unit with its own stand.
Well, I'd agree in that the operating system choice doesn't give you any measure of security.
The sub is not closed, however. Not all the time. Before and after it is on patrol it is vulnerable.
WRT tot he man on the team ... yes. However a fundamental aspect of security which we should all have learned from our accounting forbears is to arrange things under your control so that misdeeds require conspiracies, as large and elaborate as possible. One person should not be able to do something bad; he should need an accomplice.
Going from one to two people in a conspiracy is a vast jump in difficulty.
Indeed. My wife's cousins have an old farmstead that almost a mile long and maybe two hundred yards wide; all the farms are huddled along the river for access, stretch across the valley and up the mountain (for timber).
However the point is the ratios work out.
This is quite insightful. Division in half, or multiplication by two is almost always very easy. You can divide weights in half with a balance scale; you can measure twice a given weight using a balance scale using a simple procedure. Dividing a length in two is very simple. Dividing a volume in two is achieved by three halvings of length.
In fact, traditional English or Imperial units tend to follow base two ratios within sequences used for a purpose. The most common mass units go up by ratios of 16 (dram, ounce, pound) . Liquid measures, which are harder to do, go up in units of two (ounce, gill, cup, pint,quart, [skipped], gallon). Completely arbitrary ratios come up in situations where conversions to more common units are rare. If you are measuring a powder charge for a firearm, dry ounces are too imprecise. It doesn't matter that a 90 grain charge weighs 0.2057 ounces. Rounding to 0.2 ounces introduces an error of a full two and a half grains.
The US fluid ounce is less than 5% larger than an Imperial ounce. This means that a US gallon is equal to about 133 imperial ounces rather than 128 US ounces. An imperial gallon is 160 imperial ounces or 154 US ounces.
An imperial gallon is almost exactly 1.2 US gallons; since a US gallon weighs exactly eight US pounds, it follows that an imperial gallon weighs 9.6 US pounds, or 10 US pounds rounded to the nearest whole pound. The US and UK use the same pound since 1959; prior to that the avoirdupois and Imperial pounds varied by less than two parts in a million.
The reality you talk of is why metric is a better system -- for modern users.
The differences in body size aren't really that important, especially if you measure what you need and what you buy with the same hand. Merchants, of course, have to have precise, standardized rulers for pricing purposes. But for the purposes of reckoning the amount needed, precision was seldom important in a low tech economy. It's not like you are purchasing a standardized screw that has to mate with a standard thread pitch.
When you buy a pound of modern 10 penny nails, you get 41 precisely. Back in the days when these were hand forged by a blacksmith, you might get 39 or 43. It wouldn't have mattered. You might bend or break more of the lighter nails, either way you'd get roughly the same amount of fastening done. By the way they're called 10 penny nails because in the 1620s, when the sizes were standardized, you paid 10p for a 100 nails. This, by the way, meant that pound sterling bought 58 and half pounds of nails.
(1) My point is people are in position.
(2) Having source code doesn't mean anything unless you build from it.
It's not that I think there is a problem. I'm just pointing out that if it were my job to be paranoid, then I would build from source code -- ideally audited source code. If you wanted to put a back door into source code, you wouldn't put a hundred lines of comment describing the back door and how to use it. Ideally, you'd need to add up several pieces of code in different places to figure that out.
It doesn't have to be.
The point of the system being ... unsystematic, is that you define units appropriate to a task. If you do this, many ratios in your system will be conveniently defined, but some ratios in your system that are completely arbitrary.
By contrast, under the metric system all the ratios are chosen in order to make decimal calculations as simple as they might be. Aside from that all the ratios are from a practical purpose arbitrary: they're all various powers of ten.
The ratio 10 ensures that units are really a bit more far apart than is practical.
A good compromise would be to use a base four or eight system. This would be quite useful in that division into two is usually a very easy operation: either bisection of a line or division into two equal weights. D
By the way, ever wonder why a dozen is twelve and not ten? Well, 12 has the interesting and convenient property that it is evenly divisible into 2,3 or 4 parts. This makes a dozen of anything readily dividable between two, three or four parties. An interesting mathematical question is this: what other numbers have this property? For example, 12 is divisible by 1,2,3 and 4, but not 5. What numbers are divisible by all integers [1,5] or [1,7]?
In any case, a mile is exactly eight furlongs, and eight being a power of two is very useful indeed. A furlong, if you are an agriculturalist, can be conveniently measured as forty rods, or if you are surveyor as ten chains. Thus either way, a furlong is readily measurable, and is easily extendable to a mile; a mile is readily divided into easily measurable subunits. The yard is not meant to particularly figure into this, but if you must a rod is 5.5 yards. Five rods are measured, as is a half rod which is a simple bisection. Thus you can construct a rod without difficulty from a yard. It is easier, however, to construct a surveyor's chain, which is 22 yards, and from that a furlong, which is 220 yards.
So to fit yard into this, it's not the ratio of the mile to yard that matters, but to a useful intermediate measure: the furlong. The furlong is not only 220 yards, it is 1/(2^8) miles or about 1 sqrt(acre). Of course, metric does this too, and more precisely in terms of area conversions; note even metric is somewhat arbitrary though. The basic unit of area isn't a m^2 it is an hecatre, or 10,000 m^2. Why 10,000? It's a convenient area for many round measurements that happens to be a power of 10.
But we aren't talking about hacking. We're talking about back doors.
you my good sir obviously have not taken a class in statistics, as clearly, measuring 24 times would make for a huge margin of error. Better to grab a 2m "yardstick" and measure twice, and cut at a total of 2.5146 m
The statistical error could in principle add up. In practice it doesn't very much. The expected error (counting over and under) over a large number of trials is zero, since we're talking a random walk in one dimension. The expected value of the square of the error is proportional to the number of trials, therefore the expected distance from the true measurement is proportional to the square root of the number of measurements you make.
It therefore follows that the error you make after twenty four measurements is less than five times the error you make after making one measurement. Since this is likely to amount to less than an inch, a simple expedient of buying 25 hands of rope rather than 24 hands, three thumbs will ensure adequate rope is purchased at the cost of around 1 inch of rope.
It's true I've never taken a course in statistics, unless you count MIT's Stochastic Processes course with the late, great G.C. Rota.
By the way, I'd love to see a picture of your yardstick. I've never seen one calibrated in hundredths of a cm.
Depends on what you mean by "runs the whole ship". The application in question probably was related to engine control, since a technician working on a fuel valve entering the offending zero. That makes a loss of engine power easy to explain: the system that controlled the engines was offline.
None of the public descriptions of the Yorktown incident are entirely satisfactory. For example, it is often said that the faulty data caused the LAN to down. Why would that be? And why would that stop the engines?
Reading between the lines, I bet it worked something like this. I'll bet that design of the engine control system used multiple servers connected over a LAN to ensure that engine power was not lost in the case of any single computer being lost in battle. However, the servers must share data in order to make sure any one of them can take over the engines if the others are out. This makes the shared data itself a single point of failure.
Personally, I think it is unconscionable that the ship was not navigable under manual control. It may be that in such circumstances, the ship could not perform its combat functions, but it still should be able to move out of danger if at all physically possible.
With respect to whether Microsoft has any role in the incident, that is impossible to say. Why did it take so long to bring the system back online? Well, one of the aspects of SQL Server is that it lacks workable log utilities. It is impractical without such utilities to quickly bring a complex database back up to some arbitrary point in time, or to undo the consequences of a single problematic transaction unless you know exactly what the state of the system was before that point. For that reason, while that product has its good points, it's not really something I'd use where recovering data after some kind of problem is an important requirement.
They would be accessed by an operative prior to installation on board or during servicing in port. The most practical initial objective would be to gather information about submarine operations and the use of IT on the subs.
A league is about the distance a healthy man can walk on a good road in one hour. A fathom is about the height of a tall man; it is about eighteen hand widths (fingers closed). A US gallon is the volume of eight pounds of water. An imperial gallon (i.e. the UK gallon) is the volume of ten pounds of water.
One interesting thing about weights. The system of dram/ounce/pound is base 16, which makes division by two a practical measuring operation. Take a pound of something readily dividable, divide it into two equal portions (using a balance scale). Then repeat the process four times. The result is one ounce.
This shows the offsetting virtues of traditional units. While they are difficult to calculate with, they are convenient for measuring things -- especially when it come to quantifying things for sale.
For example, consider length:
1 inch = approximately the width of a thumb
1 hand = 4 inches = width of a hand with fingers closed
1 ft = 3 hands
1 yard = 3 ft
1 fathom = 2 yards
1 rod = 5.5 yards = length of ox goad
1 chain = 22 yards = 100 links in standard survey chain
1 furlong = 10 chains = distance ox team can plow without rest
1 mile = 880 fathoms
Notice that if you lay out a square field such that an ox team can plow one furrow across then rest, you get a square with sides of exactly one furlong or 660 ft. The area of that field 43,600 square feet, which is nearly exactly one acre (43,560 ft).
For purposes of round measurement (no fractions), such as you would use in commerce, traditional measurement is far more convenient. If I'm buying liquor, the following units exhaust all the practical measures to which I might wish to round a purchase:
1 mouthful
1 jigger (aka 1 fluid ounce) = 2 mouthfuls
1 jack = 2 jiggers
1 gill = 2 jacks = 4 jiggers
1 cup = 2 gills = 8 jiggers = 16 mouthfuls
1 pint = 2 cups
1 quart = 2 pints = 4 cups
1 gallon = 4 quarts = 8 pints = 16 cups
1 cask = 16 gallons
1 barrel = 2 casks
1 hogshead = 2 barrels
1 butt = 2 hogsheads = 4 barrels
1 tun = 2 butts = 4 hogsheads = 8 barrels
In such a system of measurement, you never, ever have to deal with fractions. Breaking down into smaller units is simply a matter of dividing a whole into two equal parts. So if you want to buy things without having to specify fractions, traditional units are the bee's knees (equal to 1 / 128 of an inch ... no just kidding). That's not so important in a world with calculators -- you just calculate a unit price.
Still, if you want to buy eight feet, three inches of rope, you can measure out twenty-four hands and three thumbs and come rather close.
Indeed I do.
There are much better ways to spend your money if you want the thrill of flight. There are probably better ways of spending your money if you want the thrill of space flight. I'm presuming its the thrill of operating a piece of history that is the relevant question here. That's a lot more subjective.
That's the expense to put it in orbit. It wouldn't cost as much to just to fly the thing.
Sure. But dealing learning to deal with structures which enforce scope before you need them is easier than learning to deal with them after you need them.
On top of that, your example conflates the interpretive/compiled environment distinction with the language. The whole point of the original "hello world" program is to introduce you to the things you'll need to build a compilable program. That includes invoking the compiler and linker, and giving the compiler the information it needs through header inclusion.
In an interpreted environment, you don't have those concerns. For example, "hello, world" in groovy is:
println "hello, world!"
In truth, for useful programs the equivalent BASIC program is going to be as or more complex than the Java program. If you were to write the equivalent of, say, the Apache Derby database in BASIC, it would be much more complex.
Mmmm. Crabs.
For example, lots of people have a checking account, savings account, credit card, poersonal line of credit, HELOC, brokerage account, and more. I see absolutely no reason why a single account could not offer all those features.
Neither did advocates of banking deregulation in the 1990s.
One of the reasons for this "redundancy" is (or used to be) that different rules apply to each kind of account. You used to have have commercial banks, investment banks, and insurance companies, and each did something different under different rules. Then the rules that had been in place since the Great Depression were repealed by Gramm-Leach-Bliley, and suddenly the legal boundaries between these kinds of financial services was gone.
Subsequently, we are facing the greatest economic crisis since the Great Depression. Coincidence? I'm not entirely sure, but surely some of the problem is that practices and attitudes that were normal in investment banking suddenly started to crop up in other businesses.
Although Hank Paulson is actually, in my opinion, one of the more decent individuals as a person in the administration, he's very much the wrong man at the wrong time. One of the things he did as head of Goldman Sachs was to convince the SEC to get rid of the "net capital rule". That was the rule that required banks to maintain a certain level of cash on hand to cover cash demands in unusual situations. This is obviously extremely expensive for companies who had to keep huge volumes of cash on hand, losing mind boggling amounts of value even against modest inflation.
Had the rule been kept in place, we might not have had to pony up seven hundred billion dollars to bail out Wall Street.
You didn't have a very good social studies curriculum then, or at least not enough to cover things like the history of electrification, or the subsidization of universal telephone service through government granted monopolies.
The advantage of possessing a monopoly is the ability to gain higher than normal profits, or (equivalently) lower profits at reduced risk. When such a monopoly is gained through private action, it is almost always a problem for the public, which is why we have regulatory restrictions on anti-competitive practices. On the other hand, the public sometimes creates or grants regulated monopolies as part of a quid pro quo.
I actually think that technology history is a very interesting topic.
For example, in 1684 Robert Hooke presented a scheme to the Royal Society for setting up lines of towers to relay semaphore signals over long distances. This was an eminently practical suggestion. In fact the Royal Navy in the following century developed the capability of coordinating complex land and sea operations using semaphore. Still it wasn't until over a hundred years later that an attempt was made to make a practical land based network. By that time, the first practical demonstrations of electrical telegraphy had already taken place. Electrical telegraphy was both cheaper and nearly 8x as fast. Once electrical telegraphy was possible, semaphore was doomed.
What's interesting about semaphore is that it is intrinsically low tech. It's most efficient with some kind of mechanical shutter system, but you can make do with a pair of flags. The Romans certainly had the engineering ability to connect their empire with a series of semaphore towers; the only thing wanting was the idea. You can imagine how history would have been different if it had occurred to them. At the very least, the slow and easily intercepted nature of semaphore might have lead to many computer science and cryptography ideas being discovered thousand of years earlier.
A pneumatic tube system, on the other hand, is only possible for a civilization that has at least stem engine technology. Such systems were unlikely to scale beyond local service in any case. It's an interesting concept, but not nearly as potentially revolutionary as semaphore might have been.
Actually, I'd say it's too early to say that the Semantic Web has failed. What has clearly failed for now is the vision for how the technology was to be used.
For one thing, it turned out that really, really clever textual matching is a lot more powerful than anybody thought possible. Twenty years or so ago, you'd have thought that you'd need to have some kind of sophisticated metadata to do the kinds of stuff we take for granted in Google today. I turns out that a technology that turns a needle in a haystack into a box of needles with some straw mixed in is pretty darned useful. Human intelligence picks the needle of meaning from the straw of superficial matches pretty effectively.
But what about non-human intelligence?
Well, here is another failure of the vision. Clearly, a semantic web is much more friendly to non-human agents. However, the whole agent philosophy of software design is extremely failure prone. A project which makes a resource easier to use for people is a safer bet than one which tries to replace human reason.
That said, you have the wrong end of the stick, philosophically. It is because meaning is not an attribute of data that we need semantic technology, It might be less contentious and pretentious if we simply call it "metadata".
If I want to find the rate of a certain disease in each county, the numerator is quite easy: I count all the instances of the disease. But the denominator turns out to be tricky, because of what I call the curious case of the dog barking in the night: some counties don't report any cases because they don't have any, others lack the technical capability to detect it.
Consider a county that can't detect the disease. I ought to exclude that county from the denominator in my rate calculations. On the other hand, a county which can detect ought to be included in the denominator, even if it reports no cases. However, since it found no cases, what we usually have is an absence of data which looks identical to the absence in counties that aren't capable.
You have to have the metadata to tell these cases apart. You have to have a model saying such and such a lab protocol is capable of detecting such and so set of infectious agents, and then you need metadata linking each data set to the appropriate model. You can do it by hand, manually discarding the data for counties you know you can't use, but this is really quite awkward when you cosider that the situation can change from year to year, or even within a year.
The model aspect presents a considerable can of worms. For any purpose, you want enough model, but no more than that. This is akin to the situation of novice designers who set out to create object frameworks before the have defined the software application. For us to share data we have to have some common model of things (although our terminology may differ). On the other hand it is certain our models disagree with each other; we want enough shared model to work together without forcing our entire model on each other, which is impractical.
The point is that you can't guess all the kinds of uses that future users as yet unknown might want to put data to, what kind of meaning they might extract from it. That's why search engine technology works so well: you put your stuff on the web and it gets spidered by Google: no guesswork needed. The Semantic Web, on the other hand, requires anticipating how the data will be used, which limits its usefulness. The "limits" here are, however ones of scope; the Semantic Web can't do everything, it certainly can't take the place of Google. Within the scope of its potential applications, it could be very useful indeed.
You're quibbling.
The essential point here is this: the election going against the winner of the popular vote is not a failure of the electoral college, because that is what the electoral college is designed to make possible. If that were not the case, then there would be no reason to use any system but the popular vote.
This makes the vote proper. However, "proper" is by no means the same thing as "just". One can hold that awarding the election to the winner of the popular vote is more just than counting electoral votes, so that where the results diverge, the college results are unjust. However, that's far from the only injustice in the system. Plurality voting has its own built in injustices to third party candidates.
The best thing about the electoral college is that it simplifies the concept of legitmacy. The scenario Atilla above spun out is a gross simplification of the 200 Florida situation. In fact the recount proposals on both sides, it turned out, would have backfired. Given the closeness of the race, the policies and laws under which it took place, and the number of questionable ballots, the recount could have gone on forever. The Supreme Court's ruling, although rather weak from a legal standpoint, reduced the question of legitimacy to a single question: where the electors from Florida were legitimate. You don't have to examine thousands of ballots and decide if they were proper or spoiled.
"Just" is a tricky term, but I think that all just results must in some way be rational. By any reasonable standard, the race in Florida was a statistical tie, and the arguments were all self-interested attempts to color the kind of statistical noise that got included in the result. Therefore, throwing the entire state's vote one way or the other is not rationally defensible, at least if we assume that reflecting the intent of the electorate is necessary for the result to be reasonable.
Personally, I think the best course in such cases of statistical ties would be to split the electoral vote; candidates winning a clear majority could still take all. This doesn't reduce the chance of a controversy, since it simply moves the dividing line from, say, a 0% margin to a 5% margin. However, since the number of electoral votes in question would be half, a controversy is less likely to swing the entire election (although it would have in 2000).
I'd put Gates at the top of the ticket, not because he'd do better than Jobs, but because it'd be so much more interesting that way.
Speaking of Palin, the electoral college actually casts two votes: one for the office of the Presidency, the other for the Vice-Presidency.
It is therefore possible for faithless electors to mix and match parties. The could elect an Obama/Palin administration, or a McCain/Biden one.
The structure of a government body or an electoral process is a technology. These are artifacts that are designed to meet certain requirements. There are rich fields of mathematics describing what it and is not possible, and various designs (such as proportional representation or approval voting) which represent different tradeoffs between incompatible ends.
The electoral college is a case in point. The original idea was to moderate public passions by filtering them through elected representatives from each state. However once you do that, you are presented with a problem: under such a system, residents of less populous states would, in effect, have no say in an election that was entirely determined by a few large states. So they tweaked the weight of each state's vote to provide what, at the time, amounted to an equalization of power between residents of different states (as well as ensuring that no drastic measures were taken at the Federal level which would damage economies dependent on slave importation).
Of course, this leads to the "old lady who swallowed the fly" scenario: while ensuring equalization of influence between states of different sizes, it creates severe imbalances of influence between safe states and battleground states.
And that's a hallmark of an engineering problem: you can't have everything because fixes in one place create problems in other places.