It's in the tradtion of the "Open Software Foundation" and "The Open Group". In the traditional sense, "open" means "more than one vendor is involved".
It's called "window stations" and "desktops". There are separate hooks, message queues and so on. In short: everything that is necessary. Maybe there are implementation flaws, maybe the interfaces are extremely difficult to program (I don't know, I haven't tried), but the design is sound.
15 minutes of MSDN browsing were required to discover this (and I spent 10 minutes on finding the entry point to the API documentation using Mozilla). Why can't people read the documentation?
Didn't the FTC examine those APIs in the early 90s, and didn't Microsoft claim that there wasn't any reason for them to use undocumented APIs in their applications, or something like that? Internal APIs are hard to avoid, and you can get into deep trouble if someone relies on them (because you cannot change them after that). If Microsoft was using these APIs for applications (and not system components), then they knew that they made two fundamental errors: they violated the previous FTC agreement, and good software engineering practices.
Large parts of SAPDB seem to be written in Pascal, which is processed by a transpiler to generate C code. This makes debugging complicated. In addition, the whole build environment (the transpiler, the project-specific make tool, and so on) have only been released as free software quite recently. This might explain why SAPDB doesn't attract developers from the free software community, but it doesn't explain why it doesn't take the user community by storm.
I hope to be able to use SAPDB some day, if PostgreSQL ever breaks for us. Currently, there's nothing pushing us away from PostgreSQL and SAPDB lacks quite a few features we like in PostgreSQL (the extensible type system, which allows us to store IP addresses directly, for example). The documentation seems to unclear in quite a few areas, too. In addition, it seems that native (non-ODBC) backends are no longer supported by SAPDB.
If the details to this vulnerability would have been released (even with patches) just about every Linux box on the planet would have been cracked before the owners would've had time to install the patch. Publishing a fix to this problem will only tell the cracker exactly where the problem is.
Nice story, but most GNU/Linux systems weren't affected by this bug at all. Unfortunately, we now know that privilege separation didn't help much because of BSD kernel bug.
A singularity, exactly. And if I recall most of (all?) the Escher prints I saw avoided singularities: they were quite regular, so to speak, at least locally. Only if viewed as a whole, they were absurd.
As for the database itself. I can't stand to read the damn EULA's when I buy the software. Why would anybody want to go and read them off of a website? Yuk.
Perhaps because you don't want to download all the software just to discover that you can't accept the EULA terms?
No patent license is granted separate from the Covered Code, for code that you delete from the Covered Code, or for combinations of the Covered Code with other software or hardware.
You may create a derivative work under copyright, but you don't have the right to run the code for profit (or whatever use can infringe a patent in your legislation).
Since they use Ada, this war machine will actually work, despite more 1.5 million lines of source code running it. That's sad, why couldn't they use C, C++ or even Java for such projects, where failure might actually benefit mankind?
This is a good idea, and it has been done before: for trademarks. However, those who make a living on patent-related services will never agree to such a rule (and they control much of the lawmaking in this area, at least in the industrialized world). After all, it's against their business model.
Were the inventors listed in the patent involved in JPEG standardization? Probably not. The patent is probably an accidental rediscovery. But whether intentional or not, delayed enforcement of patents is always a difficult problem. I hope they won't go after the smaller companies first and extort licenses from them (they can probably sue back their vendors, and force the latter to accept rather unfavorable license terms, even if they were objecting at first).
On the other hand, one problem with RAND is that even if you pay for a license, there is no guarantee that the same thing happens. You pay someone for a license, but you don't know if you need further licenses. So in order to use RAND-licensed technology safely, you need a decent patent portfolio. If someone tries to harnass you, you can harnass back. (What's it called? Mutual assured descruction?)
If they believe they just need to shell out 75 million dollars for a stinking mailing list in order to contral an important part of the world's infrastructure, they are idiots.
BUGTRAQ is not all the infrastructure controlled by SecurityFocus. Symantec is probably more interested in the world-wide sensors network.
Furthermore, quite a few people already Cc other lists when posting to BUGTRAQ. (There are reports that BUGTRAQ moderators try to force submitters to make pointless changes to their articles.) Lately, BUGTRAQ hasn't seen many interesting discussions. I don't think it could get a lot worse...
Distributed development with Aegis is different from CVS, of course, but it mirrors the way some projects are run (for example, the Linux kernel up to the introduction of BitKeeper).
I'm not really comfortable with Slashdot publishing phone numbers at all. Whose one is next? Yours? Mine?
Disrupting web sites by posting links is one thing, but posting internal phone numbers which are used to deal with critical problems is really, really bad.
For some reason, primes always plot along one of the axes. No one can figure out why.
Actually, that's easy. Primes (at least over the integers) are real numbers, and the zeta function maps real numbers greater than one to real numbers, which is evident from the definition as a Dirichlet series.
Quite a few proofs in analytical number theory rely on the fact that in certain areas on the right side of the line {z : Re z = 1/2} contain no zeroes of the zeta function. So far, mathematicians have tried to carefully choose these areas in order to get good results (so that you can still use them efficiently, but you can also prove that no zeroes lie in it). If we knew that no such zeroes exist at all (the Riemann Hypothesis), we could avoid all these rather technical details and theorems would improve considerably as well (for example, the error term in the Prime Number Theorem).
And how's this different from a DoS attack? Does really matter if you offer decoy files instead of sending decoy packets? In both cases, your intent is to disrupt the service.
Some more data has become public: Some one close to the Apache team claimed that the IIS patch is wrong, and there's a response from IIS. Maybe the IIS patch does fix the problem, but it is certainly not the most obvious and reader-friendly way to do it.
And, by the way, we have extrated the critical patch from the 1.3.x CVS (currently skipping mod_proxy), created a Debian package containing it, and written a German notice (still preliminary) for our free security newsletter. (The Debian package will be updated as new changes appear in the Apache CVS.)
Slashdot Mirror
It's in the tradtion of the "Open Software Foundation" and "The Open Group". In the traditional sense, "open" means "more than one vendor is involved".
It's called "window stations" and "desktops". There are separate hooks, message queues and so on. In short: everything that is necessary. Maybe there are implementation flaws, maybe the interfaces are extremely difficult to program (I don't know, I haven't tried), but the design is sound.
15 minutes of MSDN browsing were required to discover this (and I spent 10 minutes on finding the entry point to the API documentation using Mozilla). Why can't people read the documentation?
Didn't the FTC examine those APIs in the early 90s, and didn't Microsoft claim that there wasn't any reason for them to use undocumented APIs in their applications, or something like that? Internal APIs are hard to avoid, and you can get into deep trouble if someone relies on them (because you cannot change them after that). If Microsoft was using these APIs for applications (and not system components), then they knew that they made two fundamental errors: they violated the previous FTC agreement, and good software engineering practices.
Both errors are hardly surprising, though.
Large parts of SAPDB seem to be written in Pascal, which is processed by a transpiler to generate C code. This makes debugging complicated. In addition, the whole build environment (the transpiler, the project-specific make tool, and so on) have only been released as free software quite recently. This might explain why SAPDB doesn't attract developers from the free software community, but it doesn't explain why it doesn't take the user community by storm.
I hope to be able to use SAPDB some day, if PostgreSQL ever breaks for us. Currently, there's nothing pushing us away from PostgreSQL and SAPDB lacks quite a few features we like in PostgreSQL (the extensible type system, which allows us to store IP addresses directly, for example). The documentation seems to unclear in quite a few areas, too. In addition, it seems that native (non-ODBC) backends are no longer supported by SAPDB.
If the details to this vulnerability would have been released (even with patches) just about every Linux box on the planet would have been cracked before the owners would've had time to install the patch. Publishing a fix to this problem will only tell the cracker exactly where the problem is.
Nice story, but most GNU/Linux systems weren't affected by this bug at all. Unfortunately, we now know that privilege separation didn't help much because of BSD kernel bug.
A singularity, exactly. And if I recall most of (all?) the Escher prints I saw avoided singularities: they were quite regular, so to speak, at least locally. Only if viewed as a whole, they were absurd.
As for the database itself. I can't stand to read the damn EULA's when I buy the software. Why would anybody want to go and read them off of a website? Yuk.
Perhaps because you don't want to download all the software just to discover that you can't accept the EULA terms?
just wanted to grab some headlines, i guess...
Maybe he had not realized beforehand that he'd bring quite a few colleages (perhaps even friends) in a very difficult situation. We don't know.
If you put stuff out there on the net, then you're stuck with it out there.
You can put so much crap on the net that nobody is able to spot the interesting stuff (at least using Google).
Without even considering the lives that would be lost due to the software failing...
Projects of this size which are not carefully planned (which involves the choice of proper tools) tend to fail during development, not in the field.
People tried to get a custom contract for Microsoft Visual Studio (or some other development product). They failed.
I can image that the situation with Sun is better in gernal (maybe not in the Java area).
You are right. Guess what? One of the Code Red variants never made its way to the disk of a compromised system.
They could just sue for patent infringement:
No patent license is granted separate from the Covered Code, for code that you delete from the Covered Code, or for combinations of the Covered Code with other software or hardware.
You may create a derivative work under copyright, but you don't have the right to run the code for profit (or whatever use can infringe a patent in your legislation).
Since they use Ada, this war machine will actually work, despite more 1.5 million lines of source code running it. That's sad, why couldn't they use C, C++ or even Java for such projects, where failure might actually benefit mankind?
And this changes what? Surely you can't expect anyone distributing computer software to read most of the patents!
This is a good idea, and it has been done before: for trademarks. However, those who make a living on patent-related services will never agree to such a rule (and they control much of the lawmaking in this area, at least in the industrialized world). After all, it's against their business model.
Were the inventors listed in the patent involved in JPEG standardization? Probably not. The patent is probably an accidental rediscovery. But whether intentional or not, delayed enforcement of patents is always a difficult problem. I hope they won't go after the smaller companies first and extort licenses from them (they can probably sue back their vendors, and force the latter to accept rather unfavorable license terms, even if they were objecting at first).
On the other hand, one problem with RAND is that even if you pay for a license, there is no guarantee that the same thing happens. You pay someone for a license, but you don't know if you need further licenses. So in order to use RAND-licensed technology safely, you need a decent patent portfolio. If someone tries to harnass you, you can harnass back. (What's it called? Mutual assured descruction?)
If they believe they just need to shell out 75 million dollars for a stinking mailing list in order to contral an important part of the world's infrastructure, they are idiots.
BUGTRAQ is not all the infrastructure controlled by SecurityFocus. Symantec is probably more interested in the world-wide sensors network.
Furthermore, quite a few people already Cc other lists when posting to BUGTRAQ. (There are reports that BUGTRAQ moderators try to force submitters to make pointless changes to their articles.) Lately, BUGTRAQ hasn't seen many interesting discussions. I don't think it could get a lot worse...
If the build and testing is triggered from a UNIX box (using SSH or even rsh), you can use Aegis for development on NT.
Distributed development with Aegis is different from CVS, of course, but it mirrors the way some projects are run (for example, the Linux kernel up to the introduction of BitKeeper).
I'm not really comfortable with Slashdot publishing phone numbers at all. Whose one is next? Yours? Mine?
Disrupting web sites by posting links is one thing, but posting internal phone numbers which are used to deal with critical problems is really, really bad.
The *disruption* is only in the trading of "fake" files - files that aren't labeled as what they are.
By the same line of argument, a SYN flood isn't illegal either, it just consists of mislabled packets.
He wrote a function called the "zeta function."
The function had already been discussed by Euler.
For some reason, primes always plot along one of the axes. No one can figure out why.
Actually, that's easy. Primes (at least over the integers) are real numbers, and the zeta function maps real numbers greater than one to real numbers, which is evident from the definition as a Dirichlet series.
Quite a few proofs in analytical number theory rely on the fact that in certain areas on the right side of the line {z : Re z = 1/2} contain no zeroes of the zeta function. So far, mathematicians have tried to carefully choose these areas in order to get good results (so that you can still use them efficiently, but you can also prove that no zeroes lie in it). If we knew that no such zeroes exist at all (the Riemann Hypothesis), we could avoid all these rather technical details and theorems would improve considerably as well (for example, the error term in the Prime Number Theorem).
And how's this different from a DoS attack? Does really matter if you offer decoy files instead of sending decoy packets? In both cases, your intent is to disrupt the service.
Some more data has become public: Some one close to the Apache team claimed that the IIS patch is wrong, and there's a response from IIS. Maybe the IIS patch does fix the problem, but it is certainly not the most obvious and reader-friendly way to do it.
.)
And, by the way, we have extrated the critical patch from the 1.3.x CVS (currently skipping mod_proxy), created a Debian package containing it, and written a German notice (still preliminary) for our free security newsletter. (The Debian package will be updated as new changes appear in the Apache CVS