As these patents are very clearly about data, not documents, I don't think SGML is a valid antecedent.
Huh? What's the difference between "data" and the contents of a "document"? As a long-term programmer, I'd assert that they are the same thing.
One example I've had some fun with: I have a number of programs whose makefiles include commands to build some of the.h and/or.c files by running some "man..." commands and feeding the output to a perl script.
"What??? Your source code is built by a program that reads the manual and converts it to C?"
"Yeah; you got a problem with that?"
To your typical perl hacker, the term "document" is merely a warning that the data is probably embedded in junk that's much harder to parse away than need be.
Heh. I'll bet that encrypted VoIP is already in use in Saudia Arabia. The ruling class there has a lot of phone traffic that they really don't want tapped.
Rather, they'll try to strictly control who is allowed to use encryption. That way, they can spy on all the little people, while the little people (and media, police, etc.) can't spy on them.
Similarly in quite a lot of other countries.
I keep wondering why our current rulers here in the US don't seem to be trying to force us to drop ssh and go back to telnet. It would be a security disaster for everyone, of course, but why would they care?
I haven't actually read of any US or European challenges to the switch from telnet to ssh. I use it all the time, and I've never gotten any nasty letters from and authorities. Anyone have information about attempts to shut ssh down?
He might be trying to make the point that the telco's think that VOIP isn't legitimate,...
Actually, this isn't credible. They are using it heavily themselves, internally. For some years now, it's been widely reported within the comms and computer industry that, except for the link to your home, most of the "phone" traffic in the US and other countries has been converted to VoIP. The phone companies have found that running IP and VoIP over their private lines is a cheap and very effective way to multiplex everything. They don't even have to write the software, and IP is far easier to manage than most of the voice-only schemes that they had been developing.
An aside is that a phone link is usually an RTP connection, not TCP. Look it up. It's a 15-year-old protocol that is essentially TCP augmented by a "QOS" (guaranteed minimal throughput) feature.
What they're really trying to do is make sure that they control that "last mile" to your phone outlet, and that they can continue to charge you the old monopoly prices even after they've radically lowered their operating costs by using VoIP internally.
So the telcos think that VoIP is entirely legitimate and use it heavily. But only they should be allowed to sell it. Even if you own your own private network, you shouldn't be permitted to run VoIP internally; you must buy it from your local phone company in a non-competitive market.
It's all about the money. They're just protecting their century-old business plan and its profits.
Right. The APL folks realized that a compiler knows the type of each variable, and can easily ffigure out whether the args of, say, A+B are scalars or arrays. If they are arrays with compatible shapes, the compiler just does the obvious loop, and produces a result that is also an array (which may be assigned, used in another operation, passed to a function, whatever).
Some languages would have problems implementing this. In C, for example, the compiler doesn't always know the size of an array, so it wouldn't know the bounds for the loop. In perl, the array's size is available, so the loop is feasible. @A+@B could easily generate the sum, using zero for missing or undefined entires, giving a sum the same size as the larger of @A and @B. You'd probably also have to treat any non-numeric values as zero. You could also make %A+%B work in the obvious way, by running the index through all the keys of both hash tables.
One of the initial weirdnesses in APL was that A*B does the same sort of same-element multiply. It isn't the [matrix] product of A and B. That has to be defined as a separate operation. The general pattern was that the value of was an array produced by simply applying to each pair of corresponding values in and . If they are N-dimensional arrays, this requires N nested loops, of course. On a CPU with parallel-processing or vector operations, the operations can be done in parallel.
Since this works with all binary ops, in perl you could also do something like @A.@B to get the results of catenating all the corresponding items of both lists (using '' for any missing values, of course).
Anyway, in languages where it's feasible (not C), this can make for some very compact, elegant code for table calculations. And it eliminates most of the common off-by-one sort of bugs.
[E]very language since Lisp has been trying to catch up with Lisp, which means that 40 years of computer history were mostly spent trying to make what already exists exist again. And failing at it.
Pretty much true. And you could substitute several other languages. Back in the 70's, I did projects in both Snobol and Prolog. Ever since then, I've repeatedly regretted the lack of powerful pattern matching in every language I've used (including perl, which still can't do recursive patterns), and I've often really wished I could just code a simple resolution in the primitive languages I'm forced by "the market" to use.
And why do we have to keep coding loops to run through arrays? The APL folks showed us how easy it is for your language to do that for you, and they did it decades ago. This would eliminate zillions of off-by-one bugs, and half the code in a lot of routines.
Isaac Newton's famous statement about standing on the shoulders of giants. Some time back, someone (I don't recall who) observed that in the computer field, we don't stand on the shoulders of giants; we stand on their toes.
That's an easy one. The "proof" of God's non-existence is the same as the "proof" of God's existence: Someone wrote a book that claimed that God doesn't exist.
Similarly, Superman exists. The fact that Superman Comics has been published should be sufficient proof.
Just a couple of days ago I was talking to a senior IT person explaining the advantages of a particular web server configuration. I went to demonstrate something on a terminal monitor, and the guy started laughing said "What, it doesn't have a Windows interface? And you're trying to tell me that this is advanced server technology? We're not going to use primitive Unix systems here.
Heh. I've done quite a bit of network-management development, and I've frequently seen a similar phenomenon. The network people are hard at work diagnosing a problem, when a manager wanders by, sees their screens full of text windows, and asks why they aren't using the fancy Network Management app that they paid so much money for. Usually the answers from the harried network people is along the lines of "Because we're trying to solve a problem here" in a tone of voice that says "Go away and stop wasting our time".
If the manager persists, they let him know in no uncertain terms what they think of the flashy GUI package that's great for impressing management but utterly worthless at diagnosing problems when the network isn't running correctly.
It can be fun, after such a package has been installed and a problem pops up, to watch the network folks instantly abandon the flashy GUI tools and start opening text windows so they can diagnose the problem.
It is somewhat disappointing, after all these years, to see that the GUI tools really haven't gotten all that much better. 30 years ago, we had displays showing netowork maps, with the nodes and lines colored to indicate the response to pings. Today we still have those, and they're still the most useful of the pretty pictures.
Ah, so the machine isn't guaranteed to be without flaws, whereas code review is guaranteed to find these flaws. Fascinating! Maybe we should tell the computing industry about this "source code review" idea, and make bugs completely obsolete!
Actually, some software firms have heard of this concept. A few even implement it. I've worked for a number of them.
Unfortunately, in almost every case, I've been apalled at the outcome of the reviews. I've yet to see a case where a reviewer asked a question about my code that I hadn't already asked myself. I generally reply by show them the part of my test suite that tests for their question. I've known a number of other programmers who have expressed the same view: Code reviews sound good, but in practice they're always a waste of time. The programmer was always way ahead of the reviewers.
I don't recall any case of a review ever finding an actual bug in my code (or in anyone else's). This doesn't mean there weren't any bugs, of course.
Similarly with QA (Quality Assurance) teams, which sounds like a Really Good Idea. But invariably, when I hand them some code, I also have to hand them my test suite if they are to do their job. And I have to watch for their attempts at augmenting the test suite, because invariably they really need my help.
OTOH, this does put me on very good terms with the QA people. They find that I'm on their side, sympathetic, and willing to help them do a nearly impossible job. Since I've been working on the code, I understand the topic and the potential problems better than they do.
Well, because people keep bringing it up here, in a discussion of an article on computer code and court evidence. I don't think that military computer code should be relevant here, but given how many people are using it as an argument, it's obvious that a lot of people do think it's relevant. Otherwise why would there be so many messages about military secrets here?
I just thought I should make it clear that some of us see through this attempt at misdirection. I don't think you'd get very far with it in the case at hand. And I suspect that the judge would probably berate your lawyer firmly for such a legal argument in a DUI case.
We don't want our enemies to know all of our advanced algorithms, no matter how "secure" the code is.
Considering that the topic is code embedded in equipment that's providing evidence in civil or criminal courts, what you're saying is that you consider the defendant an enemy, and that your code must be secure from that enemy defendant's analysis.
We can only hope that some day soon you find yourself the defendant in a court, with the evidence against you provided by an electronic "black box" that you aren't permitted to examine.
There is an old legal principle that defendants should be permitted to examine the evidence against them. The alternative is that you can be convicted on the basis of secret evidence. Do you want to be the defendant iin such a case?
MAYBE SO THAT THE UNITED STATES RETAINS ITS MILITARY TECHNOLOGICAL SUPERORITY
So this is why, when I'm in court trying to defend myself against some DUI "evidence" provided by an electronic black box, I shouldn't be allowed to examine the code? The court should just accept this "evidence" unexamined, and I shouldn't be permitted to examine the it, because doing so would threaten our military superiority?
If that's so, then this vaunted military superiority is primarily a threat to our own citizens, not to any foreign antagonists (who aren't going to be in an American court on DUI charges).
... merely the empty claim of a uncheckable device.
Well it would be if there wasn't any other way to test or calibrate it.
As a programmer, I understand quite well how difficult I could make this.
Is the date odd? Does the suspect have an odd number of letters in their name? Did the operator of the equipment type a '#' in a certain field? If so, blank out that '#' and indicate a positive reading.
Lots of software has undocumented responses to specific obscure input data. Such responses are called "Easter eggs". They are easy to program, difficult to discover, and can do anything that the programmer can implement.
I challenge anyone to discover all the Easter eggs in any software (and prove that they've discovered them all) without access to the code. Yes, it can be done, by brute force, by testing the responses to all possible input. But for even minimal software, the time required to do this can easily be measured in centuries or millenia.
Any claim that software can be verified without access to the code, and shown to not contain hidden behavior, is disingenuous at best. Believing this can be done shows a profound lack of understanding of the nature of digital software.
(Actually, I program Easter eggs into most software that I write. I usually call them "debug hooks". I remove most of them, but it can be a good idea to have some of them in place when a customer calls asking about strange behavior. And I usually do document them, but in a separate document intended for maintainers rather than users, because my employers usually insist it be done this way. Some of those debug hooks can be used to radically interfere with the software's behavior.)
I used one important thing for at least a decade before the standard came out: the C language. And I've never regretted it.
Funny thing was that when ANSI C finally came into existence, there was hardly any of my old K&R code that didn't work. I just casually ignored the warning messages, until I got around to inserting the type-cast noise (all the while grumbling about idiotic compilers that obviously knew how to do it, just as the old compilers had;-).
I did like the addition of// for comments, though.
Actually, in the case of TFA, it's pretty clear that "standard" means "something approved by an official standards organization".
That still leaves lots of rooms for ambiguity, of course, as there are over 180 countries on Earth, not to mention international standards bodies.
Then there's the "standard American" definition, as exemplified by all the hardware stores that sell tools and other measurable things in two kinds of sizes: "metric" and "standard". (To people in the rest of the world: No; this is not a joke. They really do that.)
When you consider MySQL in a vacuum and in the context of a limited set of tasks for which it has been optimized over the course of its history then MySQL absolutely rocks. But "kick ass database" in my world means a little more than that.
Of course. And every other DB user would probably say something very similar.
The problem is that "kickass" isn't a simple adjective; it describes a relations between an app and a user. It basically means "This thing does what I need in a way that I personally find simple and easy to use". What's a "kickass" app to one person is a horribly deficient, user-hostile app to another.
The OSS world has shown it can make kickass databases
No, the "OSS world" has made no such thing.
Well, now; that depends on whose ass is being kicked.
The canonical example, of course is mySQL. And instantly, I can hear the mouse buttons click as hundreds of readers his the Reply button to royally flame me. We'll have to read another list of "mySQL can't do X" messages.
Well, yes, it probably can't. And a lot of happy users just reply "I don't need to do X. When I do, I'll look at DBs that support X. Meanwhile, mySQL runs significantly faster (with less memory) on the things that I need to do than those fancy commercial DBs that can do X."
As a programmer, I understand quite well why generally a tool designed to do tasks A, B and C will generally run more slowly for all of them than three tools each designed to do A, B or C alone. That's pretty much a no-brainer. You add features to a big program, you usually find that some of the old features run somewhat more slowly, mostly because of all those extra if tests scattered through the code. And it uses more memory, mostly because of the initialization data for data structures for the new features.
So, depending on the state of your ass, there may well be OSS DBs that can kick it quite well. Or maybe not. YMMV, as they say, depending on what you need it to do.
Ah, but you just admitted that you do share them with people who haven't paid for them - your kids. In the eyes of the MPAA and the US Congress, that makes you a vicious criminal.
Heh. Some day they'll do wireless, and they'll take over the world. Wait; that's google, isn't it?
Anyway, here's my sample of one: A year or so back, my wife and I decided to terminate our cable service. We'd only watched TV for news and movies, really. Here in the US, TV news has long since become a joke, and when news.google.com came out, we realized very quickly that it gave us more news from more viewpoints in 10 minutes than TV did in an evening of news shows. And we subscribed to Netflix, eliminating the movies angle. We realized that the only thing we'd turned the TV on for months was the Jon Stewart's Daily Show, and even that had become available in video clips on the political blogs a day after a show was aired. We asked ourself "Why are we paying for this?"
So we switched to DSL (speakeasy), including VoIP. Half the price for a real IP link with no port blocking. They're very nice if the local power structure permits them to sell in your neighborhood.
Meanwhile, we'd been following the iPod stories, bue hadn't seen anything that persuaded us to buy one of the cute little gadgets. Now, with the announcement of videos, my wife (the real old-movie freak) is mentioning "iPod" once or twice a day. My bet is that she'll wait until she sees a couple in action, and then she'll have to buy one. She'll then drop her Netflix subscription. She'll just download the movies to her Mac PB, where she'll watch most of them. Some will go to the iPod. Depending on the price they settle on, this will probably be comparable to the Netflix subscription price, but a lot more convenient.
Now if they'd just incorporate a "smartphone" (phone + calendar), with full-time internet access, it'd be an instant sell. We could carry just the one electronic barnacle.
And if they'd run OSX internally, I could even program it...
(Yeah, I know; linux or freebsd would be better. But what're the chances of either of those?;-)
(And while I'm dreaming, how about a browser that works with google maps, and GPS capability? Wouldn't it be fun to work on software that combines these in a wireless gadget?)
I've never heard an actual explanation on why exactly it is believed that C-14 concentrations in the atmosphere have been relatively constant
They aren't,...
Actually, they are, if that relatively means comparing with things like CO2, methane, or ozone. That is, over a period of decades or centuries, you can get 5% or 10% variations. But you don't get 1000% variations, at least not in the past 100,000 years or so.
Suitable corrections are available
Yeah, but there's a small additional qualification: The correction tables are somewhat different for, say, Sweden, Kamchatka, and southern Chile. Not a lot different, of course, since the major source of variation comes from off-planet. But if you want the best accuracy, you want tables from your part of the world.
As usual, there's a good introductory article on the topic at wikipedia, including lots of links that will explain more than you ever wanted to know on the topic. The correlations tables are fairly easy to track down.
One interesting tidbit is that we're in now in a period of abnormally low C-14 in living things. This is because of the recent mining of geological carbon (coal, oil, natural gas) and conversion to atmospheric CO2. There's no C-14 in this CO2, so plants growing now appear to have a C-14 age of several millenia without a correction.
(Now we can expect zillions of followups from the global-warming denial crowd.;-)
But this isn't all that unusual. There are places in the world where the local carbon supply has long included a lot of geological carbon. These are mostly places with limestone under the soil. For example in the Valley of Mexico there's a well-understood problem with Aztec remains. The area is rich in limestone, and much of the ground water is high in CO2 from this source. This makes C-14 dating in the area very difficult, and C-14 dates aren't trusted without confirmation by other methods. There's a similar problem with dates in the Karst region in the Balkans. Any archaeologist here can probably rattle off a list of other such problematical areas.
Nope; I've never seen that screen. I do see a screen with
[!!] Partition disks across the top. But it doesn't present me with the choise of erasing the disk. It only allows me to "Manually edit partition table" and "".
Not here. I have a several-years-old Dell box with an old RH installed, wasn't using it for much, so I decided to try Ubuntu. It seemed to be installing ok (though it's hard to spot error messages when they scroll off the top too fast to read). But when it settled down, all I got was a brownish-green screen with a typical pointer arrowhead in the center. That's all. It doesn't respond to anything on the keyboard, and the mouse doesn't move the arrow.
This is with the "live" CD. I also tried the "install" CD. This did demo that the keyboard and mouse work with Ubuntu, as I could use both of them during the prelim parts of the install. I got as far as the part about partitioning the disk, and can't get past that. It insists that I partition the disk, but nothing it shows me makes any sense. No info about the disk that it wants partitioned, and no matter what I select, it just leads back to that first screen about disk partitioning. After a few times around each path back to that screen, I gave up.
I suspect that they could use some filling out in their online troubleshooting stuff. I don't seem to find anything saying what to do when it behaves the way I see.
One thing curious is its remark that it won't repartition if there's already a linux installed. There is one installed, the old RH system. But it keeps insisting that I do some sort of partitioning, and won't advance past that point, not even if I tell it to accept the partitions. That just bounces me back to the first page about partitioning.
Anyone have a pointer to clues about installing it over an existing linux installation? Any way to say "wipe the disk and start from scratch"?
is "best informed" defined as most closely folowing the democratic party?
Well, it's not defined that way, but that's semi-true.
The "semi-" is because the people who voted for the various smaller parties generally rated as even better-informed by just about any measure. The Democrats are better-informed only in comparison to Republicans. This is not what I'd call high praise.
Most of these surveys measured informedness by asking people questions about various candidates' policies. Depending on the questions asked, they came up with somewhat different numbers, of course. Mostly, they said that Republicans typically failed to answer any questions correctly around 70% to 80% of the time. Democrats typically got at least some correct answers around the same percentage. But the "third party" voters, regardless of party, typically got 90% or more of their answers right, for all the candidates.
Of course, I suppose one could bias the results by making up loaded questions. But if you look at the actual questions asked by the major pollsters, it's pretty clear that they took a "pox on both your houses" approach. It's not difficult to be equally "biased" against all candidates.
Slashdot Mirror
As these patents are very clearly about data, not documents, I don't think SGML is a valid antecedent.
.h and/or .c files by running some "man ..." commands and feeding the output to a perl script.
Huh? What's the difference between "data" and the contents of a "document"? As a long-term programmer, I'd assert that they are the same thing.
One example I've had some fun with: I have a number of programs whose makefiles include commands to build some of the
"What??? Your source code is built by a program that reads the manual and converts it to C?"
"Yeah; you got a problem with that?"
To your typical perl hacker, the term "document" is merely a warning that the data is probably embedded in junk that's much harder to parse away than need be.
Heh. I'll bet that encrypted VoIP is already in use in Saudia Arabia. The ruling class there has a lot of phone traffic that they really don't want tapped.
Rather, they'll try to strictly control who is allowed to use encryption. That way, they can spy on all the little people, while the little people (and media, police, etc.) can't spy on them.
Similarly in quite a lot of other countries.
I keep wondering why our current rulers here in the US don't seem to be trying to force us to drop ssh and go back to telnet. It would be a security disaster for everyone, of course, but why would they care?
I haven't actually read of any US or European challenges to the switch from telnet to ssh. I use it all the time, and I've never gotten any nasty letters from and authorities. Anyone have information about attempts to shut ssh down?
He might be trying to make the point that the telco's think that VOIP isn't legitimate, ...
Actually, this isn't credible. They are using it heavily themselves, internally. For some years now, it's been widely reported within the comms and computer industry that, except for the link to your home, most of the "phone" traffic in the US and other countries has been converted to VoIP. The phone companies have found that running IP and VoIP over their private lines is a cheap and very effective way to multiplex everything. They don't even have to write the software, and IP is far easier to manage than most of the voice-only schemes that they had been developing.
An aside is that a phone link is usually an RTP connection, not TCP. Look it up. It's a 15-year-old protocol that is essentially TCP augmented by a "QOS" (guaranteed minimal throughput) feature.
What they're really trying to do is make sure that they control that "last mile" to your phone outlet, and that they can continue to charge you the old monopoly prices even after they've radically lowered their operating costs by using VoIP internally.
So the telcos think that VoIP is entirely legitimate and use it heavily. But only they should be allowed to sell it. Even if you own your own private network, you shouldn't be permitted to run VoIP internally; you must buy it from your local phone company in a non-competitive market.
It's all about the money. They're just protecting their century-old business plan and its profits.
Right. The APL folks realized that a compiler knows the type of each variable, and can easily ffigure out whether the args of, say, A+B are scalars or arrays. If they are arrays with compatible shapes, the compiler just does the obvious loop, and produces a result that is also an array (which may be assigned, used in another operation, passed to a function, whatever).
Some languages would have problems implementing this. In C, for example, the compiler doesn't always know the size of an array, so it wouldn't know the bounds for the loop. In perl, the array's size is available, so the loop is feasible. @A+@B could easily generate the sum, using zero for missing or undefined entires, giving a sum the same size as the larger of @A and @B. You'd probably also have to treat any non-numeric values as zero. You could also make %A+%B work in the obvious way, by running the index through all the keys of both hash tables.
One of the initial weirdnesses in APL was that A*B does the same sort of same-element multiply. It isn't the [matrix] product of A and B. That has to be defined as a separate operation. The general pattern was that the value of was an array produced by simply applying to each pair of corresponding values in and . If they are N-dimensional arrays, this requires N nested loops, of course. On a CPU with parallel-processing or vector operations, the operations can be done in parallel.
Since this works with all binary ops, in perl you could also do something like @A.@B to get the results of catenating all the corresponding items of both lists (using '' for any missing values, of course).
Anyway, in languages where it's feasible (not C), this can make for some very compact, elegant code for table calculations. And it eliminates most of the common off-by-one sort of bugs.
[E]very language since Lisp has been trying to catch up with Lisp, which means that 40 years of computer history were mostly spent trying to make what already exists exist again. And failing at it.
Pretty much true. And you could substitute several other languages. Back in the 70's, I did projects in both Snobol and Prolog. Ever since then, I've repeatedly regretted the lack of powerful pattern matching in every language I've used (including perl, which still can't do recursive patterns), and I've often really wished I could just code a simple resolution in the primitive languages I'm forced by "the market" to use.
And why do we have to keep coding loops to run through arrays? The APL folks showed us how easy it is for your language to do that for you, and they did it decades ago. This would eliminate zillions of off-by-one bugs, and half the code in a lot of routines.
Isaac Newton's famous statement about standing on the shoulders of giants. Some time back, someone (I don't recall who) observed that in the computer field, we don't stand on the shoulders of giants; we stand on their toes.
That's an easy one. The "proof" of God's non-existence is the same as the "proof" of God's existence: Someone wrote a book that claimed that God doesn't exist.
Similarly, Superman exists. The fact that Superman Comics has been published should be sufficient proof.
Just a couple of days ago I was talking to a senior IT person explaining the advantages of a particular web server configuration. I went to demonstrate something on a terminal monitor, and the guy started laughing said "What, it doesn't have a Windows interface? And you're trying to tell me that this is advanced server technology? We're not going to use primitive Unix systems here.
Heh. I've done quite a bit of network-management development, and I've frequently seen a similar phenomenon. The network people are hard at work diagnosing a problem, when a manager wanders by, sees their screens full of text windows, and asks why they aren't using the fancy Network Management app that they paid so much money for. Usually the answers from the harried network people is along the lines of "Because we're trying to solve a problem here" in a tone of voice that says "Go away and stop wasting our time".
If the manager persists, they let him know in no uncertain terms what they think of the flashy GUI package that's great for impressing management but utterly worthless at diagnosing problems when the network isn't running correctly.
It can be fun, after such a package has been installed and a problem pops up, to watch the network folks instantly abandon the flashy GUI tools and start opening text windows so they can diagnose the problem.
It is somewhat disappointing, after all these years, to see that the GUI tools really haven't gotten all that much better. 30 years ago, we had displays showing netowork maps, with the nodes and lines colored to indicate the response to pings. Today we still have those, and they're still the most useful of the pretty pictures.
Ballmer knows he's got a long roe to hoe.
There's something very fishy about that comment.
But I wouldn't want to start a row over it.
Ah, so the machine isn't guaranteed to be without flaws, whereas code review is guaranteed to find these flaws. Fascinating! Maybe we should tell the computing industry about this "source code review" idea, and make bugs completely obsolete!
...
Actually, some software firms have heard of this concept. A few even implement it. I've worked for a number of them.
Unfortunately, in almost every case, I've been apalled at the outcome of the reviews. I've yet to see a case where a reviewer asked a question about my code that I hadn't already asked myself. I generally reply by show them the part of my test suite that tests for their question. I've known a number of other programmers who have expressed the same view: Code reviews sound good, but in practice they're always a waste of time. The programmer was always way ahead of the reviewers.
I don't recall any case of a review ever finding an actual bug in my code (or in anyone else's). This doesn't mean there weren't any bugs, of course.
Similarly with QA (Quality Assurance) teams, which sounds like a Really Good Idea. But invariably, when I hand them some code, I also have to hand them my test suite if they are to do their job. And I have to watch for their attempts at augmenting the test suite, because invariably they really need my help.
OTOH, this does put me on very good terms with the QA people. They find that I'm on their side, sympathetic, and willing to help them do a nearly impossible job. Since I've been working on the code, I understand the topic and the potential problems better than they do.
Now if this would only get rid of the bugs
Well, because people keep bringing it up here, in a discussion of an article on computer code and court evidence. I don't think that military computer code should be relevant here, but given how many people are using it as an argument, it's obvious that a lot of people do think it's relevant. Otherwise why would there be so many messages about military secrets here?
I just thought I should make it clear that some of us see through this attempt at misdirection. I don't think you'd get very far with it in the case at hand. And I suspect that the judge would probably berate your lawyer firmly for such a legal argument in a DUI case.
We don't want our enemies to know all of our advanced algorithms, no matter how "secure" the code is.
Considering that the topic is code embedded in equipment that's providing evidence in civil or criminal courts, what you're saying is that you consider the defendant an enemy, and that your code must be secure from that enemy defendant's analysis.
We can only hope that some day soon you find yourself the defendant in a court, with the evidence against you provided by an electronic "black box" that you aren't permitted to examine.
There is an old legal principle that defendants should be permitted to examine the evidence against them. The alternative is that you can be convicted on the basis of secret evidence. Do you want to be the defendant iin such a case?
MAYBE SO THAT THE UNITED STATES RETAINS ITS MILITARY TECHNOLOGICAL SUPERORITY
So this is why, when I'm in court trying to defend myself against some DUI "evidence" provided by an electronic black box, I shouldn't be allowed to examine the code? The court should just accept this "evidence" unexamined, and I shouldn't be permitted to examine the it, because doing so would threaten our military superiority?
If that's so, then this vaunted military superiority is primarily a threat to our own citizens, not to any foreign antagonists (who aren't going to be in an American court on DUI charges).
... merely the empty claim of a uncheckable device.
Well it would be if there wasn't any other way to test or calibrate it.
As a programmer, I understand quite well how difficult I could make this.
Is the date odd? Does the suspect have an odd number of letters in their name? Did the operator of the equipment type a '#' in a certain field? If so, blank out that '#' and indicate a positive reading.
Lots of software has undocumented responses to specific obscure input data. Such responses are called "Easter eggs". They are easy to program, difficult to discover, and can do anything that the programmer can implement.
I challenge anyone to discover all the Easter eggs in any software (and prove that they've discovered them all) without access to the code. Yes, it can be done, by brute force, by testing the responses to all possible input. But for even minimal software, the time required to do this can easily be measured in centuries or millenia.
Any claim that software can be verified without access to the code, and shown to not contain hidden behavior, is disingenuous at best. Believing this can be done shows a profound lack of understanding of the nature of digital software.
(Actually, I program Easter eggs into most software that I write. I usually call them "debug hooks". I remove most of them, but it can be a good idea to have some of them in place when a customer calls asking about strange behavior. And I usually do document them, but in a separate document intended for maintainers rather than users, because my employers usually insist it be done this way. Some of those debug hooks can be used to radically interfere with the software's behavior.)
I used one important thing for at least a decade before the standard came out: the C language. And I've never regretted it.
;-).
// for comments, though.
Funny thing was that when ANSI C finally came into existence, there was hardly any of my old K&R code that didn't work. I just casually ignored the warning messages, until I got around to inserting the type-cast noise (all the while grumbling about idiotic compilers that obviously knew how to do it, just as the old compilers had
I did like the addition of
Actually, in the case of TFA, it's pretty clear that "standard" means "something approved by an official standards organization".
That still leaves lots of rooms for ambiguity, of course, as there are over 180 countries on Earth, not to mention international standards bodies.
Then there's the "standard American" definition, as exemplified by all the hardware stores that sell tools and other measurable things in two kinds of sizes: "metric" and "standard". (To people in the rest of the world: No; this is not a joke. They really do that.)
When you consider MySQL in a vacuum and in the context of a limited set of tasks for which it has been optimized over the course of its history then MySQL absolutely rocks. But "kick ass database" in my world means a little more than that.
Of course. And every other DB user would probably say something very similar.
The problem is that "kickass" isn't a simple adjective; it describes a relations between an app and a user. It basically means "This thing does what I need in a way that I personally find simple and easy to use". What's a "kickass" app to one person is a horribly deficient, user-hostile app to another.
Is the phonetic spelling here.
In that case, shouldn't it be "Oregun"?
Or maybe just "Orgun".
The OSS world has shown it can make kickass databases
No, the "OSS world" has made no such thing.
Well, now; that depends on whose ass is being kicked.
The canonical example, of course is mySQL. And instantly, I can hear the mouse buttons click as hundreds of readers his the Reply button to royally flame me. We'll have to read another list of "mySQL can't do X" messages.
Well, yes, it probably can't. And a lot of happy users just reply "I don't need to do X. When I do, I'll look at DBs that support X. Meanwhile, mySQL runs significantly faster (with less memory) on the things that I need to do than those fancy commercial DBs that can do X."
As a programmer, I understand quite well why generally a tool designed to do tasks A, B and C will generally run more slowly for all of them than three tools each designed to do A, B or C alone. That's pretty much a no-brainer. You add features to a big program, you usually find that some of the old features run somewhat more slowly, mostly because of all those extra if tests scattered through the code. And it uses more memory, mostly because of the initialization data for data structures for the new features.
So, depending on the state of your ass, there may well be OSS DBs that can kick it quite well. Or maybe not. YMMV, as they say, depending on what you need it to do.
Ah, but you just admitted that you do share them with people who haven't paid for them - your kids. In the eyes of the MPAA and the US Congress, that makes you a vicious criminal.
Heh. Some day they'll do wireless, and they'll take over the world. Wait; that's google, isn't it?
...
;-)
Anyway, here's my sample of one: A year or so back, my wife and I decided to terminate our cable service. We'd only watched TV for news and movies, really. Here in the US, TV news has long since become a joke, and when news.google.com came out, we realized very quickly that it gave us more news from more viewpoints in 10 minutes than TV did in an evening of news shows. And we subscribed to Netflix, eliminating the movies angle. We realized that the only thing we'd turned the TV on for months was the Jon Stewart's Daily Show, and even that had become available in video clips on the political blogs a day after a show was aired. We asked ourself "Why are we paying for this?"
So we switched to DSL (speakeasy), including VoIP. Half the price for a real IP link with no port blocking. They're very nice if the local power structure permits them to sell in your neighborhood.
Meanwhile, we'd been following the iPod stories, bue hadn't seen anything that persuaded us to buy one of the cute little gadgets. Now, with the announcement of videos, my wife (the real old-movie freak) is mentioning "iPod" once or twice a day. My bet is that she'll wait until she sees a couple in action, and then she'll have to buy one. She'll then drop her Netflix subscription. She'll just download the movies to her Mac PB, where she'll watch most of them. Some will go to the iPod. Depending on the price they settle on, this will probably be comparable to the Netflix subscription price, but a lot more convenient.
Now if they'd just incorporate a "smartphone" (phone + calendar), with full-time internet access, it'd be an instant sell. We could carry just the one electronic barnacle.
And if they'd run OSX internally, I could even program it
(Yeah, I know; linux or freebsd would be better. But what're the chances of either of those?
(And while I'm dreaming, how about a browser that works with google maps, and GPS capability? Wouldn't it be fun to work on software that combines these in a wireless gadget?)
I've never heard an actual explanation on why exactly it is believed that C-14 concentrations in the atmosphere have been relatively constant
...
;-)
They aren't,
Actually, they are, if that relatively means comparing with things like CO2, methane, or ozone. That is, over a period of decades or centuries, you can get 5% or 10% variations. But you don't get 1000% variations, at least not in the past 100,000 years or so.
Suitable corrections are available
Yeah, but there's a small additional qualification: The correction tables are somewhat different for, say, Sweden, Kamchatka, and southern Chile. Not a lot different, of course, since the major source of variation comes from off-planet. But if you want the best accuracy, you want tables from your part of the world.
As usual, there's a good introductory article on the topic at wikipedia, including lots of links that will explain more than you ever wanted to know on the topic. The correlations tables are fairly easy to track down.
One interesting tidbit is that we're in now in a period of abnormally low C-14 in living things. This is because of the recent mining of geological carbon (coal, oil, natural gas) and conversion to atmospheric CO2. There's no C-14 in this CO2, so plants growing now appear to have a C-14 age of several millenia without a correction.
(Now we can expect zillions of followups from the global-warming denial crowd.
But this isn't all that unusual. There are places in the world where the local carbon supply has long included a lot of geological carbon. These are mostly places with limestone under the soil. For example in the Valley of Mexico there's a well-understood problem with Aztec remains. The area is rich in limestone, and much of the ground water is high in CO2 from this source. This makes C-14 dating in the area very difficult, and C-14 dates aren't trusted without confirmation by other methods. There's a similar problem with dates in the Karst region in the Balkans. Any archaeologist here can probably rattle off a list of other such problematical areas.
The only bases in use in Earth DNA are Adenine, Cytosine, Guanine and Thymine (ACGT).
So why would you assume that people posting here only have Earth DNA?
Nope; I've never seen that screen. I do see a screen with
[!!] Partition disks
across the top. But it doesn't present me with the choise of erasing the disk. It only allows me to "Manually edit partition table" and "".
It just works.
Not here. I have a several-years-old Dell box with an old RH installed, wasn't using it for much, so I decided to try Ubuntu. It seemed to be installing ok (though it's hard to spot error messages when they scroll off the top too fast to read). But when it settled down, all I got was a brownish-green screen with a typical pointer arrowhead in the center. That's all. It doesn't respond to anything on the keyboard, and the mouse doesn't move the arrow.
This is with the "live" CD. I also tried the "install" CD. This did demo that the keyboard and mouse work with Ubuntu, as I could use both of them during the prelim parts of the install. I got as far as the part about partitioning the disk, and can't get past that. It insists that I partition the disk, but nothing it shows me makes any sense. No info about the disk that it wants partitioned, and no matter what I select, it just leads back to that first screen about disk partitioning. After a few times around each path back to that screen, I gave up.
I suspect that they could use some filling out in their online troubleshooting stuff. I don't seem to find anything saying what to do when it behaves the way I see.
One thing curious is its remark that it won't repartition if there's already a linux installed. There is one installed, the old RH system. But it keeps insisting that I do some sort of partitioning, and won't advance past that point, not even if I tell it to accept the partitions. That just bounces me back to the first page about partitioning.
Anyone have a pointer to clues about installing it over an existing linux installation? Any way to say "wipe the disk and start from scratch"?
is "best informed" defined as most closely folowing the democratic party?
Well, it's not defined that way, but that's semi-true.
The "semi-" is because the people who voted for the various smaller parties generally rated as even better-informed by just about any measure. The Democrats are better-informed only in comparison to Republicans. This is not what I'd call high praise.
Most of these surveys measured informedness by asking people questions about various candidates' policies. Depending on the questions asked, they came up with somewhat different numbers, of course. Mostly, they said that Republicans typically failed to answer any questions correctly around 70% to 80% of the time. Democrats typically got at least some correct answers around the same percentage. But the "third party" voters, regardless of party, typically got 90% or more of their answers right, for all the candidates.
Of course, I suppose one could bias the results by making up loaded questions. But if you look at the actual questions asked by the major pollsters, it's pretty clear that they took a "pox on both your houses" approach. It's not difficult to be equally "biased" against all candidates.