He might not be in a hurry, but I'd be surprised if he doesn't realize how this could help Linux.
I'd suggest the reason he is not in a hurry is that he does realize how this could help Linux, and also how it could hurt Linux.
Adding real-time capability is not a free lunch.
As the original C|NET article suggests, there is a class of applications that need real-time capability (which, BTW, is mostly about being able to say that interrupt X will be handled in not more than N time units).
But for most applications, real-time capability is neither needed nor really desirable: having it comes at a cost in average processing efficiency.
Incidentally, telecoms is mentioned as a possible application. I don't know enough about cellular telephony to say if it fits, and maybe there are some VoIP applications where it would make sense. But for conventional circuit-switched telecoms (e.g., a telephone switch), it really is not needed.
Interesting. I recall having decidedly mixed feelings about it: I wasn't crazy about having to deal even more with the telephone company, since I wasn't really in the market for more aggravation.:-)
I guess eventually corporate telecom goes away as a kind of island in the MIS dept? Maybe that's already happened?
Organizationally, it started happening quite a while ago, at least in some industries. I worked as an IT director in a "Wall Street" firm for several years, and ended up with responsibility for telecoms, too. That wasn't because I sought it, or even wanted it -- I had to get up to speed on a whole bunch of new (to me) stuff -- but because it just made sense:
IT was itself the largest single purchaser of telecom services, since we had to provision links for market data, order transmission to the exchange, our private WAN, links to settlement / clearing agents, and so on.
The majority of telecom services had to interface, one way or another, with computer systems (e.g., to receive market data or to transmit trade data).
The PBXs and trading floor telephone systems were computer systems. (I can recall getting a new AT&T PBX installed. Their techs went to lunch while we were still testing. We found a little problem, which I looked up in the manual and fixed. The AT&T foreman was surprised at that: I told him "Hey, it's just a UNIX box.")
Following on to the last point, evaluating and choosing telecom systems steadily took more and more "systems-type" knowledge.
Buying a PBX was just buying a computer with some specialized I/O hardware; and it came with systems concerns -- security, for example, or the difference in performance between satellite and terrestrial links for TCP/IP.
Now, of course, we are seeing things like Asterix and VoIP, which will provide much tighter integration. Traditional voice comms are still important, but they're by no means something unto themselves.
So the story is that SCO is going to ask the court to unseal some of the evidence to show that IBM has been naughty and committed fraud.
IANAL, but I don't think this would have any effect on the outcome of the legal proceeding at all.
Evidence is evidence, whether it's under seal or not.
It seems to me that this is just another example of SCO's lack of real interest in the lawsuit as a legal proceeding.
Their real interest seems to be flogging their story through their paid shills and credulous members of the press.
The only consistent thread in their legal filings seems to be a desire to drag the case out as long as possible.
Treating a way to model the value of an option with the actual value has caused many derivatives funds to go bankrupt.
Some derivative traders have gone bankrupt. Others (including two firms I've worked for) made a pile of money.
There really are a lot of institutions that trade derivatives, including over-the-counter contracts.
As in any field of human endeavor, there are a few geniuses, a few complete fools, and the majority of more or less average players.
The fools don't last long, but a continued supply is assured by P.T. Barnum's Law of Applied Economics.
These options values have more in common with gambling odds over a very long term, and much less with the value of a specific company during a specific financial quarter.
The value of an option depends on:
UNDERLYING ASSET VALUE This is observable (it's the current value that matters)
EXERCISE (STRIKE) PRICE Specified in the contract
TIME TO EXPIRY Specified in the contract
VOLATILITY OF THE UNDERLYING ASSET PRICE This has to be forecast; however, if there are other traded options on the same asset, we can observe the volatilities implied by their prices.
TERM STRUCTURE OF INTEREST RATES This is observable via the prices of high-quality debt securities (e.g., Treasury bonds in the US, gilts in the UK).
The valuation of any financial asset incorporates some forecast of the future. If you buy a 10-year US Treasury security, it may be essentially free of default risk in nominal dollar terms if held to maturity. However, it is very far from being risk-free in constant dollar (purchasing power) terms; and its value between now and maturity will fluctuate with changes in interest rates.
Not all stocks and bonds have a public market value. Consider an equity interest in a closely-held company, or private placement debt. There are also other things accounted for in the financial statements that are valued using something other than market prices; for example, the depreciated value of capital assets.
Options valuation models are not accounting formulas. They value an option relative to its underlying security, under an equilibrium assumption that there is no riskless arbitrage between the option and the underlying asset.
(This in turn involves the realization that there is a definable dynamic trading strategy, involving the underlying asset and "cash" that will give the same payoffs as the option.)
Organizations that trade these securities apparently believe (and their regulators seem to agree with them) that the models can value options accurately enough to make trading decisions, and to compute P&L.
Again, I'd stress that the current approach is tantamount to assuming that the value of the options is zero. If they're really worthless, why do people want them ?
Black Scholes does not necessarily value options with these properties in the right manner.
I agree that Black-Scholes is most likely not the best method for valuing these options; I mentioned it as more or less the starting point for modern options valuation.
There are many types of options for which B/S is inadequate, but there are other option models: for example, those based on a binomial or trinomial process, or based on numerical integration of the relevant (partial differential) equations.
People have been trading exotic options for more than a decade.
Many of these, perhaps most, are not publicly traded; they are certainly not listed on an organized exchange.
Yet the regulatory agencies, including the SEC, the FRB. and the SFA in Britain, accept model-based valuations for these instruments for the purposes of P&L and risk assessment in banks' financial statements.
The really key point, of course, is that the current approach effectively assumes the value of these options is zero, which is unlikely to be the best possible estimate.
Stock options don't have a clear value. Since you can't say "12,000,000 options are outstanding and excercisable, at a cost to the company of US$120M", you can't apply it as an expense.
I'm sorry, but that is just wrong.
The idea that stock options don't have a clear value will come as news to all the investment banks in the world that trade options, and have to mark their P&L accounts to market every day.
Beginning with Fischer Black and Myron Scholes in 1973, there has been continuing work in developing models to value options.
The key insight is that the option has a value that is a function of the current price of the underlying stock (or other asset); it is also a function of the price volatility of the stock, the time to expiry, and the term structure of interest rates.
Of course, the potential future value of the option is not certain, but so what?
The potential future value of the company's stock or debt is not certain, either, and that does not prevent their current value being reflected in the accounts.
I worked in IT in investment banking for 20+ years. In a couple of cases, I wrote the bank's documentation on our methods of valuing options that was submitted to the regulatory agencies (e.g., the SEC).
Some of those options were one-off, OTC transactions that were much more complicated than ordinary stock options, but I never heard anyone suggest that they didn't "have a clear value."
Resources, features and the schedule are indeed important, but I would also add that there are core features that must be adhered to in order to prevent disasters, which are not features, but critical systems. Sometimes companies like Microsoft will push for more and more features, when a much simpler system will work better and have stronger core competencies.
I think the 'triangle' is one of those seductive things that is almost right, and therefore is an open invitation down the proverbial garden path.
Fortunately, it's not hard to fix. Let's take the elements in order:
RESOURCES This is certainly one of the key things that determines the outcome.
TIME Time (or the schedule) is critical. To paraphrase Fred Brooks in The Mythical Man-Month, more projects have failed for lack of calendar time than for any other single reason.
FEATURES This is the one that is wrong. What it should be is product quality. This is where, IMO, Microsoft (and others) frequently go wrong, by assuming that more features => better.
(Notice that this really addresses the point that the parent post makes.)
I think the focus on features, rather than on quality, is a manifestation of what I call "bookkeeping syndrome": something is adopted as a metric not because it's important, but because it's easy to count.
Using quality as a metric is harder, because it requires actual thought about how the product ought to work, and about what really matters to the potential users.
Nearly every security expert knew that, at some point, Microsoft would be forced to bite the bullet and take a big compatibility hit in order to solidify operating system soft spots--many of which are due to legacy code support.
As the article points out (quote above) it's been obvious for quite a while that Microsoft was going to have to ditch significant backward compatibility if they were to improve security in a meaningful way.
I had an MSDN subscription up until about a year ago, and all you need to do is look through the API docs to see one glaring security weakness after another, owing to the desire to preserve compatibility.
In retrospect, the introduction of the 80386 was the time to bite the bullet and start over with a real OS. Windows users are still paying the price for that mistake.
I have to agree, though: much as I dislike some aspects of Microsoft's corporate behavior, this does seem to be a step in the right direction.
Re: Okay, call me crazy
on
The Face Detector
·
· Score: 4, Interesting
There is an actual mental handicap, called prosopagnosia, which is marked by the inability of the person to identify individual faces. That is, the person can recognize that what (s)he is looking at is a face, but not whose face it is.
Steven Pinker talks about this in his book, How the Mind Works (New York: W.W. Norton & Co., 1997). He writes:
Many psychologists believe that face recognition is special.
In a social species like ours, faces are so important that natural selection gave us a processor that registers the kinds of geometric contours and ratios needed to tell them apart.
Babies lock onto facelike patterns, but not onto other complex and symtrical arrangements. when they are only thirty minutes old.
He also discusses a patient, LH, who was unable to recognize faces following a severe head injury, although he was in other ways entirely normal.
It's important to note that this is a different question than the one the software addresses: it tries to distinguish which images are faces and which are not, not whose faces they are.
While this may be a factual study, I find myself more interested in the alarmist reactions people have to news like this.
The typical reaction is way over the top. As the article points out, these organisms generally cause problems only for people whose immune systems are compromised (e.g., by chemotherapy or HIV infection).
It's certainly a good thing for these folks to know about things that may put them at risk, but it's not something to go crazy about.
It's probably true that some exposure to pathogens is necessary in order for the immune system to develop normally. There have been at least a couple of studies that indicate that kids that grow up on a farm, or with pets, are less likely to have asthma or severe allergies later in life.
Besides, even if this is an issue for someone, it's easy to deal with. Either:
Get a glass shower enclosure, and keep it clean, or
Get a white nylon shower curtain, and run it through the washing machine with some chlorine bleach every week or two.
In any case, I suspect that good hygeine in food preparation is a more important concern for almost anyone.
I think the worst program I ever saw was a BASIC program, written for an HP mini by another grad student. It was intended to sort the contents of a file. It did this by (a) using temporary workspace six times the size of the input file, and (b) destroying the input file as it went. Printed out (on a Teletype, this was the early 1970s), it was several feet long, and completely incomprehensible. But it could sort a 500-line input file in under an hour!
The guy that wrote this masterpiece had great difficulty finding someone to help him debug it. This was partially owing to the characteristics of the program, but mostly because his personal hygeine meant no one was willing to be in the same room unless all the windows were open, and it was January in Chicago.
Historically, IBM has been a 'Red Hat shop,' and one has to wonder if this is a harbinger of things to come."
I don't think that one can describe IBM as purely a "Red Hat shop"; they've had offerings with SuSE in the past. But I'd say their primary motivation is probably just to keep their options open w/r/t OS suppliers. (And, of course, I'm sure it doesn't hurt that Novell is sticking it to SCO, and is a plausible annoyance to Microsoft.)
I mean, look how well things turned out for them the last time they had a single supplier.
Note that Outlook has been included for completeness, both because of its popularity and for use as a reference. I did not include Eudora, even though the latest version does include unique features... as it is both closed source and not available for any UNIX platforms.
And Outlook is open source and available for UNIX platforms? Yes, I know that Outlook / OE are popular, but it is kind of a shame that Eudora was omitted, given that the review was to cover the Windows environment.
Unlike Outlook, it is possible to configure Eudora to avoid some of the security mis-features of Windows.
(For example, you can disable Microsoft's HTML rendering engine.)
The reviewer missed an opportunity to provide a little education.
(BTW, I am sure that there are other good mail clients; I mention Eudora because I'm familiar with it.)
I don't know why the labels and studios cannot just realize the obvious
I'm not sure that they don't realize it. For all the twaddle that is spouted about destroying economic incentives, there is one thing that somehow goes unmentioned (although Eben Moglem did touch on it in his recent speech at Harvard). The core of what's going on with all this (and you can add proprietary software companies to the labels and studios) is perfectly explicable from Economics 101: specifically, microeconomics, which says that in an efficient market, price = marginal cost. (Marginal cost is the incremental cost of adding one unit of output; note this is different from average cost!)
Given today's technology, the marginal cost of producing one more CD or DVD or copy of a program is very close to zero.
Also, there is no particular benefit to having the physical object (e.g., a CD) for itself, unlike, for example, a beautifully printed, illustrated book.
So I'm not sure that lack of realization or understanding is the problem -- studios, labels, and software companies may well realize it. They just don't like the answer, because it means their business model is broken beyond repair.
The 86MB figure does seem high. I just checked on my box (Debian 3.0r2, KDE 3.1.4), and Firefox is using ~56 MB of virtual memory, with a working set of about 44 MB (both as reported by 'top').
(BTW, this is the GTK2+xft Linux binary.)
From a quick read through the story on Groklaw,
the copyright infringement claim has to do with IBM's continuing distribution of AIX, after SCO supposedly revoked their Unix license.
IBM has told the judge that SCO did not comply with her earlier order to specify their claims precisely (in terms of what Linux code was involved). There was apparently a ~30 minute conference with counsel in chambers before the open hearing. It doesn't sound like the judge was too sympathetic to SCO; from one witness's notes:
The judge
said "The problem is, unless you identify those codes, then IBM is
not in a position to have a response. We're at an impasse, and the
case cannot continue with an impasse, that's why there was a court
order".
From other comments the judge made (see the Groklaw write-up), it sounds like SCO may get one more really final order to lay out the specifics of their case. (Ha!)
IBM did not move for dismissal, to the surprise of some observers. My theory is that IBM thinks they have SCO on the run, and want to make sure there is nothing left of them but a glowing crater when this is all done.
I agree, all systems are certainly not the same. I should have said explicitly that I was talking about the (commercial) systems currently in use.
As you describe the OVC system, it sounds good. Essentially, as I understand it, the touchscreen computer is just a high-tech ballot marking device. The tallying machine is a high-tech counter. And the paper ballots are available as the final avenue of appeal in a dispute.
This sounds like a well-designed system, based on your description. I don't think it is a coincidence that it can be mapped pretty directly to the traditional voting method.
One of the favourite forms of lunacy among computer systems designers is the (generally unspoken) assumption that the people who designed the old, "pre-computer" systems were all idiots.
Electronic voting doesn't introduce any functional capability as compared to paper ballots, except for (possibly) faster counting of the results. (Of course, if the result doesn't have to be accurate, I can write a program that will deliver the result even faster.;-)
The other, related issue is whether or not the security model of the voting system is comprehensible to the people who are charged with running the election. I think that, in the case of paper ballots, the model can be understood by any normally-intelligent person. (You only get one ballot paper, it has to be put in the box, no one can mess with the box, etc.)
On the other hand, I would guess that there are fewer than 5 in 100 election officials (including those that select the systems) that actually grok the security model of electronic systems.
The frequently-heard claim by election officials (e.g, here in Fairfax County VA) that the election was held and "it all worked out" is scary evidence of this.
The heart of Nemesysco's security-oriented technology is a signal-processing engine that is said to use more than 8,000 algorithms each time it analyzes an incoming voice waveform....
The law enforcement version achieved about 70 percent accuracy in laboratory trials, according to V Entertainment, and better than 90 percent accuracy against real criminal subjects at a beta test site at the U.S. Air Force's Rome Laboratories.
So... more than 8000 algorithms. And it gets even better results in a field trial than it does in the laboratory. They didn't mention its secret, unbreakable encryption with the 10^6 bit key -- just slipped their mind, I suppose.
And, of course, this technology is so super-duper that they won't sell it to the government, but will market it to gulli^H^H^H^H^H ordinary consumers.
Apparently the market for lunar green cheese flavored with snake oil is thriving (see: P.T. Barnum's Law of Applied Economics).
It could be the case that certain language and platforms are using precalculated tables...
Quite right. Using precalculated tables with interpolation is in fact a reasonable strategy under some circumstances. (Most Slashdot readers -- not I, alas -- are probably too young to have been taught how to interpolate in printed function tables. I still have my trusty copy of the AMS 55 Handbook of Mathematical Functions -- right next to my slide rule.;-)
As you said, accuracy is a primary issue. The earliest versions of Lotus 1-2-3 demonstrated how easy it is to get this wrong. They calculated standard deviation, not from the definition (the right way), but from a "shortcut" formula devised for a person using a desk calculator. This in some circumstances produced a horrendous loss of significance: the answer 1-2-3 came up with for the standard deviation of {999999, 1000000, 1000001} was negative! (The correct answer is obviously 1.)
Someone once said that floating-point numbers are like a pile of sand: every time you move one, you pick up some dirt.
I have a couple of issues with the way the trig tests were done in this benchmark. (BTW, I have posted a similar comment on the original article at OS News.)
First, if you read the description of the test, and look at the source code on the author's Web site, it is obvious that all of the computational "heavy lifting" is being done by the run-time math library routines (e.g., sin, cos, sqrt). I don't know offhand which languages use which libraries; it is not inconceivable that Python, say, uses the C math library. The only thing we can be sure is different in comparing languages is the function call overhead particular to each language.
The second, and IMO more serious issue, is that the test incorporates no measure of how accurate the results are. This is a real issue, because these functions are generally evaluated using an economized power-series approximation. Caculating fewer terms of the series will results in faster execution, but diminished accuracy.
To take a silly example, I can write a very fast C function to return the cosine of x:
double cos ( double x ) { return ( 1.0 - ( (x*x)/2.0 ) ); }
(This uses the first two terms of a Taylor/Maclaurin expansion. It will be fast but not very accurate!)
I think the difficulty of getting over an unfortunate employment history depends a lot on the nature of the person's job, and the overall circumstances.
From what I can tell from the published reports, the "smoke and mirrors" approach to financial disclosure was pretty pervasive at Enron. I think anyone who has experience of that kind of trading business would regard someone who claimed to have known nothing about it with a rather skeptical eye. (I know I would. Although I'm a geek, I do also have an MBA and spent ~20 years working in IT on Wall Street. Had I worked at Enron, I feel certain I would have known something fishy was up -- there just aren't that many secrets in that culture.)
SCO/Caldera, on the other hand, did have a legitimate, although not very successful, business before they entered the litigation industry. If I were hiring, I wouldn't touch any of the management with a bargepole, but a Unix support tech who just did a competent job is a different story.
In any case, in any interview, all you can do is to tell the truth (emphasizing your good points, of course), and hope that the interviewer will take things on the merits.
Slashdot Mirror
I'd suggest the reason he is not in a hurry is that he does realize how this could help Linux, and also how it could hurt Linux. Adding real-time capability is not a free lunch.
As the original C|NET article suggests, there is a class of applications that need real-time capability (which, BTW, is mostly about being able to say that interrupt X will be handled in not more than N time units). But for most applications, real-time capability is neither needed nor really desirable: having it comes at a cost in average processing efficiency.
Incidentally, telecoms is mentioned as a possible application. I don't know enough about cellular telephony to say if it fits, and maybe there are some VoIP applications where it would make sense. But for conventional circuit-switched telecoms (e.g., a telephone switch), it really is not needed.
Interesting. I recall having decidedly mixed feelings about it: I wasn't crazy about having to deal even more with the telephone company, since I wasn't really in the market for more aggravation. :-)
Organizationally, it started happening quite a while ago, at least in some industries. I worked as an IT director in a "Wall Street" firm for several years, and ended up with responsibility for telecoms, too. That wasn't because I sought it, or even wanted it -- I had to get up to speed on a whole bunch of new (to me) stuff -- but because it just made sense:
-
IT was itself the largest single purchaser of telecom services, since we had to provision links for market data, order transmission to the exchange, our private WAN, links to settlement / clearing agents, and so on.
-
The majority of telecom services had to interface, one way or another, with computer systems (e.g., to receive market data or to transmit trade data).
-
The PBXs and trading floor telephone systems were computer systems. (I can recall getting a new AT&T PBX installed. Their techs went to lunch while we were still testing. We found a little problem, which I looked up in the manual and fixed. The AT&T foreman was surprised at that: I told him "Hey, it's just a UNIX box.")
-
Following on to the last point, evaluating and choosing telecom systems steadily took more and more "systems-type" knowledge.
Buying a PBX was just buying a computer with some specialized I/O hardware; and it came with systems concerns -- security, for example, or the difference in performance between satellite and terrestrial links for TCP/IP.
Now, of course, we are seeing things like Asterix and VoIP, which will provide much tighter integration. Traditional voice comms are still important, but they're by no means something unto themselves.IANAL, but I don't think this would have any effect on the outcome of the legal proceeding at all. Evidence is evidence, whether it's under seal or not.
It seems to me that this is just another example of SCO's lack of real interest in the lawsuit as a legal proceeding. Their real interest seems to be flogging their story through their paid shills and credulous members of the press. The only consistent thread in their legal filings seems to be a desire to drag the case out as long as possible.
Can you say "pump and dump"?
Some derivative traders have gone bankrupt. Others (including two firms I've worked for) made a pile of money. There really are a lot of institutions that trade derivatives, including over-the-counter contracts. As in any field of human endeavor, there are a few geniuses, a few complete fools, and the majority of more or less average players. The fools don't last long, but a continued supply is assured by P.T. Barnum's Law of Applied Economics.
These options values have more in common with gambling odds over a very long term, and much less with the value of a specific company during a specific financial quarter.
The value of an option depends on:
The valuation of any financial asset incorporates some forecast of the future. If you buy a 10-year US Treasury security, it may be essentially free of default risk in nominal dollar terms if held to maturity. However, it is very far from being risk-free in constant dollar (purchasing power) terms; and its value between now and maturity will fluctuate with changes in interest rates.
-
Not all stocks and bonds have a public market value. Consider an equity interest in a closely-held company, or private placement debt. There are also other things accounted for in the financial statements that are valued using something other than market prices; for example, the depreciated value of capital assets.
-
Options valuation models are not accounting formulas. They value an option relative to its underlying security, under an equilibrium assumption that there is no riskless arbitrage between the option and the underlying asset.
(This in turn involves the realization that there is a definable dynamic trading strategy, involving the underlying asset and "cash" that will give the same payoffs as the option.)
Organizations that trade these securities apparently believe (and their regulators seem to agree with them) that the models can value options accurately enough to make trading decisions, and to compute P&L.
Again, I'd stress that the current approach is tantamount to assuming that the value of the options is zero. If they're really worthless, why do people want them ?I agree that Black-Scholes is most likely not the best method for valuing these options; I mentioned it as more or less the starting point for modern options valuation. There are many types of options for which B/S is inadequate, but there are other option models: for example, those based on a binomial or trinomial process, or based on numerical integration of the relevant (partial differential) equations. People have been trading exotic options for more than a decade. Many of these, perhaps most, are not publicly traded; they are certainly not listed on an organized exchange. Yet the regulatory agencies, including the SEC, the FRB. and the SFA in Britain, accept model-based valuations for these instruments for the purposes of P&L and risk assessment in banks' financial statements.
The really key point, of course, is that the current approach effectively assumes the value of these options is zero, which is unlikely to be the best possible estimate.
I'm sorry, but that is just wrong. The idea that stock options don't have a clear value will come as news to all the investment banks in the world that trade options, and have to mark their P&L accounts to market every day. Beginning with Fischer Black and Myron Scholes in 1973, there has been continuing work in developing models to value options. The key insight is that the option has a value that is a function of the current price of the underlying stock (or other asset); it is also a function of the price volatility of the stock, the time to expiry, and the term structure of interest rates.
Of course, the potential future value of the option is not certain, but so what? The potential future value of the company's stock or debt is not certain, either, and that does not prevent their current value being reflected in the accounts.
I worked in IT in investment banking for 20+ years. In a couple of cases, I wrote the bank's documentation on our methods of valuing options that was submitted to the regulatory agencies (e.g., the SEC). Some of those options were one-off, OTC transactions that were much more complicated than ordinary stock options, but I never heard anyone suggest that they didn't "have a clear value."
Resources, features and the schedule are indeed important, but I would also add that there are core features that must be adhered to in order to prevent disasters, which are not features, but critical systems. Sometimes companies like Microsoft will push for more and more features, when a much simpler system will work better and have stronger core competencies.
I think the 'triangle' is one of those seductive things that is almost right, and therefore is an open invitation down the proverbial garden path. Fortunately, it's not hard to fix. Let's take the elements in order:
-
RESOURCES This is certainly one of the key things that determines the outcome.
-
TIME Time (or the schedule) is critical. To paraphrase Fred Brooks in The Mythical Man-Month, more projects have failed for lack of calendar time than for any other single reason.
-
FEATURES This is the one that is wrong. What it should be is product quality. This is where, IMO, Microsoft (and others) frequently go wrong, by assuming that more features => better.
(Notice that this really addresses the point that the parent post makes.)
I think the focus on features, rather than on quality, is a manifestation of what I call "bookkeeping syndrome": something is adopted as a metric not because it's important, but because it's easy to count. Using quality as a metric is harder, because it requires actual thought about how the product ought to work, and about what really matters to the potential users.As the article points out (quote above) it's been obvious for quite a while that Microsoft was going to have to ditch significant backward compatibility if they were to improve security in a meaningful way. I had an MSDN subscription up until about a year ago, and all you need to do is look through the API docs to see one glaring security weakness after another, owing to the desire to preserve compatibility.
In retrospect, the introduction of the 80386 was the time to bite the bullet and start over with a real OS. Windows users are still paying the price for that mistake.
I have to agree, though: much as I dislike some aspects of Microsoft's corporate behavior, this does seem to be a step in the right direction.
Steven Pinker talks about this in his book, How the Mind Works (New York: W.W. Norton & Co., 1997). He writes:
He also discusses a patient, LH, who was unable to recognize faces following a severe head injury, although he was in other ways entirely normal.It's important to note that this is a different question than the one the software addresses: it tries to distinguish which images are faces and which are not, not whose faces they are.
The typical reaction is way over the top. As the article points out, these organisms generally cause problems only for people whose immune systems are compromised (e.g., by chemotherapy or HIV infection). It's certainly a good thing for these folks to know about things that may put them at risk, but it's not something to go crazy about.
It's probably true that some exposure to pathogens is necessary in order for the immune system to develop normally. There have been at least a couple of studies that indicate that kids that grow up on a farm, or with pets, are less likely to have asthma or severe allergies later in life.
Besides, even if this is an issue for someone, it's easy to deal with. Either:
- Get a glass shower enclosure, and keep it clean, or
- Get a white nylon shower curtain, and run it through the washing machine with some chlorine bleach every week or two.
In any case, I suspect that good hygeine in food preparation is a more important concern for almost anyone.The guy that wrote this masterpiece had great difficulty finding someone to help him debug it. This was partially owing to the characteristics of the program, but mostly because his personal hygeine meant no one was willing to be in the same room unless all the windows were open, and it was January in Chicago.
I don't think that one can describe IBM as purely a "Red Hat shop"; they've had offerings with SuSE in the past. But I'd say their primary motivation is probably just to keep their options open w/r/t OS suppliers. (And, of course, I'm sure it doesn't hurt that Novell is sticking it to SCO, and is a plausible annoyance to Microsoft.)
I mean, look how well things turned out for them the last time they had a single supplier.
And Outlook is open source and available for UNIX platforms? Yes, I know that Outlook / OE are popular, but it is kind of a shame that Eudora was omitted, given that the review was to cover the Windows environment. Unlike Outlook, it is possible to configure Eudora to avoid some of the security mis-features of Windows. (For example, you can disable Microsoft's HTML rendering engine.) The reviewer missed an opportunity to provide a little education. (BTW, I am sure that there are other good mail clients; I mention Eudora because I'm familiar with it.)
I'm not sure that they don't realize it. For all the twaddle that is spouted about destroying economic incentives, there is one thing that somehow goes unmentioned (although Eben Moglem did touch on it in his recent speech at Harvard). The core of what's going on with all this (and you can add proprietary software companies to the labels and studios) is perfectly explicable from Economics 101: specifically, microeconomics, which says that in an efficient market, price = marginal cost. (Marginal cost is the incremental cost of adding one unit of output; note this is different from average cost!)
Given today's technology, the marginal cost of producing one more CD or DVD or copy of a program is very close to zero. Also, there is no particular benefit to having the physical object (e.g., a CD) for itself, unlike, for example, a beautifully printed, illustrated book.
So I'm not sure that lack of realization or understanding is the problem -- studios, labels, and software companies may well realize it. They just don't like the answer, because it means their business model is broken beyond repair.
The 86MB figure does seem high. I just checked on my box (Debian 3.0r2, KDE 3.1.4), and Firefox is using ~56 MB of virtual memory, with a working set of about 44 MB (both as reported by 'top'). (BTW, this is the GTK2+xft Linux binary.)
IBM has told the judge that SCO did not comply with her earlier order to specify their claims precisely (in terms of what Linux code was involved). There was apparently a ~30 minute conference with counsel in chambers before the open hearing. It doesn't sound like the judge was too sympathetic to SCO; from one witness's notes:
From other comments the judge made (see the Groklaw write-up), it sounds like SCO may get one more really final order to lay out the specifics of their case. (Ha!)
IBM did not move for dismissal, to the surprise of some observers. My theory is that IBM thinks they have SCO on the run, and want to make sure there is nothing left of them but a glowing crater when this is all done.
As you describe the OVC system, it sounds good. Essentially, as I understand it, the touchscreen computer is just a high-tech ballot marking device. The tallying machine is a high-tech counter. And the paper ballots are available as the final avenue of appeal in a dispute.
This sounds like a well-designed system, based on your description. I don't think it is a coincidence that it can be mapped pretty directly to the traditional voting method.
One of the favourite forms of lunacy among computer systems designers is the (generally unspoken) assumption that the people who designed the old, "pre-computer" systems were all idiots.
The other, related issue is whether or not the security model of the voting system is comprehensible to the people who are charged with running the election. I think that, in the case of paper ballots, the model can be understood by any normally-intelligent person. (You only get one ballot paper, it has to be put in the box, no one can mess with the box, etc.)
On the other hand, I would guess that there are fewer than 5 in 100 election officials (including those that select the systems) that actually grok the security model of electronic systems.
The frequently-heard claim by election officials (e.g, here in Fairfax County VA) that the election was held and "it all worked out" is scary evidence of this.
The law enforcement version achieved about 70 percent accuracy in laboratory trials, according to V Entertainment, and better than 90 percent accuracy against real criminal subjects at a beta test site at the U.S. Air Force's Rome Laboratories.
So ... more than 8000 algorithms. And it gets even better results in a field trial than it does in the laboratory. They didn't mention its secret, unbreakable encryption with the 10^6 bit key -- just slipped their mind, I suppose.
And, of course, this technology is so super-duper that they won't sell it to the government, but will market it to gulli^H^H^H^H^H ordinary consumers.
Apparently the market for lunar green cheese flavored with snake oil is thriving (see: P.T. Barnum's Law of Applied Economics).
Quite right. Using precalculated tables with interpolation is in fact a reasonable strategy under some circumstances. (Most Slashdot readers -- not I, alas -- are probably too young to have been taught how to interpolate in printed function tables. I still have my trusty copy of the AMS 55 Handbook of Mathematical Functions -- right next to my slide rule. ;-)
As you said, accuracy is a primary issue. The earliest versions of Lotus 1-2-3 demonstrated how easy it is to get this wrong. They calculated standard deviation, not from the definition (the right way), but from a "shortcut" formula devised for a person using a desk calculator. This in some circumstances produced a horrendous loss of significance: the answer 1-2-3 came up with for the standard deviation of {999999, 1000000, 1000001} was negative! (The correct answer is obviously 1.)
Someone once said that floating-point numbers are like a pile of sand: every time you move one, you pick up some dirt.
First, if you read the description of the test, and look at the source code on the author's Web site, it is obvious that all of the computational "heavy lifting" is being done by the run-time math library routines (e.g., sin, cos, sqrt). I don't know offhand which languages use which libraries; it is not inconceivable that Python, say, uses the C math library. The only thing we can be sure is different in comparing languages is the function call overhead particular to each language.
The second, and IMO more serious issue, is that the test incorporates no measure of how accurate the results are. This is a real issue, because these functions are generally evaluated using an economized power-series approximation. Caculating fewer terms of the series will results in faster execution, but diminished accuracy.
To take a silly example, I can write a very fast C function to return the cosine of x:
(This uses the first two terms of a Taylor/Maclaurin expansion. It will be fast but not very accurate!)From what I can tell from the published reports, the "smoke and mirrors" approach to financial disclosure was pretty pervasive at Enron. I think anyone who has experience of that kind of trading business would regard someone who claimed to have known nothing about it with a rather skeptical eye. (I know I would. Although I'm a geek, I do also have an MBA and spent ~20 years working in IT on Wall Street. Had I worked at Enron, I feel certain I would have known something fishy was up -- there just aren't that many secrets in that culture.)
SCO/Caldera, on the other hand, did have a legitimate, although not very successful, business before they entered the litigation industry. If I were hiring, I wouldn't touch any of the management with a bargepole, but a Unix support tech who just did a competent job is a different story.
In any case, in any interview, all you can do is to tell the truth (emphasizing your good points, of course), and hope that the interviewer will take things on the merits.
It is accessible only to CIA employees and guests admitted to those closed quarters.
The International Spy Museum mentioned is open to the public, but admission is quite pricey: about $10 per head, if I recall correctly.