They put down BSD 4.3 just so they wouldn't get flamed into eternity. But they didn't know the real reason why UNIX (not BSD 4.3 in particular) was so significant. It was the first OS written in a high level language, which was designed to write an operating system (prior to this point operating systems were written in assembly language for speed).
Thank you for playing. Our hostess has a fine parting gift for you as you leave. If you return, please remember to always phrase your answer in the form of a question.
The correct question for: "Tbe first operating sytem written in a high level language" was: "What was MULTICS?"
On a whim, the judges decided that PL/I and BLISS both sucked, and The C Programming Language openly states that C isn't really a high level language, so they would also accept "What was the Lilith?"
Of course, the first truly high level language was Trebecktran, used to write the OS for me, the Trebecktron 9000!
If you're dealing with amounts of cents that could possibly start overflowing even a 32-bit int (that is, billions of cents, or tens of millions of dollars), then the application's important enough to be worth the cost of further research on the matter.
...especially when you can find roughly 10 gazillion alternative for about $1 worth of research time.
Unfortunately, most of the obvious alternatives are either somewhat restrictive, or have relatively poor performance. For example, on a 64-bit machine, a 64-bit integer works quite nicely -- but of course, most people aren't (yet) using 64-bit machines. There are quite a few arbitrary precision integer packages available, but most of them are substantially slower than a float or a double for most calculations.
Unfortunately, quite a bit of calculation with money really will run into problems with being stored in a 32-bit integer. If you're dealing strictly with US currency, you're right: the problem only arises with quite large amounts of money. OTOH, if you have to deal with international currency, the problem can (and will) arise far sooner. Just for a couple obvious examples, there are around 27 Russian Kopecks or about 39 Zambian Kwacha to one US penny. Even inside of the US, some things have prices that include fractions of a cent (e.g. Gasoline often has.9 cents tacked onto the end of its price, and some stock/bond/commodities markets use prices in eights of a cent).
In a lot of cases, the best alternative to using floating point is to use floating point. No, that's not a typo. What you want to do is store an integer number of pennies -- but store it in a double (or on ocassion, a long double). A typical implementation of double can also be used as a 53-bit integer type. A 32-bit number is right on the edge where it's often usable, but can easily run into problems. A 53-bit integer makes those problems much more remote -- to the point that by the time you're dealing with such a large amount of money, you probably don't want to know about pennies anymore. A long double will store a 20 digit integer -- so it should be usable even for something like figuring the stock dividend of a large company.
As long as you're careful about order of calculation and when you do rounding, this gives the added bonus of working nicely for things like converting one currency to another, that are relatively difficult to do with pure integers.
Reading this got me to thinking about a slightly different point -- one that's been niggling at the back of my mind for a while, but I haven't seen discussed much. Maybe that's just because to everybody else it's just to obvious to mention though...
It seems to me that computers are progressively becoming less and less about computing, and more and more about simply storing and communicating data. A long time ago, IBM bought out Lotus software. Lotus became famous based on 1-2-3. It was the "killer app" that sold tons of DOS machines -- and oriented heavily toward doing computation. I'm not sure if IBM even still sells 1-2-3 or anything derived from it -- the big Lotus-derived products are Notes and Domino (I.e. storing and communicating data, not doing actual computing). In fact, you hardly hear about spreadsheets any more. Excel works, and a lot of people use it, but it doesn't seem to be a "killer app" for much of anybody anymore -- I'm pretty sure I haven't heard of anybody buying a machine to run it (or any other spreadsheet) in years.
Now acquisitions (and new development) seem to be oriented almost entirely toward storing and communicating data, not toward doing any actual computing. The same seems to be happening in software development as well. Languages for doing real computation, like FORTRAN and Matlab are almost universally seen as boring and passe. Even languages like C++ oriented kind of halfway toward computation seem to be viewed as a whole less less than exciting, anyway. What's hot are things like Ruby on Rails. Of course, you can write computational code in Ruby if you want to, but I'm pretty sure nearly nobody uses Ruby to do things like matrix multiplication -- they use it for Rails, to set up web sites that talk to databases (storing and communicating data).
In fairness, I suppose I should add that there are still a few "big things" oriented heavily toward real computation -- Folding@home and Seti@home for a couple of obvious ones -- and BOINC has a number of less obvious/well-known ones as well. Clearly computation isn't entirely dead and gone or anything like that.
I'm a little uncertain what this emphasis on simply storing and communicating data really means though. Was most computing that involved real computation really just a fad, and people were doing it primarily because it was new and different? Is the current emphasis on data storage and communication really just a fad, and people will care a lot less about it in a few years? Is it a matter of the "computing" parts of things mostly being cured problems, so they're less apparent, even though they're really as important as ever?
I suppose for this to be a proper comment, I should have a strong opinion to express about it, but I really don't -- at least for me it's almost entirely an open question.
..or maybe Sun copied it from Microsoft, who'd been using it in VB for years, and in QuickBASIC for years before that. MS even had a C/C++ compiler that produced stack-based P-code (MS C/C++ 7.0, the immediate predecessor to VC++ 1.0). QuickPascal (short-lived though it was) also used stack-based P-code.
Of course, none of this is anywhere close to original with either MS or Sun. The very first Pascal compiler produced stack-based P-Code which was then interpreted by a virtual machine.
Getting back to the original subject of TFA, I'm afraid the poster was letting his enthusiasm get the better of him. Stack-based machines have one fairly fundamental problem: they make extremely heavy usage of a few registers at the very top of the stack. Nearly every instruction depends on those registers. Modern CPUs attempt to execute a number of instructions in parallel. They do this (in large part) by keeping track of dependencies between instructions -- e.g. when a value used as the input to one instruction is the value produced by a previous instruction.
Now, when you have a number of registers you can use interchangeably, you do you best to cycle through them to produce values in different registers before using them in subsequent instructions. The instructions that don't directly depend on each other can be executed in parallel. Most modern processors can theoretically produce around 3 or 4 results per clock, and most actually DO produce close to 2 result per clock as a general rule.
A stack-based processor makes this substantially more difficult. Most of the advantages result from the fact that most instructions have implicit sources and an implicit destination (e.g. an ADD instruction takes the two items at the top of the stack, adds them together, and desposits the result back on the top of the stack).
This means a few registers near the top of the stack are used almost constantly, and nearly every instruction depends on them. It's possible to break this dependency by using register renaming. For example, if you have something like:
lod a
lod b
add
lod c
lod d
mul
sub
sto x
[equivalent to: x = (a+b)-(c*d) ]
You can break the dependency by internally allocating a number of different registers that will each act as the top of the stack at different times. Each time you load a value, you allocate a new register for it, independent of the previous top of stack register. Internally, the processor can figure out that the code above is equivalent to:
lod R0, a
lod R1, b
add R0, R1
lod R2, c
lod R3, d
mul R2, R3
sub R0, R2
sto X
But even a minimal look at that reveals something pretty obvious: you no longer have a stack-based CPU at all -- you're really using a perfectly normal register-based CPU.
This is largely why stack-based architectures are so popular in virtual machines and such. On one hand, they abstract out most of the details that vary between different CPUs, such as the number of registers. OTOH, it's generally quite easy to execute stack-based code efficiently on a register-based CPU.
There might be an advantage to this being done internally in the CPU though. The most obvious would be that insructions that instructions that need to specify sources and destinations are larger than instructions that use implicit sources and destinations. That means teh CPU is reading data from memory that it could pretty easily figure out on its own. Given the large (and increasing) disparity between memory speed and processor speed, this could be a real improvement.
The question is though (having not RTFA yet): will this work on Linux, and what boards offer four PCI-E x16 slots?
I can't say one way or the other about Linux (yet). You don't need four PCI-E x16 slots though. This is based around the nVidia 7950 GX2, which connects two graphics processors to the motherboard via a single PCI-E slot. Each of those takes up two slots worth of space (in fact,it's two boards connected together) but the high-end single-GPU boards (e.g. 7900GTX, ATI X1900) do so as well. Most SLI motherboards leave quite a bit of room between their x16 slots, so the physical installation should rarely (if ever) cause a problem.
In case anybody cares: apparently during development, they did build a few dual-GPU boards that required two slots -- but they were never put into real production.
> Fortunately the US is not installing the great firewall.
[... ]
> Sadly, other countries like China are.
US companies are providing the technology and know-how, but hey, "let the market decide".
Presumably that was meant more or less sarcastically. The question I'd ask is whether you can figure out a way of providing only technology that can't be abused in such ways (and yes, IMO, the great firewall of China is an outright abuse of the technology). While it's applied to a much larger number of computers and a much wider variety of subject matter, I don't see a lot of difference in the basic technology or know-how involved in the great firewall of China than in quite a few perfectly legitimate corporate firewalls and such.
The difference is primarily in the application of the technology and know-how, not in the technology itself. Is there any real difference between my filter that knows "viagra" is a bad thing and theirs that knows "tianamen square" instead?
And to answer the obvious question: yes, I'd even give up my spam filer if it meant the whole world would have unrestricted communication. Somehow I doubt that's going to happen though...
IMHO, The central server stucture is the way to go. The entity that owns the central server(s) can concentrate security on those server(s) and thus provide verification that you download what you wanted.
There's no need for a single central server for this purpose. If anything, a really big site becomes enough of a headache to manage at all that in a lot of cases, there seems to be nobody who understands its overall structure well enough to be at all sure they've provided even minimally adequate security. If you want a secure system, keep it small and simple.
With P2P, you never know what you are going to get until you run the file, and it's harder to track for liscensing purposes and the like.
Nonsense. It's trivial to provide a secure hash of a file so the receiver can verify that they've received what was originally intended. A P2P protocol could carry out such verification automatically. If memory serves, BitTorrent (for one example) already does this automatically.
Tracking for licensing purposes doesn't require a centralized server either. We're looking at updating a database, but a distributed database (about which, see more below) is a perfectly reasonable way to do that. The simple fact is that most people writing P2P simply haven't been interested in such things; rather the opposite, side-stepping licensing issues and such seems to have been one of the major attractions of P2P for many.
You can also track payments and such easier with a central server structure.
Distributed database technology has been around for decades. In fact, even when you're working with something that looks like a single central server, in a lot of cases it's really distributed across a number of machines for redundancy. Putting those machines next to each other makes it a lot cheaper to wire fast communication between them, but when you get down to it, there isn't much fundamental difference between two blades in the same server and two servers that live on different continents.
P2P has been shown to be faster in some applications, but with people getting faster and faster connections to the internet, the speed advantage is going to be less in the future.
Here you've got things exactly backwards. When/if all those people with fast connections try to talk to a single central server, that central server needs bandwidth that's roughly the aggregate of all its simultaneous users to be able to keep up. As more people get faster connections, it becomes increasingly difficult for that central server to keep up with the whole load.
OTOH, most of those fast connections are currently only used at anywhere close to their full bandwidth a small fraction of the time. The rest of the time they could just as well be acting as servers to provide information for others. This allows those fast connections to bear the load rather than just imposing it on others.
I'd like to know why it is that there are 4 bars right before I dial, and only 2 bars (or worse) right after I hit the SEND button. This has happened to me multiple times.
Obviously you're driving by the bars when you decide to dial. Your phone is trying to tell you to stop in and have a drink instead of just driving by. It won't make your phone work any better, but it'll help you realize the futility of caring about it.:-)
"But it seems Parexel, despite having the moral responsibilty [sic] for the outcome of its incompetence
It would be incompetence if they had released the drug to market, or at least attempted to. The whole point of clinical testing is to look for problems like this that couldn't be predicted, and did not turn up in animal testing.
If the allegations are true, that there was little or no delay between injecting the test subjects, then Parexel does seem (at least to me) to have conducted the test in a grossly incompetent fashion.
My own take on things is that TeGenero should be held partially responsible for the problems experienced by the first victim to have been injected. To the extent that the adverse reactions were reasonably foreseeable, Parexel should have had contingency plans in place to deal with them. To the extent that they didn't, they should bear financial responsibility (e.g. for pain and suffering experienced by the victim between the time that treatment should have been given, and the time it actually was given). If quicker adminstration of proper treatment would have prevented some or all of the long-term damage, they should also bear responsibility for that damage. The damage that would have happened even if the test had been carried out correctly should be born by TeGenero.
All of the damages to the second and subsequent victims should be born entirely by Parexel. If Parexel had administered the tests in anything even vaguely resembling a competent fashion, nothing whatsoever would have happened to these people, because they never would have been injected at all.
In a situation like this (Parexel has a lot of money and TeGenero has essentially none) it's tempting to simply say the Parexel should be held responsible for all the damages, and be done with it. IMO, that's a mistake. It's clear that they caused some of the problems, and should be held responsible for what they did. At least to me, it seems equally clear that they didn't cause all the problems by any means, and should not be held responsible for those problems that they really didn't cause. It would be downright wrong to hold them financially responsible for problems they didn't cause just because they're able to afford the cost.
As an aside: I don't know about the law in Great Britain, but in the US, if a court finds that a provision in a contract is unconscionable, the court is allowed to void that provision of the contract. IMO, this provision should be voided for exactly that reason -- and if local law doesn't allow the court to do so, it bloody well should.
I wonder if OS X 10.5 was going to have such a feature and it leaked out. This is actually a quasi-innovative idea from Microsoft. Maybe they stole it from Apple via corporate spying.
Microsoft got this one much more directly. Windows NT started out as basically the next version of VMS, designed and written almost entirely by former DECies (one rumor has it that the "NT" came from taking VMS and adding one to each letter to get WNT...) VMS has had a feature like this for years. It predates not only OS/X, but the Macintosh in general. I can remember using in about 1981 or so -- I don't remember for sure, but VMS 3 is what sticks in my mind -- and I don't think it was new then (it seemed pretty cool to me after dealing with Control Data mainframes, but the people who'd been using VMS longer didn't seem to think of it as new or exciting).
They probably have another "secret" base to do this work from.
You seem to be talking about Schriever Air Force Base. Interestingly, this is also pretty close by. According to TFA, one of the reasons for the move is the commute between Peterson and Cheyenne Mountain. From Peterson to Cheyenne Mountain is a fairly ugly drive directly through Colorado Springs (the end of that route isn't quite right, but Mapquest doesn't seem to know exactly where the entrance to NORAD is. By contrast, from Peterson to Schriever is almost entirely through open country with minimal traffic.
You can probably find some good satellite photos on Google.
You hardly need satellite photos. I'd guess some people living near the Broadmoor can probably see traffic in and out of the mountain with nothing more than binoculars or maybe a small telescope at most. OTOH, there's not really much to see -- almost everything is underground, and about all you can see from the outside is the entrance to a tunnel into the mountain. About all you'd see from a satellite photo would be a road that disappears into the side of a mountain with a LOT of antennas on top (though a lot of them belong to the local radio stations, TV stations, Sprint Broadband, etc.)
This isn't an all-purpose petaflop computer (ie. can't be used for protein folding calculations, thermonuclear explosion simulations, weather and climate prediction, etc...).
Actually, it probably could be used in protein folding -- but not the others.
The first real petaflop computer will be built by Cray and up and running in about 2 years.
Maybe -- but IBM has at least talked about a Blue Gene/P (P for petaFLOP). I haven't seen much about it recently, so it may be open to some question. OTOH, IBM now has enough presence in supercomputers that I'd have to call it a credible possibility.
OTOH, Cray's use of reconfigurable computing could make theirs applicable to a wider variety of problems -- if IBM builds a BG/P, it'll probably be pretty similar to a larger version of the BG/L, which means a HUGE number of processors. Nobody gets this kind of speed from a single processor, but Cray does it with far fewer than most (though Hitachi clearly wins in this respect). The real challenge with most of these huge machines is figuring out how to distribute the job across lots of CPUs. Fewer, faster, CPUs makes that easier and (somewhat) less necessary.
For those who aren't aware of it, reconfigurable computing means Cray has boxes that include some big Xilinx FPGAs, which it can use to create custom hardware. For bits and pieces that can benefit from massive parallelization, this can provide considerable improvement. It gives more or less the kind of special-purpose capability discussed in TFA, BUT can be reconfigured to have more or less that kind of capability for a lot of different purposes.
This may sound like we're back to a general-purpose computer, with the same shortcomings as usual -- and to an extent that's exactly true. The difference is that you're reconfiguring the hardware instead of doing things in software. The result is a compromise between the two extremes. Slower and less power efficient than an ASIC, but faster and more power efficient than software. Developing a particular capability for an FPGA is generally slower and more expensive than equivalent software, but faster than cheaper than developing an equivalent ASIC.
This whole article is like comparing the rendering capabilities of your new Nvidia GPU and the latest AMD CPU, then concluding AMD is full of idiots who can't engineer because the Nvidia chip renders more polygons.
...and now we know the real reason AMD decided to buy ATI!:-)
Is it actually cheaper to run large programs like SETI@HOME on a supercomputer?
This computer is efficient at what it does largely because it's extremely specialized. It's built specifically for working on molecular dynamics, but from the looks of things, it's probably close to useless for nearly anything else.
As such, it would probably work quite nicely for Stanford's folding@home project (which studies protein folding, i.e. molecular dynamics). It probably would not work very well for seti@home, because SETI isn't studying molecular dynamics, and it would probably be difficult to cast the problems they're working on into a form that would "look" enough like molecular dynamics to work well on this machine (this, BTW, is why this machine probably shouldn't go onto the top500 list or anything like that -- it's really not a general purpose computer at all).
As far as using other supercomputers for these kinds of jobs, here's what the folding@home FAQ has to say about it (from the F@H FAQ):
Why not just use a supercomputer? Modern supercomputers are essentially clusters of hundreds of processors linked by fast networking. The speed of these processors is comparable to (and often slower than) those found in PCs! Thus, if an algorithm (like ours) does not need the fast networking, it will run just as fast on a supercluster as a supercomputer. However, our application needs not the hundreds of processors found in modern supercomputers, but hundreds of thousands of processors. Hence, the calculations performed on Folding@Home would not be possible by any other means! Moreover, even if we were given exclusive access to all of the supercomputers in the world, we would still have fewer cycles than we do with the Folding@Home cluster! This is possible since PC processors are now very fast and there are hundreds of millions of PCs sitting idle in the world.
To put that into perspective, consider that the Blue Gene/L has 65536 processors. seti@home has over a million hosts and folding@home has a couple hundred thousand more. As the quote above notes, most supercomputers aren't drastically faster on a per-processor basis than PCs -- not nearly enough to make up this deficiency in sheer number of processors.
My guess is that the Blue Gene/L is probably somewhat more power efficient than the average contributor to seti@home or folding@home -- but mostly because the majority of the latter are probably Pentium 4's, which are notoriously inefficient in terms of power usage. As the world transitions away from the Netbust architecture, it's nearly certain that the efficiency of seti@home, folding@home, etc., will go up (considerably).
That brings up another point worth considering: the way things are right now, the computers used for seti@home, folding@home, BOINC, etc., get updated on quite a regular basis. If they spent millions of dollars for a single fast machine, it would might be more efficient right now -- but in a few years it would fall behind the curve -- but most budget committees (and such) would be reluctant to spend millions of dollars to replace it simply because something better was available.
While this will almost certainly be a complete flop in terms of preventing malware from patching the kernel, it may still be a good thing for people's security.
By far the best thing that could happen to the security of Windows would be if everybody forgot the personal firewalls, Norton Virus, etc., and used external boxes for these purposes. By the time anything running inside of Windows has a chance to try to do the job, it's too late. Windows is extremely large and complex, with myriad routes from almost any place to any other. Once malicious code is on the machine, it's too late to be at all certain you can prevent it from doing its dirty work.
Nonsense? Keep in mind that Quantum computing can do an expontial amount of work per step. So the doubling of the problem space size requires one additonal qubit to operate over all extra space and does so in a single operation.
With the best algorithms known at the present time, searching an unsorted set is O(N) on a classical computer, and O(sqrt(N)) on a quantum computer. That means the key needs to be twice as long to give (roughly) the same number of steps. Right now, actual speed is harder to guess, since there's no such thing as a practical quantum computer yet.
Maybe you should read up on what you're talking about before you call 'Nonsense';)
Since he invented most of the relevant algorithms, perhaps you'd be so kind as to point out what part of which of Peter Schor's papers you think I missed (or misunderstood)?
One more step to kissing NP Complete good bye, and one more step to invalidating all current forms of encryption.
Nonsense. First of all, nobody's really figured out much of a way to apply quantum computers to symmetric encryption, only to most public key cryptography. There are some ideas around that the fast database lookup you can do with a quantum computer should translate to some way to break symmetric encryption faster, but most current algorithms support long enough keys to combat that already. From the viewpoint of exhausting the key space (i.e. a brute force attack) using a conventional computer, there's basically no point in a key size large than 128 bits (or even a bit less than that). Most current algorithms, however, support at least 256 bits.
Keep in mind that the difficulty of key exhaustion is exponential with respect to key size. IOW, adding one bit to the key size doubles the difficulty of key exhaustion. Adding 128 bits multiplies the difficulty by 2^128.
Hardly seems fair to compare different browsers based on beta builds.
Three points: First, which generates more revenue - fairness or page hits?
Second, by the time some products are released, everybody who cares has been using it routinly for months or (in a few cases) even years anyway.
Third, in a lot of cases, it's hard to tell the difference between beta and released software anyway. Let's have a quick show of hands of all the people who believe that IE 7 will have been officially released for an entire month before a major security hole is found. Hmm...I'm not seeing any hands...and I don't think the fact that I can't see any of you really makes much difference in that.
The only real advantage to adding in "unused" octaves is in order to transmit overtones.
I'm pretty sure his point is that it's only one more octave. What the phone companies consider an "ideal" response for a telephone line is a bandwidth from about 180 Hz to 3-4 KHz or so, with a signal to noise ratio of about 45 dB. That means an ideal POTS line starts with about 4.5 octaves of bandwidth, and this increases that to about 5.5 instead. IOW, even though it doubles the maximum frequency, the perceived change is only about 20-25% at most.
In reality it'll usually be less than that. The perceived quality is reduced only to the extent that the original signal started out with energy in that region. Take a look at a spectrum analysis of a voice. This is a recording of a woman (more or less) singing a scale. The highest note is the last one, so let's look at it (though you'll see there's relatively little difference between them). What you're looking for is the graph titled: "This is the eighth utterance." The highest peaks are at about -20 dB. There's only one peak at or above 4 KHz that goes above -50 dB, meaning the signal is at least 30 dB down at that point. By 8 KHz, the signal has dropped even further, to around -65 dB, or about 45 dB below the primary signal -- and the energy drops still further above that point.
That means, even if the normal POTS line actually transmitted signal at higher frequencies, it would be almost entirely buried in noise anyway, unless they also reduced noise levels. It turns out that while low noise levels are generally good, on a phone most people don't like it much.
In fact, on a current phone syste, much of the noise is there intentionally. To maximize bandwidth, especially over the long distance networks, they compress the signals, and when the compressor detects a time that nothing is being said, instead of transmitting compressed noise, it transmits a more compact signal saying there's no real signal right now. On the receiving end, they respond to this by synthesizing and injecting what they call "comfort noise". Without this, many people think the call has been dropped, because it sounds like it has "gone dead".
In case anybody wonders: I talked about 4 KHz and 8 KHz instead of 8 KHz and 16 KHz. The 8 and 16 KHz are the _sampling_ rates. A guy named Nyquist long ago theorized that to sample a signal meaningfully, you have to sample at a frequency at least double that of the signal itself. On the decoding side, you have to do some filtering, and in the process you normally lose at least a little bit of the bandwidth near the limit, so an 8 KHz sampling rate means the theoretical maximum signal is 4 KHz, but in reality it'll normally be a little less than that.
This is one of the most intelligent comments in this thread. If the article is correct, it's pretty clear that the FBI isn't even making an attempt at following basic rules of security that have been well known since long before the FBI even existed...
You seem to have missed the point. Yes, there would be some innovation without a patent system -- RSA might have been developed if there were no patents, but it might well have taken many more years before it happened. And yes, that's a case in point. A quick review of public key cryptography might reveal why I think that.
PK in general was originally invented by one of the British spy agencies (CESG, if memory serves). They invented analogs to both Diffie-Hellman key exchange, and to RSA encryption. They didn't see it as particularly useful for their work, so they didn't do much with it, but they kept the work secret, so nobody else did anything with it either. Nothing happened at all.
Then (years later), Diffie and Hellman worked out their key exchange protocol. They patented and published it. Almost immediately, the entire field nearly exploded -- half a dozen more forms of public key cryptography were invented (and half of them broken, of course). Among those was RSA -- but if D-H hadn't patented and published theirs first, I doubt RSA would have been invented, at least when and how it was. Somebody else might have eventually come up with the same thing -- or, if nothing else, the earlier British work might have come to public notice and somebody would have recognized its usefulness.
OTOH, that really is an "eventually" kind of thing. Admittedly, it's impossible to say what would have happened under different circumstances; it's possible that even without a patent system, Diffie and Hellman would have published their work. It's possible that without Diffie and Hellman's prior work, Rivest, Shamir and Adelman would have gotten together and developed RSA anyway -- but I doubt it. My own guess is that if there wasn't a patent system, "ecommerce" would only be a typo, not a business model.
It's an insult to humanity to say that patents are the only way people can share their ideas to improve their surroundings.
I've never heard anybody say they're the only way. Quite a few different methods have been tried, however, and patents do appear to be one of the most effective. If, however, you look at the systems that were in place before patents came into use, they were mostly aimed at confining knowledge, not sharing it. There's pretty solid historical evidence that under the old guild system, people were sometimes killed for having revealed the guild's secrets. In fact, engineering books today are chock full of knowledge that was once carefully guarded from public disclosure.
Right now, innovation is hindered, rather than prepeled, by patents, because at the current rate, it can only be stopped by legal ways such as patents. There is enough incentive to develop all kinds of stuff, even if you don't get a monopoly on production.
There would undoubtedly be some innovation without a patent system. Personally, however, I'm reasonably convinced that there wouldn't be nearly as much. Much of this would be due to inventions not being published.
As far as HTTP and autoconf go: neither one would probably qualify for a patent in the first place. To patent something, you need to invent something. Offhand, I can't think of much about either one that looks truly inventive. It's hard to imagine anybody attempting to put something as innovative as public key encryption into the same bin with something as mundane as HTTP or autoconf.
And then the big companies will lobby to have patents extended, just like copyrights.
The first US patent law was passed in 1790, and gave a term of 14 years with the possibility of a 7 year extension. In 1836, the possibility of an extension was removed, and the original term was extended to 17 years. It stayed at 17 years until 1995.
Up to that point, the term of a patent was measured from the time the patent was granted. In 1995, the law was changed so the term of a patent is measured from the time the patent is filed instead. Since it typically takes around 3 years for a patent to be granted, they changed the coverage to be 20 years from when the patent is filed. This change gets rid of a few abuses some people used to keep patents in the system for years (decades, in some cases) to extend their coverage far beyond what was ever really intended.
This gives some minimal extension to a few patents that are granted relatively quickly. OTOH, it shortens the term of patents that take longer to be granted. There's also a special provision for drug patents to have their coverage extended in case the patent would be expired (or nearly so) before the FDA approved its sale.
All in all, there's been little overall change. Some patents granted under the current law will probably get a couple of years more than they would have under the 1790 law, but there are almost certainly other patents that get less. I don't know for sure, but I suspect that on average, patents now expire a bit sooner than they did at that time.
See them in court if they try to get around my patent 3404987:
I know this was meant to be funny, but it brings out a frequently ignored point. The real patent number 3404987 expired in 1985. What it covered (a food preservative) was the exclusive property of Procter and Gamble for a while, but it's now in the public domain, so anybody can use it. Furthermore, the patent gives anybody who cares directions about exactly what it is, how to make it, and how to use it.
The point is that patents expire, and when they do, whatever they covered becomes public domain, guaranteed to be usable by anybody. Furthermore, they often disclose more than they actually covered -- and whatever they disclose is public domain as well.
For quite a while, the patent office didn't accept applications for patents on software at all. That meant (among other things) that when they did start to accept such patents, it was hard to see the benefit because no such patent was going to expire for a long time, and it often looked like they'd all be obsolete long before they expired. That's clearly not the case. There are now quite a few expired patents on truly useful things. Obvious examples include LZW compression and RSA encryption.
Right now we're seeing an explosion in the number of patents on what we currently consider high-tech inventions. These, however, are starting to expire. Somewhere on the order of 1000 patents expire every week -- and that number is rising. In a few years, we can expect to see a couple of thousand inventions come into the public domain every week -- and they'll all include directions about how to build them, put them to use, etc. Without the patent system, or something very similar to it, we could not expect such a thing to happen.
Slashdot Mirror
Thank you for playing. Our hostess has a fine parting gift for you as you leave. If you return, please remember to always phrase your answer in the form of a question.
The correct question for: "Tbe first operating sytem written in a high level language" was: "What was MULTICS?"
On a whim, the judges decided that PL/I and BLISS both sucked, and The C Programming Language openly states that C isn't really a high level language, so they would also accept "What was the Lilith?"
Of course, the first truly high level language was Trebecktran, used to write the OS for me, the Trebecktron 9000!
Unfortunately, most of the obvious alternatives are either somewhat restrictive, or have relatively poor performance. For example, on a 64-bit machine, a 64-bit integer works quite nicely -- but of course, most people aren't (yet) using 64-bit machines. There are quite a few arbitrary precision integer packages available, but most of them are substantially slower than a float or a double for most calculations.
Unfortunately, quite a bit of calculation with money really will run into problems with being stored in a 32-bit integer. If you're dealing strictly with US currency, you're right: the problem only arises with quite large amounts of money. OTOH, if you have to deal with international currency, the problem can (and will) arise far sooner. Just for a couple obvious examples, there are around 27 Russian Kopecks or about 39 Zambian Kwacha to one US penny. Even inside of the US, some things have prices that include fractions of a cent (e.g. Gasoline often has .9 cents tacked onto the end of its price, and some stock/bond/commodities markets use prices in eights of a cent).
In a lot of cases, the best alternative to using floating point is to use floating point. No, that's not a typo. What you want to do is store an integer number of pennies -- but store it in a double (or on ocassion, a long double). A typical implementation of double can also be used as a 53-bit integer type. A 32-bit number is right on the edge where it's often usable, but can easily run into problems. A 53-bit integer makes those problems much more remote -- to the point that by the time you're dealing with such a large amount of money, you probably don't want to know about pennies anymore. A long double will store a 20 digit integer -- so it should be usable even for something like figuring the stock dividend of a large company.
As long as you're careful about order of calculation and when you do rounding, this gives the added bonus of working nicely for things like converting one currency to another, that are relatively difficult to do with pure integers.
It seems to me that computers are progressively becoming less and less about computing, and more and more about simply storing and communicating data. A long time ago, IBM bought out Lotus software. Lotus became famous based on 1-2-3. It was the "killer app" that sold tons of DOS machines -- and oriented heavily toward doing computation. I'm not sure if IBM even still sells 1-2-3 or anything derived from it -- the big Lotus-derived products are Notes and Domino (I.e. storing and communicating data, not doing actual computing). In fact, you hardly hear about spreadsheets any more. Excel works, and a lot of people use it, but it doesn't seem to be a "killer app" for much of anybody anymore -- I'm pretty sure I haven't heard of anybody buying a machine to run it (or any other spreadsheet) in years.
Now acquisitions (and new development) seem to be oriented almost entirely toward storing and communicating data, not toward doing any actual computing. The same seems to be happening in software development as well. Languages for doing real computation, like FORTRAN and Matlab are almost universally seen as boring and passe. Even languages like C++ oriented kind of halfway toward computation seem to be viewed as a whole less less than exciting, anyway. What's hot are things like Ruby on Rails. Of course, you can write computational code in Ruby if you want to, but I'm pretty sure nearly nobody uses Ruby to do things like matrix multiplication -- they use it for Rails, to set up web sites that talk to databases (storing and communicating data).
In fairness, I suppose I should add that there are still a few "big things" oriented heavily toward real computation -- Folding@home and Seti@home for a couple of obvious ones -- and BOINC has a number of less obvious/well-known ones as well. Clearly computation isn't entirely dead and gone or anything like that.
I'm a little uncertain what this emphasis on simply storing and communicating data really means though. Was most computing that involved real computation really just a fad, and people were doing it primarily because it was new and different? Is the current emphasis on data storage and communication really just a fad, and people will care a lot less about it in a few years? Is it a matter of the "computing" parts of things mostly being cured problems, so they're less apparent, even though they're really as important as ever?
I suppose for this to be a proper comment, I should have a strong opinion to express about it, but I really don't -- at least for me it's almost entirely an open question.
Of course, none of this is anywhere close to original with either MS or Sun. The very first Pascal compiler produced stack-based P-Code which was then interpreted by a virtual machine.
Getting back to the original subject of TFA, I'm afraid the poster was letting his enthusiasm get the better of him. Stack-based machines have one fairly fundamental problem: they make extremely heavy usage of a few registers at the very top of the stack. Nearly every instruction depends on those registers. Modern CPUs attempt to execute a number of instructions in parallel. They do this (in large part) by keeping track of dependencies between instructions -- e.g. when a value used as the input to one instruction is the value produced by a previous instruction.
Now, when you have a number of registers you can use interchangeably, you do you best to cycle through them to produce values in different registers before using them in subsequent instructions. The instructions that don't directly depend on each other can be executed in parallel. Most modern processors can theoretically produce around 3 or 4 results per clock, and most actually DO produce close to 2 result per clock as a general rule.
A stack-based processor makes this substantially more difficult. Most of the advantages result from the fact that most instructions have implicit sources and an implicit destination (e.g. an ADD instruction takes the two items at the top of the stack, adds them together, and desposits the result back on the top of the stack).
This means a few registers near the top of the stack are used almost constantly, and nearly every instruction depends on them. It's possible to break this dependency by using register renaming. For example, if you have something like:
lod a
lod b
add
lod c
lod d
mul
sub
sto x
[equivalent to: x = (a+b)-(c*d) ]
You can break the dependency by internally allocating a number of different registers that will each act as the top of the stack at different times. Each time you load a value, you allocate a new register for it, independent of the previous top of stack register. Internally, the processor can figure out that the code above is equivalent to:
lod R0, a
lod R1, b
add R0, R1
lod R2, c
lod R3, d
mul R2, R3
sub R0, R2
sto X
But even a minimal look at that reveals something pretty obvious: you no longer have a stack-based CPU at all -- you're really using a perfectly normal register-based CPU.
This is largely why stack-based architectures are so popular in virtual machines and such. On one hand, they abstract out most of the details that vary between different CPUs, such as the number of registers. OTOH, it's generally quite easy to execute stack-based code efficiently on a register-based CPU.
There might be an advantage to this being done internally in the CPU though. The most obvious would be that insructions that instructions that need to specify sources and destinations are larger than instructions that use implicit sources and destinations. That means teh CPU is reading data from memory that it could pretty easily figure out on its own. Given the large (and increasing) disparity between memory speed and processor speed, this could be a real improvement.
I can't say one way or the other about Linux (yet). You don't need four PCI-E x16 slots though. This is based around the nVidia 7950 GX2, which connects two graphics processors to the motherboard via a single PCI-E slot. Each of those takes up two slots worth of space (in fact,it's two boards connected together) but the high-end single-GPU boards (e.g. 7900GTX, ATI X1900) do so as well. Most SLI motherboards leave quite a bit of room between their x16 slots, so the physical installation should rarely (if ever) cause a problem.
In case anybody cares: apparently during development, they did build a few dual-GPU boards that required two slots -- but they were never put into real production.
Presumably that was meant more or less sarcastically. The question I'd ask is whether you can figure out a way of providing only technology that can't be abused in such ways (and yes, IMO, the great firewall of China is an outright abuse of the technology). While it's applied to a much larger number of computers and a much wider variety of subject matter, I don't see a lot of difference in the basic technology or know-how involved in the great firewall of China than in quite a few perfectly legitimate corporate firewalls and such.
The difference is primarily in the application of the technology and know-how, not in the technology itself. Is there any real difference between my filter that knows "viagra" is a bad thing and theirs that knows "tianamen square" instead?
And to answer the obvious question: yes, I'd even give up my spam filer if it meant the whole world would have unrestricted communication. Somehow I doubt that's going to happen though...
There's no need for a single central server for this purpose. If anything, a really big site becomes enough of a headache to manage at all that in a lot of cases, there seems to be nobody who understands its overall structure well enough to be at all sure they've provided even minimally adequate security. If you want a secure system, keep it small and simple.
Nonsense. It's trivial to provide a secure hash of a file so the receiver can verify that they've received what was originally intended. A P2P protocol could carry out such verification automatically. If memory serves, BitTorrent (for one example) already does this automatically.
Tracking for licensing purposes doesn't require a centralized server either. We're looking at updating a database, but a distributed database (about which, see more below) is a perfectly reasonable way to do that. The simple fact is that most people writing P2P simply haven't been interested in such things; rather the opposite, side-stepping licensing issues and such seems to have been one of the major attractions of P2P for many.
Distributed database technology has been around for decades. In fact, even when you're working with something that looks like a single central server, in a lot of cases it's really distributed across a number of machines for redundancy. Putting those machines next to each other makes it a lot cheaper to wire fast communication between them, but when you get down to it, there isn't much fundamental difference between two blades in the same server and two servers that live on different continents.
Here you've got things exactly backwards. When/if all those people with fast connections try to talk to a single central server, that central server needs bandwidth that's roughly the aggregate of all its simultaneous users to be able to keep up. As more people get faster connections, it becomes increasingly difficult for that central server to keep up with the whole load.
OTOH, most of those fast connections are currently only used at anywhere close to their full bandwidth a small fraction of the time. The rest of the time they could just as well be acting as servers to provide information for others. This allows those fast connections to bear the load rather than just imposing it on others.
Obviously you're driving by the bars when you decide to dial. Your phone is trying to tell you to stop in and have a drink instead of just driving by. It won't make your phone work any better, but it'll help you realize the futility of caring about it. :-)
If the allegations are true, that there was little or no delay between injecting the test subjects, then Parexel does seem (at least to me) to have conducted the test in a grossly incompetent fashion.
My own take on things is that TeGenero should be held partially responsible for the problems experienced by the first victim to have been injected. To the extent that the adverse reactions were reasonably foreseeable, Parexel should have had contingency plans in place to deal with them. To the extent that they didn't, they should bear financial responsibility (e.g. for pain and suffering experienced by the victim between the time that treatment should have been given, and the time it actually was given). If quicker adminstration of proper treatment would have prevented some or all of the long-term damage, they should also bear responsibility for that damage. The damage that would have happened even if the test had been carried out correctly should be born by TeGenero.
All of the damages to the second and subsequent victims should be born entirely by Parexel. If Parexel had administered the tests in anything even vaguely resembling a competent fashion, nothing whatsoever would have happened to these people, because they never would have been injected at all.
In a situation like this (Parexel has a lot of money and TeGenero has essentially none) it's tempting to simply say the Parexel should be held responsible for all the damages, and be done with it. IMO, that's a mistake. It's clear that they caused some of the problems, and should be held responsible for what they did. At least to me, it seems equally clear that they didn't cause all the problems by any means, and should not be held responsible for those problems that they really didn't cause. It would be downright wrong to hold them financially responsible for problems they didn't cause just because they're able to afford the cost.
As an aside: I don't know about the law in Great Britain, but in the US, if a court finds that a provision in a contract is unconscionable, the court is allowed to void that provision of the contract. IMO, this provision should be voided for exactly that reason -- and if local law doesn't allow the court to do so, it bloody well should.
Microsoft got this one much more directly. Windows NT started out as basically the next version of VMS, designed and written almost entirely by former DECies (one rumor has it that the "NT" came from taking VMS and adding one to each letter to get WNT...) VMS has had a feature like this for years. It predates not only OS/X, but the Macintosh in general. I can remember using in about 1981 or so -- I don't remember for sure, but VMS 3 is what sticks in my mind -- and I don't think it was new then (it seemed pretty cool to me after dealing with Control Data mainframes, but the people who'd been using VMS longer didn't seem to think of it as new or exciting).
You seem to be talking about Schriever Air Force Base. Interestingly, this is also pretty close by. According to TFA, one of the reasons for the move is the commute between Peterson and Cheyenne Mountain. From Peterson to Cheyenne Mountain is a fairly ugly drive directly through Colorado Springs (the end of that route isn't quite right, but Mapquest doesn't seem to know exactly where the entrance to NORAD is. By contrast, from Peterson to Schriever is almost entirely through open country with minimal traffic.
You hardly need satellite photos. I'd guess some people living near the Broadmoor can probably see traffic in and out of the mountain with nothing more than binoculars or maybe a small telescope at most. OTOH, there's not really much to see -- almost everything is underground, and about all you can see from the outside is the entrance to a tunnel into the mountain. About all you'd see from a satellite photo would be a road that disappears into the side of a mountain with a LOT of antennas on top (though a lot of them belong to the local radio stations, TV stations, Sprint Broadband, etc.)
Ah, I wasn't aware of that -- I mentioned SET primarily because the OP did. My own spare cycles all go to F@H...
Quite true -- and IMO, likely to remain that way (and thus, my decision about where to contribute...)
Actually, it probably could be used in protein folding -- but not the others.
Maybe -- but IBM has at least talked about a Blue Gene/P (P for petaFLOP). I haven't seen much about it recently, so it may be open to some question. OTOH, IBM now has enough presence in supercomputers that I'd have to call it a credible possibility.OTOH, Cray's use of reconfigurable computing could make theirs applicable to a wider variety of problems -- if IBM builds a BG/P, it'll probably be pretty similar to a larger version of the BG/L, which means a HUGE number of processors. Nobody gets this kind of speed from a single processor, but Cray does it with far fewer than most (though Hitachi clearly wins in this respect). The real challenge with most of these huge machines is figuring out how to distribute the job across lots of CPUs. Fewer, faster, CPUs makes that easier and (somewhat) less necessary.
For those who aren't aware of it, reconfigurable computing means Cray has boxes that include some big Xilinx FPGAs, which it can use to create custom hardware. For bits and pieces that can benefit from massive parallelization, this can provide considerable improvement. It gives more or less the kind of special-purpose capability discussed in TFA, BUT can be reconfigured to have more or less that kind of capability for a lot of different purposes.
This may sound like we're back to a general-purpose computer, with the same shortcomings as usual -- and to an extent that's exactly true. The difference is that you're reconfiguring the hardware instead of doing things in software. The result is a compromise between the two extremes. Slower and less power efficient than an ASIC, but faster and more power efficient than software. Developing a particular capability for an FPGA is generally slower and more expensive than equivalent software, but faster than cheaper than developing an equivalent ASIC.
As such, it would probably work quite nicely for Stanford's folding@home project (which studies protein folding, i.e. molecular dynamics). It probably would not work very well for seti@home, because SETI isn't studying molecular dynamics, and it would probably be difficult to cast the problems they're working on into a form that would "look" enough like molecular dynamics to work well on this machine (this, BTW, is why this machine probably shouldn't go onto the top500 list or anything like that -- it's really not a general purpose computer at all).
As far as using other supercomputers for these kinds of jobs, here's what the folding@home FAQ has to say about it (from the F@H FAQ):
To put that into perspective, consider that the Blue Gene/L has 65536 processors. seti@home has over a million hosts and folding@home has a couple hundred thousand more. As the quote above notes, most supercomputers aren't drastically faster on a per-processor basis than PCs -- not nearly enough to make up this deficiency in sheer number of processors.
My guess is that the Blue Gene/L is probably somewhat more power efficient than the average contributor to seti@home or folding@home -- but mostly because the majority of the latter are probably Pentium 4's, which are notoriously inefficient in terms of power usage. As the world transitions away from the Netbust architecture, it's nearly certain that the efficiency of seti@home, folding@home, etc., will go up (considerably).
That brings up another point worth considering: the way things are right now, the computers used for seti@home, folding@home, BOINC, etc., get updated on quite a regular basis. If they spent millions of dollars for a single fast machine, it would might be more efficient right now -- but in a few years it would fall behind the curve -- but most budget committees (and such) would be reluctant to spend millions of dollars to replace it simply because something better was available.
By far the best thing that could happen to the security of Windows would be if everybody forgot the personal firewalls, Norton Virus, etc., and used external boxes for these purposes. By the time anything running inside of Windows has a chance to try to do the job, it's too late. Windows is extremely large and complex, with myriad routes from almost any place to any other. Once malicious code is on the machine, it's too late to be at all certain you can prevent it from doing its dirty work.
With the best algorithms known at the present time, searching an unsorted set is O(N) on a classical computer, and O(sqrt(N)) on a quantum computer. That means the key needs to be twice as long to give (roughly) the same number of steps. Right now, actual speed is harder to guess, since there's no such thing as a practical quantum computer yet.
Since he invented most of the relevant algorithms, perhaps you'd be so kind as to point out what part of which of Peter Schor's papers you think I missed (or misunderstood)?
Nonsense. First of all, nobody's really figured out much of a way to apply quantum computers to symmetric encryption, only to most public key cryptography. There are some ideas around that the fast database lookup you can do with a quantum computer should translate to some way to break symmetric encryption faster, but most current algorithms support long enough keys to combat that already. From the viewpoint of exhausting the key space (i.e. a brute force attack) using a conventional computer, there's basically no point in a key size large than 128 bits (or even a bit less than that). Most current algorithms, however, support at least 256 bits.
Keep in mind that the difficulty of key exhaustion is exponential with respect to key size. IOW, adding one bit to the key size doubles the difficulty of key exhaustion. Adding 128 bits multiplies the difficulty by 2^128.
Three points: First, which generates more revenue - fairness or page hits?
Second, by the time some products are released, everybody who cares has been using it routinly for months or (in a few cases) even years anyway.
Third, in a lot of cases, it's hard to tell the difference between beta and released software anyway. Let's have a quick show of hands of all the people who believe that IE 7 will have been officially released for an entire month before a major security hole is found. Hmm...I'm not seeing any hands...and I don't think the fact that I can't see any of you really makes much difference in that.
I'm pretty sure his point is that it's only one more octave. What the phone companies consider an "ideal" response for a telephone line is a bandwidth from about 180 Hz to 3-4 KHz or so, with a signal to noise ratio of about 45 dB. That means an ideal POTS line starts with about 4.5 octaves of bandwidth, and this increases that to about 5.5 instead. IOW, even though it doubles the maximum frequency, the perceived change is only about 20-25% at most.
In reality it'll usually be less than that. The perceived quality is reduced only to the extent that the original signal started out with energy in that region. Take a look at a spectrum analysis of a voice. This is a recording of a woman (more or less) singing a scale. The highest note is the last one, so let's look at it (though you'll see there's relatively little difference between them). What you're looking for is the graph titled: "This is the eighth utterance." The highest peaks are at about -20 dB. There's only one peak at or above 4 KHz that goes above -50 dB, meaning the signal is at least 30 dB down at that point. By 8 KHz, the signal has dropped even further, to around -65 dB, or about 45 dB below the primary signal -- and the energy drops still further above that point.
That means, even if the normal POTS line actually transmitted signal at higher frequencies, it would be almost entirely buried in noise anyway, unless they also reduced noise levels. It turns out that while low noise levels are generally good, on a phone most people don't like it much.
In fact, on a current phone syste, much of the noise is there intentionally. To maximize bandwidth, especially over the long distance networks, they compress the signals, and when the compressor detects a time that nothing is being said, instead of transmitting compressed noise, it transmits a more compact signal saying there's no real signal right now. On the receiving end, they respond to this by synthesizing and injecting what they call "comfort noise". Without this, many people think the call has been dropped, because it sounds like it has "gone dead".
In case anybody wonders: I talked about 4 KHz and 8 KHz instead of 8 KHz and 16 KHz. The 8 and 16 KHz are the _sampling_ rates. A guy named Nyquist long ago theorized that to sample a signal meaningfully, you have to sample at a frequency at least double that of the signal itself. On the decoding side, you have to do some filtering, and in the process you normally lose at least a little bit of the bandwidth near the limit, so an 8 KHz sampling rate means the theoretical maximum signal is 4 KHz, but in reality it'll normally be a little less than that.
This is one of the most intelligent comments in this thread. If the article is correct, it's pretty clear that the FBI isn't even making an attempt at following basic rules of security that have been well known since long before the FBI even existed...
PK in general was originally invented by one of the British spy agencies (CESG, if memory serves). They invented analogs to both Diffie-Hellman key exchange, and to RSA encryption. They didn't see it as particularly useful for their work, so they didn't do much with it, but they kept the work secret, so nobody else did anything with it either. Nothing happened at all.
Then (years later), Diffie and Hellman worked out their key exchange protocol. They patented and published it. Almost immediately, the entire field nearly exploded -- half a dozen more forms of public key cryptography were invented (and half of them broken, of course). Among those was RSA -- but if D-H hadn't patented and published theirs first, I doubt RSA would have been invented, at least when and how it was. Somebody else might have eventually come up with the same thing -- or, if nothing else, the earlier British work might have come to public notice and somebody would have recognized its usefulness.
OTOH, that really is an "eventually" kind of thing. Admittedly, it's impossible to say what would have happened under different circumstances; it's possible that even without a patent system, Diffie and Hellman would have published their work. It's possible that without Diffie and Hellman's prior work, Rivest, Shamir and Adelman would have gotten together and developed RSA anyway -- but I doubt it. My own guess is that if there wasn't a patent system, "ecommerce" would only be a typo, not a business model.
I've never heard anybody say they're the only way. Quite a few different methods have been tried, however, and patents do appear to be one of the most effective. If, however, you look at the systems that were in place before patents came into use, they were mostly aimed at confining knowledge, not sharing it. There's pretty solid historical evidence that under the old guild system, people were sometimes killed for having revealed the guild's secrets. In fact, engineering books today are chock full of knowledge that was once carefully guarded from public disclosure.
There would undoubtedly be some innovation without a patent system. Personally, however, I'm reasonably convinced that there wouldn't be nearly as much. Much of this would be due to inventions not being published.
As far as HTTP and autoconf go: neither one would probably qualify for a patent in the first place. To patent something, you need to invent something. Offhand, I can't think of much about either one that looks truly inventive. It's hard to imagine anybody attempting to put something as innovative as public key encryption into the same bin with something as mundane as HTTP or autoconf.
The first US patent law was passed in 1790, and gave a term of 14 years with the possibility of a 7 year extension. In 1836, the possibility of an extension was removed, and the original term was extended to 17 years. It stayed at 17 years until 1995.
Up to that point, the term of a patent was measured from the time the patent was granted. In 1995, the law was changed so the term of a patent is measured from the time the patent is filed instead. Since it typically takes around 3 years for a patent to be granted, they changed the coverage to be 20 years from when the patent is filed. This change gets rid of a few abuses some people used to keep patents in the system for years (decades, in some cases) to extend their coverage far beyond what was ever really intended.
This gives some minimal extension to a few patents that are granted relatively quickly. OTOH, it shortens the term of patents that take longer to be granted. There's also a special provision for drug patents to have their coverage extended in case the patent would be expired (or nearly so) before the FDA approved its sale.
All in all, there's been little overall change. Some patents granted under the current law will probably get a couple of years more than they would have under the 1790 law, but there are almost certainly other patents that get less. I don't know for sure, but I suspect that on average, patents now expire a bit sooner than they did at that time.
I know this was meant to be funny, but it brings out a frequently ignored point. The real patent number 3404987 expired in 1985. What it covered (a food preservative) was the exclusive property of Procter and Gamble for a while, but it's now in the public domain, so anybody can use it. Furthermore, the patent gives anybody who cares directions about exactly what it is, how to make it, and how to use it.
The point is that patents expire, and when they do, whatever they covered becomes public domain, guaranteed to be usable by anybody. Furthermore, they often disclose more than they actually covered -- and whatever they disclose is public domain as well.
For quite a while, the patent office didn't accept applications for patents on software at all. That meant (among other things) that when they did start to accept such patents, it was hard to see the benefit because no such patent was going to expire for a long time, and it often looked like they'd all be obsolete long before they expired. That's clearly not the case. There are now quite a few expired patents on truly useful things. Obvious examples include LZW compression and RSA encryption.
Right now we're seeing an explosion in the number of patents on what we currently consider high-tech inventions. These, however, are starting to expire. Somewhere on the order of 1000 patents expire every week -- and that number is rising. In a few years, we can expect to see a couple of thousand inventions come into the public domain every week -- and they'll all include directions about how to build them, put them to use, etc. Without the patent system, or something very similar to it, we could not expect such a thing to happen.