Simple. It'll become illegal to send random data. How about sending a JPEG of a Jackson Pollock painting? It sure looks like random data. (Pollock's usual method of creating "art" was to cover the floor with canvas, set a ladder in the middle of it, climb up with various colored paint cans, and fling paint.) But since some people will pay large sums for the original, it isn't random data and you could sue for false arrest.
Meanwhile, real terrorists will be sending the communications they need buried in innocuous-looking messages in the clear. Agree on a few code words at a face to face meeting, and then you can make all messages necessary for scheduling and coordination look like ordinary business communications -- e.g., send the target location, date, and time as the time and place for a meeting, an order for "staplers and staples" can refer to guns and ammo,...
Or if they really have to send an incriminating message, there are lots of ways to hide it in an innocuous message. E.g., insert a letter here and a letter there as "misspellings". Flip a few bits in an image or audio file -- if the recipient has an unmodified copy of the file, just do an XOR to recover the hidden message. Or if you want something really sophisticated, hire some underpaid Russian mathematician/programmer.
Or after a decade or two of this sort of sh*t, you'll be able to hire impoverished Americans instead...
I'm not sure I'm ready to tell those kids whose parents didn't come home last week that they and others down the road just have to suck it up because people may be unwilling -- even temporarily -- to lose any measure of privacy.
I'd say instead that thousands of lives were lost because most americans have been brainwashed out of defending themselves. The hijackers did not need sophisticated technology to plan this -- just face to face meetings, and a few agreed upon code words so the necessary phone or e-mail messages would sound like normal business planning. For example, "The big meeting is set for Sept 11."
But the really weak part of their plan was that they did NOT have a way to smuggle real weapons past airport security. Instead, they depended on being able to bluff the passengers and crew with pen-knives, box cutters, and a cardboard box. And the terrible thing is that on all four airplanes, this was sufficient to get the pilots to the rear of the airplane and their own guys in the driver's seat. There was a time in this country when someone who tried something like that would have been beaten unconscious with carry-on luggage -- if not shot by someone carrying a real weapon. But we've not only taken away the weapons, we've taught people not to defend themselves.
(1) Congress forces backdoors in all encryption, including that used for corporate trade secrets, banking, etc. (2) The best hacker owns the world -- and tells Bill Gates to get off of his property...;-)
What do you expect when you sort-of-elect a President that thinks there is too much freedom?
All of my servers scream via SNMP should the fans drop in RPM, increase in RPM, fail, stutter, and almost anything else that can go wrong with the hardware. Yeah, but how would an RPM detector know whether the fan is where it belongs or lying in the bottom of the case? 8-)
Seriously, you're smart to pay extra for good servers with lots of conditions monitored, but don't count on it to cover everything. You must also have something sensing the CPU temperature, but it wouldn't save the AMD chips if the heatsink falls off -- the CPU's heated up so fast that the one with an internal temperature sensor fried before the motherboard circuit could shut it down. SNMP would be even slower -- but if your system is slowing down or crashing because the fan died, it would probably tell you that.
Servers are a different case than desktop/home machines. I think servers are always "some assembly required", and I would hope that in the process of putting in your hard-drives, network interfaces, etc., you would take a glance at the CPU area. Desktop boxes are often sold to people who wouldn't understand what they are seeing even if they did open the case, and sometimes with warranty stickers where they get torn if you do open the case.
Yes, that's a wonderful example of "context sensitive advertising." Not the first time I've seen an article panning a product accompanied by advertising for the same product. I suspect many sites have software to scan the page for key words and select matching ads -- but Artificial Stupidity is nowhere near being good enough yet to tell whether it said good or bad things.
If they ran articles on the terrorist attacks of 9/11, would they be accompanied by ads for airlines and office space in the WTC?
The fundamental thing to understand about campaign finance laws is that they were invented by politicians to legalize some bribes by calling them "campaign contributions". They were never created to clean up politics -- simply prosecuting all cases of bribery would have done that! But as long as effective campaigning requires massive advertising budgets, we're stuck with some form of legalized bribery...
The other thing campaign finance laws accomplish is incumbent protection. Whatever they propose, it isn't going to cut into either the money received directly by most Congressmen, or the "soft" money that is funneled through the two major parties, but it will cut into the money available to run a third party or to challenge the candidate anointed by a major party in the primaries. (How else did we wind up with TWO such dweebs as the smirking chimp and Mr. Roger's evil twin?)
If it wasn't for that soft money, both parties might well be irrelevant by now. There are certainly wider divisions inside both parties than existed between the publicly claimed positions of Bush and Gore. (Their real positions differed more -- but they'll change at the drop of a corporate check.) As long as the parties hold the money taps, most politicians are going to stay in one line or the other. So that's what campaign laws are for: keep the money flowing to the established politicians, and see that the two big parties have enough monetary clout to prevent any real alternatives arising.
The attack could have been arranged without using any communications system more complex than plain old telephones, and without ever saying anything on the phone that wouldn't sound like ordinary family or business chatter. That is, you get the group together in some remote village in the Middle East, where CIA agents don't dare go because the locals know who doesn't belong. You agree on general plans, and a few simple and innocuous-sounding code words. Like, "The big meeting is set for 10:00 Sept 11. Get your tickets."
For an analogy: in 1941, the US Navy was decrypting practically everything the Japanese sent by coded radio, including instructions to their spies sent by diplomatic codes. We also knew that their gov't was getting very close to the point where they would _have_ to start a war with us, or else end their war in China, and probably kill themselves to apologize to the Japanese people for getting so far in over their heads. And we fully expected that they would start with a devastating surprise attack, just like in 1905.
What we didn't believe was that they would have to guts to strike so far away as Pearl Harbor. And so, three weeks before the attack when the Army and Navy sent out "war warning" messages, the general in charge of defending Hawaii "protected" his airplanes from possible sabotage by pulling them out of their camouflaged and somewhat protected shelters, lining them up in the middle of the airfield under guard, and de-fueled and de-armed them so if someone did manage to sneak in a bomb, the fire wouldn't spread. In other words, the planes were immobilized and lined up for easiest possible air attack. (For the record: there is NO evidence of traitorous action by any Japanese-American on American soil -- unlike the Germans and Italians.)
The Japanese Navy simply sent their carrier fleet to a remote location to practice for the strike, threw a cordon around so no one could leave, cut off all radio communications, allowed telephone calls (by land line inside Japan only) only for mission-critical needs and phrased so as not to give the mission away. Even if we had agents in the strike force itself (and this wasn't possible, for reasons which should be obvious), they wouldn't have been able to send a warning. Nor would a tap on the phone lines (also impossible) have revealed anything that wasn't already covered by the "war warnings."
There is no evidence at all that, if this bill could stop terrorists from using strong cryptography (it won't, since the necessary algorithms have been published, some of them 20 years ago), it would have made any difference to this attack. Nor are the heightened security precautions at airports likely to make a difference -- you think there still won't be ways to smuggle through razor blades? How about ceramic-bladed knives?
What will make a difference is people on board willing to fight back. On flight 93, it sounds like the passengers _did_ finally take back the airplane, but then couldn't get someone qualified back in the pilot's seat before it hit the ground. If they'd fought initially, rather than letting 3 men with little knives take over the cockpit first... But the government would much rather have completely disarmed sheeple than citizens who might decide to stand up for their rights.
You don't have to go through a security checkpoint again when you get off a plane and board a new one. You should.
They do that at Tokyo-Narita airport. So it takes 30 minutes to get from one airplane to another one waiting at the next gate. (And last time I was through there, very late at night, they _were_ literally waiting for me and about a dozen others -- the first plane took off two hours late, so the second one was held...)
Just what does this contribute to security? If the first security checkpoint did it's job, people getting off an airplane don't _have_ any weapons. If it didn't, why didn't the hijackers take over the first airplane?
It's really a matter of your boss's instincts. Unfortunately, most human instincts were formed back in the days when "management" consisted of taking a dozen guys armed with clubs and spears out into the jungle and grunting and pointing to get them into position surrounding their intended meat dish for dinner. And so if a modern manager can't SEE you working, he gets nervous about whether you really are. Hell, my boss wonders about what I'm doing when he's in his office with the door closed just 30 feet away...
In any case, happy employees == productive employees. Ask anyone in Personnel. A former "human resources" manager seemed to prefer unhappy employees who felt they had been screwed with broken promises, but were terrified of losing their jobs. Yes, firing him was probably the smartest move this company has made in a decade, but it hasn't yet restored it to profitability.
Working as a team isn't much of a barrier to telecommuting. I've worked in a team with engineers at our biggest customer, 400 miles away. You do NOT need to be in the same room for work-related communication, but you do have get to know the other people, so every few months we drive down there or they drive up here, for two days of working together, seeing the actual equipment involved, and (most important of all) just plain socializing.
The USA Today article keeps saying "patent" where it means "patent application." Patents are on public record. Patent applications are not, for the first 18 months (formerly forever in the US), because it would be idiotic to let the gov't publish your hot new technology, and then take a year or two to process the application and give you some protection against imitators.
"Submarine patent" refers to patent applications that were kept in limbo at the USPTO for a very long time by a stream of amendments and other maneuvers, then finally emerged with apparent claims to whole broad areas of technology. For instance, someone filed a patent application about 1960 for several transistors grown on one block of silicon, interconnected by wires soldered between transistors, instead of the then-usual procedure of sawing up the silicon into individual transistors. After 20-some years of amendments, this finally became a patent which claimed to cover _all_ integrated circuits, never mind that there is as much resemblance between the original invention and a modern IC as between a high-wheel bicycle and a modern automobile. But the "inventor" hoped to collect royalties from companies that felt it was cheaper to pay than to fight.
The things talked about in this article aren't submarine patents, but rather are patent applications that became patents in the normal time, but belonged to companies sitting on the committees writing standards concerning the technology in the applications. That's clearly a conflict of interest, and so standards committees usually require members to sign contracts to disclose related patents and patent applications, and to license them at set rates. The three companies are accused of breaching those contracts. Rambus (at least) is also accused of using the standards committee discussions to target technology to add to their patent claims.
The feds seem to be claiming that this breach of contract voids the patents. That might be too far of a stretch under the laws as written by Congress, but it's certainly justice, and the Constitutional clause authorizing Congress to pass patent laws ("To encourage the progress of science and the useful arts...", or something like that) would seem to require voiding a patent like Rambus's that was deliberately written to _impede_ the adoption of new technology.
Wrong. "Royal patents" existed long before the US -- but these were gained by political pull rather than set procedures, and were more likely to grant a monopoly on well-known processes than to protect innovations. Most people simply didn't recognize that inventions were valuable until the industrial revolution was well underway, that is, the latter half of the 18th century. (One exception might be military technology -- see for example Leonardo da Vinci's notebooks -- but no country has ever forgone useful weapons in war time just because they don't own the patents.)
It's possible that some other countries enacted patent laws before the Constitution allowing American patent laws took effect in the US (1793?), but we certainly weren't far behind anyone. We were way ahead of most European aristocrats, who in 1793 still thought that true wealth lay in vast tracts of farmland worked by downtrodden peasants...
How is it possible to keep a patent "secret?" The secrets here weren't patents, but patent applications. It's reasonable to keep applications secret for a limited time, since it takes two or three years for the USPTO to grant a patent, and meanwhile there is little legal protection for the technology.
However, if you want to sit on a standards committee, you probably have to sign a contract stating that you will disclose any pending applications concerning the area under discussion.
Aren't all patents part of the public record? Pretty much, although there must be an exception for military secrets. The problem is finding the patents actually related to what you are doing among tens of thousands of badly written patents with over-inflated claims.
While the standards were being set, the patent [application] was in the PTO, being kept secret.
Patents aren't secret. Patent applications are secret (for a limited time in Europe, or until a patent was granted under the old American system), because it's unreasonable to ask a company to expose it's new technology a year or two before the patent office grants it legal protection. But it's certainly abusive to join a standards committee without disclosing any pending patents covering items under discussion. Usually it's also a breach of contract.
According to news reports about the Rambus lawsuits, the abuse went far further than that. They would come back from a standards committee meeting and call their patent attorney to amend the claims in applications at the patent office to cover the technology that had just been discussed.
For all this data collected from all the surfers to a busy site, where on earth are they going to store it all for any length of time??
Duh. Most of the posts crying "invasion of privacy" have been far off the mark. This isn't technology for tracking individual users -- maybe it could do that, but recording every mouse movement individually would overload most servers. It's an attempt to collect stats on what parts of the page draws attention. Occasionally someone would use that to improve their web site. Mostly, advertisers are going to try to use it to find out if anyone even _looks_ at their ad. I don't think tracking mouse movements will do that too well, but in the absence of equipment to spot where your eyes are looking, they'll record the mouse movements and try to deduce something, then some dumb suits in marketing will take this faulty data as gospel.
And the real problem arises if this is actually accurate enough to reveal that no one looks at the ads... The first generation of spyware revealed that no one clicks on banner ads -- and millions of $ were pulled out of internet web sites and put into TV and magazine ads instead. No one looks at those either, but there is no way of showing just _how much_ we don't look at them. Improve the tools for measuring user interest in ads, and you are going to lose even more ad $...
The basic problem with them developing better tools to show how much we DON'T pay attention to the !@#$% ads is that it puts web sites at a disadvantage with respect to TV where the dumb suits paying a million $ a minute for ad time have no way of finding out that no one is watching.
Somebody mod the parent up please, it certainly deserves equal billing with my first post.
1994 was way too late for a Forth standard. ANSI C has at least a decades lead, and I think C was kept reasonably standard ever since its creation in the early 70's.
Somewhere in Moore's pages on colorForth it does say that the executable is tokenized source. Unless I misunderstood? Glad to hear that other compilers don't.
You might be right about programming traps and debugging -- most C and C++ projects never do get adequately debugged, so how could Forth be worse? But the big problem is that I can show a C program to an engineer that doesn't program, and he can read parts of it. Show him Forth, and it might as well be hexadecimal.
True, in the early days most programmers had degrees in a mathematical field (math, physics, engineering), and that certainly biased them towards the familiar-looking Fortran, Algol, and their descendants. But I think it's not just that the algebraic-type languages look more like the math you learned in school, but that algebraic notation went through centuries of evolution to become as easy for humans to read as possible.
Another factor is that Algol and its descendants visually break up the code more than Lisp and Forth usually do, making it easier to see the structure. (This depends on the programmer, of course -- anyone with a smidgen of artistic ability and any concern for those who must follow him can add white space to make any language look good. But the average hacker seems to be lacking in either artistry or concern for maintainability. I've even seen Pascal code run together until it was unreadable. But the varied grouping elements in C (parentheses and curly brackets) give it some visible structure even when the indentation is snafu'd. Lisps all-parentheses is harder to parse visually, and I've seen Forth programs presented as a single string with no breaks at all.)
Who is saying "what's Algol?" It was a structured language created by a committee of mathematicians around 1960, before anyone thought to call it "structured programming". It had most of the ideas you find in Pascal, C, Modula 2, and filtering back into the originally unstructured Fortran, cobol, and basic languages. It also had a lot of ideas which turned out to be either unimplementable or just plain bad. If you want to see just the good parts of Algol, learn Pascal.
It had blocks separated by begin and end, which allowed you to replace the single statement controlled by an if with a whole group of statements (C turned that into {} for faster typing), plus the whole nine yards of "structured" languages (while, for, etc.). For wasn't new, FORTRAN and COBOL already had equivalent loop statements, but using blocks instead some hokey syntax to delimit the loop was new. Algol might have been the first to make the variable names in a subroutine independent of the names in the main and other subroutines. It had rules for variable scope that only a mathematician could love -- e.g., you could define a function inside another function inside main, and it would have access to the outer function's and main's variables, besides having its own local variables. (C simplified this to each function having its own distinct set of variables, and blocks being allowed to have local variables plus inheriting the next level's.) It introduced:= for assignment, to distinguish this from = for comparison in an if statement. (C kept the single character = for the most common usage and == for the less common comparison operator.) It had several different ways to pass an argument to a function: call by value (C directly uses this only), call by reference (passing a pointer in C, but C++ brought back references in a more general way), and call by name. (Wirth, the Swiss creator of Pascal and Modula 2, is supposed to have explained how to pronounce his name by saying, "You can call me by name, "Veert", or you can call me by value "Worth". You never heard a professor of mathematics and computing tell a joke before?)
Call by Name seems to have been both hard to implement and a basically bad idea. Since a function could access the variables in the calling program, all the way up to the main program, the original language definition seems to say that a function could actually call a subordinate function that would change the invisibly change the value of the first function's argument, and if it was by name the first function should use the new value henceforth. Uhhg! The second edition of the standard (which I long ago discovered marked down to about 10 cents in hardcover and still have packed somewhere...), discussed this and various other language features that were impractical with the compiler technology of the time, but didn't actually say what to do about it. So I guess each compiler writer implemented a different subset of Algol. Fortran and Cobol maintained fairly good compatibility, Algol started out incompatible, so it died except as an inspiration to others.
In the 1970's, Wirth finally handled it right: he named his favorite Algol subset "Pascal" and pushed it as a standard language. But it didn't compete too well with the more hacker-friendly C. It told you when you f*d up and didn't let the program compile, while C just assumed you knew what you were doing... Borland gave a version of Pascal a new lease on life by writing remarkably fast compilers for it (after, I presume, changing whatever part of Wirth's standard made it slow to compile but mathematically correct) and selling them cheap, but it was still treated mainly as a toy language -- good for learning to program, but to do real work you used C which didn't complain when you did something odd with a pointer. Even though most of the time it was a mistake... But I don't think it's possible to write a hardware driver in Pascal, it will think your reads and writes to hardware are a mistake.
Chuck's CAD system used to design his processors is written in colorForth. That is really eating your own dogfood! I have some idea of what goes into writing a schematics and board layout CAD system from watching a couple of vendors struggle through the transition to GUI's. IC design is much harder. Amazing to see it done by one man. Can I download a copy somewhere?
Note that it wasn't used to design something equivalent to a Pentium. I think it was used to design a much simpler but not too slow CPU, and then replicate that 25 times with interconnections. And the user interface is often the hardest part of a program; Moore may have left that as simply a text console or something that takes a lot of work for anyone but the programmer to master. But still, I would think that to write a CAD program to do even that much well would take a a large programming team, and various routing algorithms that are held as trade secrets or patents by large corporations.
Mr. Moore, are the specs or a demo on the web somewhere?
why isn't Forth used more as a platform? Simple answer, it looks too darned weird. I sometimes do small embedded programs where Forth's tiny memory footprint would be advantageous, and it would be more than fast enough. But my boss isn't about to let me use it. He doesn't want to learn to read it, and if something happened to me, the nearest guy that could maintain Forth code might be 200 miles south of here...
Other reasons: It isn't advertised. It isn't standardized. (I doubt this matters much since it's pretty easy to add new words to any available Forth as needed to support a program from another dialect, but this sort of thing scares away managers who don't have time to listen to the details.) It allows you to do horrible things like writing a subroutine that removes too many or too few items from the stack. (Sort of like the horrible mistakes C programmers make with pointers, malloc and free, == vs =, etc, but we're talking about managerial perceptions again...) Some versions of Forth store your tokenized source code right in the executable program, so you can't protect your "trade secrets." RPN really is hard to work with, at least for me (with the early HP scientific calculators). But the basic reason is that it looks weird and this inclines people to find fault...
Follow the colorforth link to "early binding" and you'll see what Chuck Moore really values: tiny and fast. Portability, readability, ease of programming, and even ability of the program to handle unexpected inputs take second place to efficiency, according to Moore.
If you're programming a microprocessor controlled toaster, and will sell a million toasters, then using forth might let you use a $0.50 microcontroller instead of an $0.75 one, saving $250,000. That's certainly worth some extra programming effort. This is called "embedded programming". And, believe it or not, there are several guys coding the smallest scale embedded programs for every one coding PC and server operating systems and applications. (I suspect embedded programmers are grossly underrepresented in surveys, because most of them are EE's and also do circuit design, and so show up as design engineers rather than programmers. Likewise, few of the many people customizing databases to fit the needs of each and every corporation are called "programmers", although they do sort of code, and there are a heck of a lot of them.)
For bigger jobs, things are a bit different. I don't disagree with Moore's comments about bloatware, it's just that I think there's a middle ground between Win ME (a bloated program with a 20 year history during which nothing was ever taken out, including bugs), and tiny OS-less applications where the programmer sweated for each byte saved. And I think that for less than million-unit quantities, that middle ground is more cost-effective -- otherwise we'd all still be using assembly language, except for the Forth programmers. Apparently Forth can have a smaller memory footprint than good assembly; it's not going to run as fast, but there never have been many good assembly programmers, and Forth might beat poorly written assembly. At any rate, for toasters, washing machines, ATM's, and about 90% of the other 8-bit embedded systems, it doesn't matter because the thing being controlled is thousands of times slower than any reasonably written software.
I don't have experience working with Forth, but it looks like it would be much harder to work in than C, mainly because algebraic notation is much easier for humans to comprehend than reverse polish notation. (RPN is easier for computers to comprehend -- that's why the first scientific calculators used it, and why Forth is so compact.) In some respects, they have similar capabilities: they let you work on an extremely low level when you have to, and they let you make horrendous mistakes. (I can't imagine a compiler that would work for direct hardware control that didn't have those possibilities.) They also let you work at a higher level. It's claimed that Forth can go to a higher and more abstract level than C or even C++, and this might be true, but I don't see how I could ever program Forth without continually thinking about the stack, and I can shove the details into C functions and work at a pretty high level in C. C produces much larger machine code than Forth, but at the present prices of memory, working harder on the code to save memory takes something like 100,000 units sold to pay off. Forth is sort of interpreted, very quickly, while C is compiled into pretty fast machine code. C should be faster, but there's a lot more overhead to C so Forth would win sometimes. And of course, a good algorithm in a slow language beats a poor algorithm in expertly hand-tuned assembly -- will Forth's general weirdness make it harder to find an apply good algorithms?
Am I biased? Too many people merely like the first language they met, but I think I'm about as unbiased as it is possible to be while still having some experience: I first learned programming in FORTRAN and COBOL long before these languages were "structured", then BASIC, APL, assembly, many more dialects of BASIC and assembly, a little Pascal and LISP, C, and Labview. I'm not wedded to any particular paradigm of programming languages, not even to using the Roman alphabet, but I do have to admit that C resembles FORTRAN in several ways (algebraic notation, printf formatting, the simpler variable declarations), and Forth doesn't resemble anything at all.
One final thing note: Forth does seem like a great language for p-codes, that is, compiler output that is not machine code. P-code can be machine and OS independent, and protection against rogue code can be built into the interpreters. There's a performance loss, but since MS's bloated code has pushed everyone into buying ridiculously overpowered desktop boxes, does it matter?
Slashdot Mirror
Simple. It'll become illegal to send random data. How about sending a JPEG of a Jackson Pollock painting? It sure looks like random data. (Pollock's usual method of creating "art" was to cover the floor with canvas, set a ladder in the middle of it, climb up with various colored paint cans, and fling paint.) But since some people will pay large sums for the original, it isn't random data and you could sue for false arrest.
...
Meanwhile, real terrorists will be sending the communications they need buried in innocuous-looking messages in the clear. Agree on a few code words at a face to face meeting, and then you can make all messages necessary for scheduling and coordination look like ordinary business communications -- e.g., send the target location, date, and time as the time and place for a meeting, an order for "staplers and staples" can refer to guns and ammo,
Or if they really have to send an incriminating message, there are lots of ways to hide it in an innocuous message. E.g., insert a letter here and a letter there as "misspellings". Flip a few bits in an image or audio file -- if the recipient has an unmodified copy of the file, just do an XOR to recover the hidden message. Or if you want something really sophisticated, hire some underpaid Russian mathematician/programmer.
Or after a decade or two of this sort of sh*t, you'll be able to hire impoverished Americans instead...
I'm not sure I'm ready to tell those kids whose parents didn't come home last week that they and others down the road just have to suck it up because people may be unwilling -- even temporarily -- to lose any measure of privacy.
I'd say instead that thousands of lives were lost because most americans have been brainwashed out of defending themselves. The hijackers did not need sophisticated technology to plan this -- just face to face meetings, and a few agreed upon code words so the necessary phone or e-mail messages would sound like normal business planning. For example, "The big meeting is set for Sept 11."
But the really weak part of their plan was that they did NOT have a way to smuggle real weapons past airport security. Instead, they depended on being able to bluff the passengers and crew with pen-knives, box cutters, and a cardboard box. And the terrible thing is that on all four airplanes, this was sufficient to get the pilots to the rear of the airplane and their own guys in the driver's seat. There was a time in this country when someone who tried something like that would have been beaten unconscious with carry-on luggage -- if not shot by someone carrying a real weapon. But we've not only taken away the weapons, we've taught people not to defend themselves.
(1) Congress forces backdoors in all encryption, including that used for corporate trade secrets, banking, etc. (2) The best hacker owns the world -- and tells Bill Gates to get off of his property... ;-)
What do you expect when you sort-of-elect a President that thinks there is too much freedom?
All of my servers scream via SNMP should the fans drop in RPM, increase in RPM, fail, stutter, and almost anything else that can go wrong with the hardware. Yeah, but how would an RPM detector know whether the fan is where it belongs or lying in the bottom of the case? 8-)
Seriously, you're smart to pay extra for good servers with lots of conditions monitored, but don't count on it to cover everything. You must also have something sensing the CPU temperature, but it wouldn't save the AMD chips if the heatsink falls off -- the CPU's heated up so fast that the one with an internal temperature sensor fried before the motherboard circuit could shut it down. SNMP would be even slower -- but if your system is slowing down or crashing because the fan died, it would probably tell you that.
Servers are a different case than desktop/home machines. I think servers are always "some assembly required", and I would hope that in the process of putting in your hard-drives, network interfaces, etc., you would take a glance at the CPU area. Desktop boxes are often sold to people who wouldn't understand what they are seeing even if they did open the case, and sometimes with warranty stickers where they get torn if you do open the case.
Yes, that's a wonderful example of "context sensitive advertising." Not the first time I've seen an article panning a product accompanied by advertising for the same product. I suspect many sites have software to scan the page for key words and select matching ads -- but Artificial Stupidity is nowhere near being good enough yet to tell whether it said good or bad things.
If they ran articles on the terrorist attacks of 9/11, would they be accompanied by ads for airlines and office space in the WTC?
The fundamental thing to understand about campaign finance laws is that they were invented by politicians to legalize some bribes by calling them "campaign contributions". They were never created to clean up politics -- simply prosecuting all cases of bribery would have done that! But as long as effective campaigning requires massive advertising budgets, we're stuck with some form of legalized bribery...
The other thing campaign finance laws accomplish is incumbent protection. Whatever they propose, it isn't going to cut into either the money received directly by most Congressmen, or the "soft" money that is funneled through the two major parties, but it will cut into the money available to run a third party or to challenge the candidate anointed by a major party in the primaries. (How else did we wind up with TWO such dweebs as the smirking chimp and Mr. Roger's evil twin?)
If it wasn't for that soft money, both parties might well be irrelevant by now. There are certainly wider divisions inside both parties than existed between the publicly claimed positions of Bush and Gore. (Their real positions differed more -- but they'll change at the drop of a corporate check.) As long as the parties hold the money taps, most politicians are going to stay in one line or the other. So that's what campaign laws are for: keep the money flowing to the established politicians, and see that the two big parties have enough monetary clout to prevent any real alternatives arising.
The attack could have been arranged without using any communications system more complex than plain old telephones, and without ever saying anything on the phone that wouldn't sound like ordinary family or business chatter. That is, you get the group together in some remote village in the Middle East, where CIA agents don't dare go because the locals know who doesn't belong. You agree on general plans, and a few simple and innocuous-sounding code words. Like, "The big meeting is set for 10:00 Sept 11. Get your tickets."
For an analogy: in 1941, the US Navy was decrypting practically everything the Japanese sent by coded radio, including instructions to their spies sent by diplomatic codes. We also knew that their gov't was getting very close to the point where they would _have_ to start a war with us, or else end their war in China, and probably kill themselves to apologize to the Japanese people for getting so far in over their heads. And we fully expected that they would start with a devastating surprise attack, just like in 1905.
What we didn't believe was that they would have to guts to strike so far away as Pearl Harbor. And so, three weeks before the attack when the Army and Navy sent out "war warning" messages, the general in charge of defending Hawaii "protected" his airplanes from possible sabotage by pulling them out of their camouflaged and somewhat protected shelters, lining them up in the middle of the airfield under guard, and de-fueled and de-armed them so if someone did manage to sneak in a bomb, the fire wouldn't spread. In other words, the planes were immobilized and lined up for easiest possible air attack. (For the record: there is NO evidence of traitorous action by any Japanese-American on American soil -- unlike the Germans and Italians.)
The Japanese Navy simply sent their carrier fleet to a remote location to practice for the strike, threw a cordon around so no one could leave, cut off all radio communications, allowed telephone calls (by land line inside Japan only) only for mission-critical needs and phrased so as not to give the mission away. Even if we had agents in the strike force itself (and this wasn't possible, for reasons which should be obvious), they wouldn't have been able to send a warning. Nor would a tap on the phone lines (also impossible) have revealed anything that wasn't already covered by the "war warnings."
There is no evidence at all that, if this bill could stop terrorists from using strong cryptography (it won't, since the necessary algorithms have been published, some of them 20 years ago), it would have made any difference to this attack. Nor are the heightened security precautions at airports likely to make a difference -- you think there still won't be ways to smuggle through razor blades? How about ceramic-bladed knives?
What will make a difference is people on board willing to fight back. On flight 93, it sounds like the passengers _did_ finally take back the airplane, but then couldn't get someone qualified back in the pilot's seat before it hit the ground. If they'd fought initially, rather than letting 3 men with little knives take over the cockpit first... But the government would much rather have completely disarmed sheeple than citizens who might decide to stand up for their rights.
You don't have to go through a security checkpoint again when you get off a plane and board a new one. You should.
They do that at Tokyo-Narita airport. So it takes 30 minutes to get from one airplane to another one waiting at the next gate. (And last time I was through there, very late at night, they _were_ literally waiting for me and about a dozen others -- the first plane took off two hours late, so the second one was held...)
Just what does this contribute to security? If the first security checkpoint did it's job, people getting off an airplane don't _have_ any weapons. If it didn't, why didn't the hijackers take over the first airplane?
It's really a matter of your boss's instincts. Unfortunately, most human instincts were formed back in the days when "management" consisted of taking a dozen guys armed with clubs and spears out into the jungle and grunting and pointing to get them into position surrounding their intended meat dish for dinner. And so if a modern manager can't SEE you working, he gets nervous about whether you really are. Hell, my boss wonders about what I'm doing when he's in his office with the door closed just 30 feet away...
You do need face time. You don't need it everyday. I know, I've worked on a team with engineers 400 miles away.
In any case, happy employees == productive employees. Ask anyone in Personnel. A former "human resources" manager seemed to prefer unhappy employees who felt they had been screwed with broken promises, but were terrified of losing their jobs. Yes, firing him was probably the smartest move this company has made in a decade, but it hasn't yet restored it to profitability.
Working as a team isn't much of a barrier to telecommuting. I've worked in a team with engineers at our biggest customer, 400 miles away. You do NOT need to be in the same room for work-related communication, but you do have get to know the other people, so every few months we drive down there or they drive up here, for two days of working together, seeing the actual equipment involved, and (most important of all) just plain socializing.
Forgot to say: "submarine patent" was not in the USA Today article, but is a mistake by the slashdot headline writer.
The USA Today article keeps saying "patent" where it means "patent application." Patents are on public record. Patent applications are not, for the first 18 months (formerly forever in the US), because it would be idiotic to let the gov't publish your hot new technology, and then take a year or two to process the application and give you some protection against imitators.
"Submarine patent" refers to patent applications that were kept in limbo at the USPTO for a very long time by a stream of amendments and other maneuvers, then finally emerged with apparent claims to whole broad areas of technology. For instance, someone filed a patent application about 1960 for several transistors grown on one block of silicon, interconnected by wires soldered between transistors, instead of the then-usual procedure of sawing up the silicon into individual transistors. After 20-some years of amendments, this finally became a patent which claimed to cover _all_ integrated circuits, never mind that there is as much resemblance between the original invention and a modern IC as between a high-wheel bicycle and a modern automobile. But the "inventor" hoped to collect royalties from companies that felt it was cheaper to pay than to fight.
The things talked about in this article aren't submarine patents, but rather are patent applications that became patents in the normal time, but belonged to companies sitting on the committees writing standards concerning the technology in the applications. That's clearly a conflict of interest, and so standards committees usually require members to sign contracts to disclose related patents and patent applications, and to license them at set rates. The three companies are accused of breaching those contracts. Rambus (at least) is also accused of using the standards committee discussions to target technology to add to their patent claims.
The feds seem to be claiming that this breach of contract voids the patents. That might be too far of a stretch under the laws as written by Congress, but it's certainly justice, and the Constitutional clause authorizing Congress to pass patent laws ("To encourage the progress of science and the useful arts...", or something like that) would seem to require voiding a patent like Rambus's that was deliberately written to _impede_ the adoption of new technology.
Patent law existed long before the US.
Wrong. "Royal patents" existed long before the US -- but these were gained by political pull rather than set procedures, and were more likely to grant a monopoly on well-known processes than to protect innovations. Most people simply didn't recognize that inventions were valuable until the industrial revolution was well underway, that is, the latter half of the 18th century. (One exception might be military technology -- see for example Leonardo da Vinci's notebooks -- but no country has ever forgone useful weapons in war time just because they don't own the patents.)
It's possible that some other countries enacted patent laws before the Constitution allowing American patent laws took effect in the US (1793?), but we certainly weren't far behind anyone. We were way ahead of most European aristocrats, who in 1793 still thought that true wealth lay in vast tracts of farmland worked by downtrodden peasants...
How is it possible to keep a patent "secret?" The secrets here weren't patents, but patent applications. It's reasonable to keep applications secret for a limited time, since it takes two or three years for the USPTO to grant a patent, and meanwhile there is little legal protection for the technology.
However, if you want to sit on a standards committee, you probably have to sign a contract stating that you will disclose any pending applications concerning the area under discussion.
Aren't all patents part of the public record? Pretty much, although there must be an exception for military secrets. The problem is finding the patents actually related to what you are doing among tens of thousands of badly written patents with over-inflated claims.
While the standards were being set, the patent [application] was in the PTO, being kept secret.
Patents aren't secret. Patent applications are secret (for a limited time in Europe, or until a patent was granted under the old American system), because it's unreasonable to ask a company to expose it's new technology a year or two before the patent office grants it legal protection. But it's certainly abusive to join a standards committee without disclosing any pending patents covering items under discussion. Usually it's also a breach of contract.
According to news reports about the Rambus lawsuits, the abuse went far further than that. They would come back from a standards committee meeting and call their patent attorney to amend the claims in applications at the patent office to cover the technology that had just been discussed.
For all this data collected from all the surfers to a busy site, where on earth are they going to store it all for any length of time??
Duh. Most of the posts crying "invasion of privacy" have been far off the mark. This isn't technology for tracking individual users -- maybe it could do that, but recording every mouse movement individually would overload most servers. It's an attempt to collect stats on what parts of the page draws attention. Occasionally someone would use that to improve their web site. Mostly, advertisers are going to try to use it to find out if anyone even _looks_ at their ad. I don't think tracking mouse movements will do that too well, but in the absence of equipment to spot where your eyes are looking, they'll record the mouse movements and try to deduce something, then some dumb suits in marketing will take this faulty data as gospel.
And the real problem arises if this is actually accurate enough to reveal that no one looks at the ads... The first generation of spyware revealed that no one clicks on banner ads -- and millions of $ were pulled out of internet web sites and put into TV and magazine ads instead. No one looks at those either, but there is no way of showing just _how much_ we don't look at them. Improve the tools for measuring user interest in ads, and you are going to lose even more ad $...
The basic problem with them developing better tools to show how much we DON'T pay attention to the !@#$% ads is that it puts web sites at a disadvantage with respect to TV where the dumb suits paying a million $ a minute for ad time have no way of finding out that no one is watching.
Somebody mod the parent up please, it certainly deserves equal billing with my first post.
1994 was way too late for a Forth standard. ANSI C has at least a decades lead, and I think C was kept reasonably standard ever since its creation in the early 70's.
Somewhere in Moore's pages on colorForth it does say that the executable is tokenized source. Unless I misunderstood? Glad to hear that other compilers don't.
You might be right about programming traps and debugging -- most C and C++ projects never do get adequately debugged, so how could Forth be worse? But the big problem is that I can show a C program to an engineer that doesn't program, and he can read parts of it. Show him Forth, and it might as well be hexadecimal.
True, in the early days most programmers had degrees in a mathematical field (math, physics, engineering), and that certainly biased them towards the familiar-looking Fortran, Algol, and their descendants. But I think it's not just that the algebraic-type languages look more like the math you learned in school, but that algebraic notation went through centuries of evolution to become as easy for humans to read as possible.
:= for assignment, to distinguish this from = for comparison in an if statement. (C kept the single character = for the most common usage and == for the less common comparison operator.) It had several different ways to pass an argument to a function: call by value (C directly uses this only), call by reference (passing a pointer in C, but C++ brought back references in a more general way), and call by name. (Wirth, the Swiss creator of Pascal and Modula 2, is supposed to have explained how to pronounce his name by saying, "You can call me by name, "Veert", or you can call me by value "Worth". You never heard a professor of mathematics and computing tell a joke before?)
Another factor is that Algol and its descendants visually break up the code more than Lisp and Forth usually do, making it easier to see the structure. (This depends on the programmer, of course -- anyone with a smidgen of artistic ability and any concern for those who must follow him can add white space to make any language look good. But the average hacker seems to be lacking in either artistry or concern for maintainability. I've even seen Pascal code run together until it was unreadable. But the varied grouping elements in C (parentheses and curly brackets) give it some visible structure even when the indentation is snafu'd. Lisps all-parentheses is harder to parse visually, and I've seen Forth programs presented as a single string with no breaks at all.)
Who is saying "what's Algol?" It was a structured language created by a committee of mathematicians around 1960, before anyone thought to call it "structured programming". It had most of the ideas you find in Pascal, C, Modula 2, and filtering back into the originally unstructured Fortran, cobol, and basic languages. It also had a lot of ideas which turned out to be either unimplementable or just plain bad. If you want to see just the good parts of Algol, learn Pascal.
It had blocks separated by begin and end, which allowed you to replace the single statement controlled by an if with a whole group of statements (C turned that into {} for faster typing), plus the whole nine yards of "structured" languages (while, for, etc.). For wasn't new, FORTRAN and COBOL already had equivalent loop statements, but using blocks instead some hokey syntax to delimit the loop was new. Algol might have been the first to make the variable names in a subroutine independent of the names in the main and other subroutines. It had rules for variable scope that only a mathematician could love -- e.g., you could define a function inside another function inside main, and it would have access to the outer function's and main's variables, besides having its own local variables. (C simplified this to each function having its own distinct set of variables, and blocks being allowed to have local variables plus inheriting the next level's.) It introduced
Call by Name seems to have been both hard to implement and a basically bad idea. Since a function could access the variables in the calling program, all the way up to the main program, the original language definition seems to say that a function could actually call a subordinate function that would change the invisibly change the value of the first function's argument, and if it was by name the first function should use the new value henceforth. Uhhg! The second edition of the standard (which I long ago discovered marked down to about 10 cents in hardcover and still have packed somewhere...), discussed this and various other language features that were impractical with the compiler technology of the time, but didn't actually say what to do about it. So I guess each compiler writer implemented a different subset of Algol. Fortran and Cobol maintained fairly good compatibility, Algol started out incompatible, so it died except as an inspiration to others.
In the 1970's, Wirth finally handled it right: he named his favorite Algol subset "Pascal" and pushed it as a standard language. But it didn't compete too well with the more hacker-friendly C. It told you when you f*d up and didn't let the program compile, while C just assumed you knew what you were doing... Borland gave a version of Pascal a new lease on life by writing remarkably fast compilers for it (after, I presume, changing whatever part of Wirth's standard made it slow to compile but mathematically correct) and selling them cheap, but it was still treated mainly as a toy language -- good for learning to program, but to do real work you used C which didn't complain when you did something odd with a pointer. Even though most of the time it was a mistake... But I don't think it's possible to write a hardware driver in Pascal, it will think your reads and writes to hardware are a mistake.
Chuck's CAD system used to design his processors is written in colorForth. That is really eating your own dogfood! I have some idea of what goes into writing a schematics and board layout CAD system from watching a couple of vendors struggle through the transition to GUI's. IC design is much harder. Amazing to see it done by one man. Can I download a copy somewhere?
Note that it wasn't used to design something equivalent to a Pentium. I think it was used to design a much simpler but not too slow CPU, and then replicate that 25 times with interconnections. And the user interface is often the hardest part of a program; Moore may have left that as simply a text console or something that takes a lot of work for anyone but the programmer to master. But still, I would think that to write a CAD program to do even that much well would take a a large programming team, and various routing algorithms that are held as trade secrets or patents by large corporations.
Mr. Moore, are the specs or a demo on the web somewhere?
why isn't Forth used more as a platform? Simple answer, it looks too darned weird. I sometimes do small embedded programs where Forth's tiny memory footprint would be advantageous, and it would be more than fast enough. But my boss isn't about to let me use it. He doesn't want to learn to read it, and if something happened to me, the nearest guy that could maintain Forth code might be 200 miles south of here...
Other reasons: It isn't advertised. It isn't standardized. (I doubt this matters much since it's pretty easy to add new words to any available Forth as needed to support a program from another dialect, but this sort of thing scares away managers who don't have time to listen to the details.) It allows you to do horrible things like writing a subroutine that removes too many or too few items from the stack. (Sort of like the horrible mistakes C programmers make with pointers, malloc and free, == vs =, etc, but we're talking about managerial perceptions again...) Some versions of Forth store your tokenized source code right in the executable program, so you can't protect your "trade secrets." RPN really is hard to work with, at least for me (with the early HP scientific calculators). But the basic reason is that it looks weird and this inclines people to find fault...
Follow the colorforth link to "early binding" and you'll see what Chuck Moore really values: tiny and fast. Portability, readability, ease of programming, and even ability of the program to handle unexpected inputs take second place to efficiency, according to Moore.
If you're programming a microprocessor controlled toaster, and will sell a million toasters, then using forth might let you use a $0.50 microcontroller instead of an $0.75 one, saving $250,000. That's certainly worth some extra programming effort. This is called "embedded programming". And, believe it or not, there are several guys coding the smallest scale embedded programs for every one coding PC and server operating systems and applications. (I suspect embedded programmers are grossly underrepresented in surveys, because most of them are EE's and also do circuit design, and so show up as design engineers rather than programmers. Likewise, few of the many people customizing databases to fit the needs of each and every corporation are called "programmers", although they do sort of code, and there are a heck of a lot of them.)
For bigger jobs, things are a bit different. I don't disagree with Moore's comments about bloatware, it's just that I think there's a middle ground between Win ME (a bloated program with a 20 year history during which nothing was ever taken out, including bugs), and tiny OS-less applications where the programmer sweated for each byte saved. And I think that for less than million-unit quantities, that middle ground is more cost-effective -- otherwise we'd all still be using assembly language, except for the Forth programmers. Apparently Forth can have a smaller memory footprint than good assembly; it's not going to run as fast, but there never have been many good assembly programmers, and Forth might beat poorly written assembly. At any rate, for toasters, washing machines, ATM's, and about 90% of the other 8-bit embedded systems, it doesn't matter because the thing being controlled is thousands of times slower than any reasonably written software.
I don't have experience working with Forth, but it looks like it would be much harder to work in than C, mainly because algebraic notation is much easier for humans to comprehend than reverse polish notation. (RPN is easier for computers to comprehend -- that's why the first scientific calculators used it, and why Forth is so compact.) In some respects, they have similar capabilities: they let you work on an extremely low level when you have to, and they let you make horrendous mistakes. (I can't imagine a compiler that would work for direct hardware control that didn't have those possibilities.) They also let you work at a higher level. It's claimed that Forth can go to a higher and more abstract level than C or even C++, and this might be true, but I don't see how I could ever program Forth without continually thinking about the stack, and I can shove the details into C functions and work at a pretty high level in C. C produces much larger machine code than Forth, but at the present prices of memory, working harder on the code to save memory takes something like 100,000 units sold to pay off. Forth is sort of interpreted, very quickly, while C is compiled into pretty fast machine code. C should be faster, but there's a lot more overhead to C so Forth would win sometimes. And of course, a good algorithm in a slow language beats a poor algorithm in expertly hand-tuned assembly -- will Forth's general weirdness make it harder to find an apply good algorithms?
Am I biased? Too many people merely like the first language they met, but I think I'm about as unbiased as it is possible to be while still having some experience: I first learned programming in FORTRAN and COBOL long before these languages were "structured", then BASIC, APL, assembly, many more dialects of BASIC and assembly, a little Pascal and LISP, C, and Labview. I'm not wedded to any particular paradigm of programming languages, not even to using the Roman alphabet, but I do have to admit that C resembles FORTRAN in several ways (algebraic notation, printf formatting, the simpler variable declarations), and Forth doesn't resemble anything at all.
One final thing note: Forth does seem like a great language for p-codes, that is, compiler output that is not machine code. P-code can be machine and OS independent, and protection against rogue code can be built into the interpreters. There's a performance loss, but since MS's bloated code has pushed everyone into buying ridiculously overpowered desktop boxes, does it matter?