I think the grandparent was suggesting applying security patches that include kernel upgrades.
How else would you handle security bug fixes if remote exploits are involved?
My job got me a linux laptop from dell years ago (about 5 years back I guess) so they used to do it
(it was a dell inspiron with a redhat install). I'm not sure why they stopped.
I was always under the impression that David Patterson at Berkeley and John Hennessy (now President of Stanford) invented the RISC architecture and then took it to Sun? The Patterson bio linked to above seems to indicate that he did invent the RISC architecture. Huh.
To be sure Patterson and Hennessy were influential in the development RISC architectures and
certainly did a lot to increase their popularity..
However, Patterson's design became the SPARC, but Hennessy's was the MIPS, and Hennessy
founded a chip building company (also called MIPS if my memory serves) based on the
MIPS processor family. I think SGI bought out MIPS in the early/mid 1990's.
While SPARC may have been the first VLSI based RISC architecture, I think the IBM 801 architecture may have preceded it.
John Cocke at IBM
was a seminal thinker in the area and may have developed the RISC concept and was awarded
a Turing award for this work, so he might have a claim for the innovation.
Actually my favorite depiction of Engineers in the movies is in Apollo 13. They show engineers responding to a crisis, rolling up their sleeves and making things work in a very no-nonsense way. Even when the crisis is first reported and you see all the people in the room lift their hands off their keyboards and hold them up and give the time-honored look of "I didn't do it, what the hell is going on here?" is very telling of true engineering culture.
But you are right, engineers, mathematicians and scientists could use more positive images (I like Numb3rs on that account). The U.S. culture seems to undervalue them.
That is hard to say. EPIC is a very long instruction word architecture (VLIW) which supports up to 3 concurrent non-interfering instructions which requires static (compile time) scheduling,
since the instructions must be in contiguous memory.
Getting efficient scheduling is hard, since the complexity is pushed back on the compiler, which may need to do some serious code reordering. Additionally, EPIC was designed to support speculative execution, which has efficiency issues if the wrong prediction is made. Additionally, EPIC had a new instruction set/core so Intel may not have gotten as much reuse of existing designs that multithreaded (using register bank switching) or multi core designs might have been able to exploit. Modern fabrication and design is so complex, that widely used designs get development resources and new interesting directions often don't get fabricated.
I originally posted from memory and didn't take the time to do an on-line search.
While there may have been an issue with that (which I've never heard of), the infamous Hubble mirror problem was that Perkin-Elmer built the mirror wrong due to a flawed instrument, and ignored the other instruments that were telling them it wasn't the right shape.
Some details on the measuring error you mention are given here and a mention of a misplaced measuring rod cap is discussed here.
The early Hubble pictures suffered from optical distortion due to a miscalculation on what the shape of the mirror would be in obit, and NASA also fixed that problem using digital image filtering techniques to reconstruct a clear image. The key was that they had a precise model of the distortion and that it was invertible.
Recently in our department, we had historically made separate orders for equipment purchases. I had our purchasing revise our approach to aggregate the orders and then called the vendors and got between 10 and 15 percent off on average. The reduced cost of processing and shipping was probably what did it (although we are a regular customer of theirs).
The mostly likely one is that exploits are intentionally broken when released. The reasons why are numerous and have been discussed before. But it's common to find exploits that have intentional programming errors. Every so often, an exploit author will release a "working" exploit on BugTraq. When this happens, the author is typically flammed because he didn't break the exploit.
Unfortunately the effort of trying to find the
bug is often large, and many times when I read the kernel or application code the claimed vulernability is not present in a version that the exploit writer claims is susceptible.
Given the quality of exploit code I've seen written recently, it may be unintentionally broken:-). Remember, raising false alarms helps the bad guys, perhaps if they can't safely publish a working exploit they should not publish any.
Another common cause is the author didn't design the exploit to be portable. If the author returned to libc in the exploit and they wrote it on say a Slackware system, the exploit probably will not work as written on FC2.
But these authors make all sorts of claims
about what environments are vulnerable, no?
There are times when vulnerabilities exist only when a complex list of environmental conditions are met. A certain kernel version, using a certain version of libc, compiled with a certain version of gcc with a particular compiler option, on a particular filesystem.....
That may be true. There certainlly is a need for a good test facility coupled with the repositories. Being fast and wrong in disclosing vulnerabilities is not nearly as helpful as being right.
one thing i think is an issue is its hard to make exploits that work against a range of kernels as offsets etc change. but with some effort most of them could be adapted to other kernels which have the bug but need slightly different numbers to exploit it.
It is hard to say, the exploits are typically released with mysterious hard coded values in them, with no documentation of how those values are computed. Also many exploits claim to exploit race conditions.
Often, the vulnerability these folks write about seems plausible. Other times these folks just make wild claims about what kernel versions they think are vulnerable but when I go read the kernel source I see that the vulnerability was closed. There is definitely a need to standardize testing and analysis of exploit code and vulnerabilities,
and a need for places that publish such data to vet their data, to screen out the poseurs and focus on the credible security researchers.
Our research group works in intrusion detection. As part of our research we wanted to generate host based intrusions in a Linux environment (Linux 2.6.2 kernel running on Fedora Core 2 without security patches applied).
We found that almost all the exploits we tried did not work as advertised. Yet the security advisory lists blindly post these as if they work. While the design/implementation issues may be present in a range of kernels, I'm beginning to think that these exploits are not vetted, and that the exploit writers look for a possible weakness and publish a piece of software that sort of pokes at it and claim success. It is very frustrating, since if the vulnerability can be exploited, a bogus exploit gives a false sense of security (since you can't compromise the system using it).
I was a professional Pascal programmer back in
the day (mid 1980's). One of the best C.S. books
of all time is Niklaus Wirth's
Data Structures+Algorithms=Programs. Don't bother
with the watered down Modula 2 followup book (unless you want
to learn Modula 2), this version covers many
useful algorithms AND even shows a compiler
with a virtual machine interpreter, done in
stages with stepwise refinement.
Pascal had many limitiations, however,
many production versions of the language had
useful but nonstandard work arounds.
Key escrow/recovery schemes where there is a sort of "backdoor" built in to allow for key recovery via trusted third parties fell out of favor in the late 1990's, as can be seen at:
in this paper.
My research is currently looking into approaches to related areas (as a user, not necessarily as a cryptographer), you may wish to look into "secret sharing", where given a secret (e.g. a private key), a set of participants, and what the literature calls an access structure which is a collection of subsets of participants that you wish to be able to easily recover the secret (called a qualified subset), establishes a two stage protocol:
Share - a trusted entity called the dealer takes the secret and encodes it into a set of shares, securely awarding each participant a unique share.
Reconstruct - some subset of the participants presents their shares, if the shares are valid and the subset is a qualified subset, the secret is recovered and securely distributed to that subset of participants, otherwise the secret should not be revealed.
Now, there are (t,n) theshold schemes where any subset of t or more participants where t is between 2 and n are qualified to recover the key otherwise they are not.
There are proactive variants that periodically recut the shares to prevent accumulated leaking of shares over time from forming a qualified subset.
Also there are verified secret sharing schemes which support a verify operation, where a share can be checked for correctness without trying to reconstruct the secret (so that bad dealers can be caught and that at reconstruct time invalid shares
can be found prior to reconstruction).
Finally there are "cheating immune" schemes.
A cheater is a participant who gives a bogus share at reconstruct time. If they know something about the reconstruction step and can assume the other participants are giving valid shares, some schemes may allow the cheaters to learn something about the secret. In cheating immune schemes, this is prevented.
Finally there are schemes that use verifiable threshold schemes and verifiable secret sharing for digital signatures.
But statistics are critical to AI, right? Data mining (KDD) and Machine Learning (AI) both rely heavily on statistical approaches and require knowing at least something about statistical confidence, sampling, experiment design and some regression/analysis of variance would not hurt either. Bayesian models are quite popular and they are highly statistical.
As many of the other responses have noted,
patents provide protection of small companies
who come up with innovative approaches, preventing
larger companies from stealing their work.
Also important, is that patents encourage
disclosure and forwards scientific research.
Without patents, companies would have to treat
their methods as trade secrets and hope that
others cannot steal the techniques or reverse
engineer them. Thus patents are important to
the public good (although some reforms of the
current system might make sense).
I'm curious, what about fuel/hangar/airport and other costs. How expensive are those, and are there other operating expenses (e.g. insurance) that add up?
The amount of electricity generated varies according to the load. I don't think it is safe to assume that unused capacity is "free" given the way I think they operate.
2) Using oil/coal/gas, etc in ONE location makes it easier to clean- only ONE smokestack needs to be dealt with, instead of thousands of car exhausts all over the place.
While pollution control and conversion to electricity might potentially be more efficient at a large central location, transmission loss and loss when charging batteries might not be so efficient. The high number of miles per gallon obtained may not be an accurate refletion of energy efficiency, since the cost of obtaining the potential energy in the batteries is not discussed in the article.
Some classes of errors are pretty hard to solve,
in particular timing, synchronization, and some clases of hardware related failures can appear to be sporadic and very difficult to reproduce and analyze. When I'm up against one of those problems, I'll take all the help I can get. Particularly for timing dependent stuff, where instrumentation chan change the timing characteristics.
Reverse execution is possible at the source level, but it requires generation of extra data structures to handle operations that don't correspond to invertible functions. This approach has been applied with some success to high performance simulations to give a "lightweight rollback",
by Peters and Carothers in An Algorithm for Fully Reversible Optimistic Parallel Simulation.
Slashdot Mirror
I think the grandparent was suggesting applying security patches that include kernel upgrades. How else would you handle security bug fixes if remote exploits are involved?
My job got me a linux laptop from dell years ago (about 5 years back I guess) so they used to do it (it was a dell inspiron with a redhat install). I'm not sure why they stopped.
While SPARC may have been the first VLSI based RISC architecture, I think the IBM 801 architecture may have preceded it. John Cocke at IBM was a seminal thinker in the area and may have developed the RISC concept and was awarded a Turing award for this work, so he might have a claim for the innovation.
What about using WAP or some html based response. Just because the user uses voice input does not mean that has to be the output.
But you are right, engineers, mathematicians and scientists could use more positive images (I like Numb3rs on that account). The U.S. culture seems to undervalue them.
Maybe Dave Musser at RPI (one of the founders of the STL project) might take it over.
That is hard to say. EPIC is a very long instruction word architecture (VLIW) which supports up to 3 concurrent non-interfering instructions which requires static (compile time) scheduling, since the instructions must be in contiguous memory. Getting efficient scheduling is hard, since the complexity is pushed back on the compiler, which may need to do some serious code reordering. Additionally, EPIC was designed to support speculative execution, which has efficiency issues if the wrong prediction is made. Additionally, EPIC had a new instruction set/core so Intel may not have gotten as much reuse of existing designs that multithreaded (using register bank switching) or multi core designs might have been able to exploit. Modern fabrication and design is so complex, that widely used designs get development resources and new interesting directions often don't get fabricated.
Thanks for the correction, that is very informative.
I originally posted from memory and didn't take the time to do an on-line search. While there may have been an issue with that (which I've never heard of), the infamous Hubble mirror problem was that Perkin-Elmer built the mirror wrong due to a flawed instrument, and ignored the other instruments that were telling them it wasn't the right shape. Some details on the measuring error you mention are given here and a mention of a misplaced measuring rod cap is discussed here.
The early Hubble pictures suffered from optical distortion due to a miscalculation on what the shape of the mirror would be in obit, and NASA also fixed that problem using digital image filtering techniques to reconstruct a clear image. The key was that they had a precise model of the distortion and that it was invertible.
Recently in our department, we had historically made separate orders for equipment purchases. I had our purchasing revise our approach to aggregate the orders and then called the vendors and got between 10 and 15 percent off on average. The reduced cost of processing and shipping was probably what did it (although we are a regular customer of theirs).
We found that almost all the exploits we tried did not work as advertised. Yet the security advisory lists blindly post these as if they work. While the design/implementation issues may be present in a range of kernels, I'm beginning to think that these exploits are not vetted, and that the exploit writers look for a possible weakness and publish a piece of software that sort of pokes at it and claim success. It is very frustrating, since if the vulnerability can be exploited, a bogus exploit gives a false sense of security (since you can't compromise the system using it).
Pascal had many limitiations, however, many production versions of the language had useful but nonstandard work arounds.
My research is currently looking into approaches to related areas (as a user, not necessarily as a cryptographer), you may wish to look into "secret sharing", where given a secret (e.g. a private key), a set of participants, and what the literature calls an access structure which is a collection of subsets of participants that you wish to be able to easily recover the secret (called a qualified subset), establishes a two stage protocol:
- Share - a trusted entity called the dealer takes the secret and encodes it into a set of shares, securely awarding each participant a unique share.
- Reconstruct - some subset of the participants presents their shares, if the shares are valid and the subset is a qualified subset, the secret is recovered and securely distributed to that subset of participants, otherwise the secret should not be revealed.
Now, there are (t,n) theshold schemes where any subset of t or more participants where t is between 2 and n are qualified to recover the key otherwise they are not.There are proactive variants that periodically recut the shares to prevent accumulated leaking of shares over time from forming a qualified subset.
Also there are verified secret sharing schemes which support a verify operation, where a share can be checked for correctness without trying to reconstruct the secret (so that bad dealers can be caught and that at reconstruct time invalid shares can be found prior to reconstruction).
Finally there are "cheating immune" schemes. A cheater is a participant who gives a bogus share at reconstruct time. If they know something about the reconstruction step and can assume the other participants are giving valid shares, some schemes may allow the cheaters to learn something about the secret. In cheating immune schemes, this is prevented.
Finally there are schemes that use verifiable threshold schemes and verifiable secret sharing for digital signatures.
If you are interested in some references, Doug Stinson's bibliography on Secret Sharing (he has some recent work too). Tal Rabin has done some good work, as has Markus Stadler. Recent work by Stanislaw Jarecki has caught my eye.
I thought patents were for 17 years, and this one appears to have been granted in 1987.
But statistics are critical to AI, right? Data mining (KDD) and Machine Learning (AI) both rely heavily on statistical approaches and require knowing at least something about statistical confidence, sampling, experiment design and some regression/analysis of variance would not hurt either. Bayesian models are quite popular and they are highly statistical.
I'm curious, what about fuel/hangar/airport and other costs. How expensive are those, and are there other operating expenses (e.g. insurance) that add up?
The amount of electricity generated varies according to the load. I don't think it is safe to assume that unused capacity is "free" given the way I think they operate.
Some classes of errors are pretty hard to solve, in particular timing, synchronization, and some clases of hardware related failures can appear to be sporadic and very difficult to reproduce and analyze. When I'm up against one of those problems, I'll take all the help I can get. Particularly for timing dependent stuff, where instrumentation chan change the timing characteristics.
Reverse execution is possible at the source level, but it requires generation of extra data structures to handle operations that don't correspond to invertible functions. This approach has been applied with some success to high performance simulations to give a "lightweight rollback", by Peters and Carothers in An Algorithm for Fully Reversible Optimistic Parallel Simulation.