The old X11 license explicitly granted the right to sublicense. You can take
the code and redistribute it as part of a derived work under the GPL, the
Mozilla Public License or the MS EULA.
The GPL explicitly says that derived works must be redistributed under
exactly the terms of the GPL. You cannot take the code and redistribute it
as a part of a derived work under the X11 license, the MPL or the MS EULA.
The web server is not everything Apache does. They also provide many very
popular Java libraries, for example. Log4J is more or less a quasi-standard,
even after Sun included a competing API in the core library. The Xerces
and Xalan XML tools are extremely popular. These libraries cannot be used
together with other licenses under the GPL, if the licenses really were
incompatible.
Go to apache.org some time, the web server is by far not the only important
project of theirs any more. They are probably the second biggest free
software metaproject, after GNU.
Armed Bear Lisp: Interpreted, only used as an extension language for an unpopular editor
As for programming constructs introduced by Lisp and other high-level languages, no need to refer to obscure things like the Boost Greenspun^WLambda library. How about garbage collection, recursion, symbolic computing, or conditionals? (Lisp was the first language to have an "if"-like construct, before that it was all FORTRAN-style computed GOTOs)
With "current MySql versions", you mean the pre-alpha development release which for example will have (potentially crude) stored procedures? As opposed to the current unsupported beta version, which is the first to finally have subqueries (of course, after years of telling customers that you don't want them anyway, just as MySQL AB did with all other basic DBMS features they only now promise to support in a few years)?
PostgreSQL is trivial to install. Actually, there was a binary package for just about any unix-like OS I ever wanted to run it on. Compiling it from source is not hard either, even if there are more steps involved that just "configure; make; make install", due to it not running as root, which is a good thing.
Configuration, what you seem to be talking about, is not rocket science either. Of course it is harder than configuring MySQL, because it does more. In the case of access permissions, PostgreSQL seperates database permissions (GRANT SELECT ON some_table TO some_user) and the right to connect to the server in the first place (which you set up in pg_hba.conf). This is more work than the pure GRANT-based scheme of MySQL, where GRANTs not only based on user id, but also the remote host etc. It is also more flexible - For example, PostgreSQL can authenticate a connection with Kerberos or PAM - as far as I know, this is not possible, or at least not trivial, with MySQL.
As always, both have their place. If you want easy, use MySQL. If you want flexible, use PostgreSQL. Firebird's claim to fame in this regard has to be filled in by someone else, I don't know it well enough:-)
He is technically correct. SQL as a language, and the database management systems that use it, are not strictly implementations of relational algebra/calculus as CS defines it. Simple example: SQL's NULL doesn't make sense in the CS relational model.
In practice, it doesn't matter. The term "relational database" used to describe a real piece of software does not neccessarily imply strict conformance to the relational model as defined in CS textbooks. It is just another example of the same word used to refer to slightly different concepts in different contexts.
It is a little like saying that Objective Caml is not a functional programming language, because it allows side effects. In one sense, it is true, but not in the sense people care about.
Exactly. This is about preventing buffer overflows as much as file permissions are about preventing trojan horses.
There already is a fine way to reliably prevent buffer overflows: Check each access. Prove that you don't overwrite anything. Too hard or too annoying? How about using a language that does this for you, like about every freaking programming language except C and C++? You'll get rid about another one of the most frequently exploited "features" as well, namely format string errors.
Given however that we are stuck with piles of buggy C programs, which will have buffer overflows and can't make use of dynamic programming techniques that might make W^X a hassle anyway, this oh so amazing new feature might in the end be worth it. But compare it to the state of the art of the early 80ies, where some processors had full builtin support for sophisticated type checks, this once again shows how ridiculously lousy "modern" systems, and the x86-derived architectures in particular, are. x86 is really the perfect match for Microsoft, no wonder that their success has been so closely coupled - a lousy, sub-par operating system for a lousy, sub-par processor architecture.
Unlike Joel Spolksy, free software developers have the luxury to base
technical decisions on technical facts, not being bound by marketing
or shareholder value related issues.
Many of the core Subversion developers are former CVS hackers. If they
say the code they worked on for years is unmaintainable I believe them.
CVS had fundamental (and obvious) architectural issues which you cannot
solve by adding a bugfix here and a new feature there. Sure, it took a
few years to make svn just do everything CVS already does, but did it
harm anyone? From now on there is a much cleaner codebase which is
easier to extend with new features, has less surprising corner cases
for users, and makes it easier for new developers to start hacking
it.
Although I am still undecided whether svn or arch will replace CVS for me
(arch is nice, but its non-portability sucks, and whoever came up with
the idea that using all kinds of funky hard-to-type script-unfriendly
characters in filenames would make a vc system better in any way should
be taken out and shot), I completely support the decision of the svn team
to start from scratch.
Working in your own tree, and merging that tree with the "official" one
only when you are done, is especially usefull if your connectivity sucks.
In a centralized model you don't have a chance to version-control your
local changes unless you can connect to the CVS-(or whatever-)Server,
you basically work without the safety net until you can commit.
This is probably more of an issue for free software projects, where
contributors might feel a desire to hack while travelling, or live in areas
without good connectivity. If everyone has a dedicated development
workstation connected to a CVS-server in the same LAN, it doesn't
matter much.
If nobody would write viruses, nobody would need virus scanners.
Not to mention that people do not understand that they should
not run arbitrary email attachments. Every few weeks we have a major
worm outbreak because millions of people happily run every piece of
malicious code they find.
As for "real" worms that don't require a collaborative user to spread,
it can hardly get worse than it is now, with all the knowledge and
awareness we have. The really ugly ones spread in minutes, faster than
anyone can react. (Also, they never seem to die, Nimda for example is
still active.)
You know, if this weren't such a stupid proposal in the case of TAOCP, he
might actually do that. Remember that TeX was one of the first explicitly
free software programs, just with fewer bugs and less ideology than the
stallmanist oevres.
Remember that he is already some years (decades?) past his original schedule.
TAOCP will not be finished. Period. Knuth is too much of a genius, and a
perfectionist, to actually manage to complete it in his lifetime. It will end
up like Karl Marx' Kapital (which was planned to have 6 volumes, and he died
early in preparing the third - which some people argue was only the third part
of volume 1), with few people actually understanding all of it, and heated
debates of what things might mean in the light of the never-written later
parts.
With the exception that fewer people will die because of such
controversies in Knuth' case, because there aren't too many militant
guerilla groups fighting for the right way to do seminumerical algorithms.
Nobody uses the OpenBSD default install on a server, because it just doesn't
serve anything. (Same goes for many other OSes, including the other free BSDs
and many Linux distros). Few people use a default Windows install on a server
either, because they know what services they want to offer to the public, and
DCOM might not be one of them.
In general, I think it is about as much work to make an OpenBSD server
do exactly what you want than it is to make a Windows one. The difference is
what happens when you make a mistake - in the OpenBSD case, you failed to
enable something properly, which will be easy to detect by clients complaining;
on Windows, everything keeps working, and you only notice that too much
is working when you are owned.
Thus, given that the study is about publically reachable servers, it comes
down to a measurement of average admin braindeadness. The systems talked
about are not home-user preinstalled vanilly systems, they are set up by
people paid for keeping them working. In that light, I think it is not
unthinkable that the percentage of idiots setting up a public server without
being qualified and knowing what they are doing that use Linux is pretty
hight - after all, "Linux is not hard for the average guy to use" and
"Linux is great for servers" are both claims not unheard of... Just combine
these marketing memes, and you have a timebomb.
Then again, this ignores that this particular study is really not worth
discussing...
The fact is, unix was a multiuser,
networked OS decades ago
Yes, and its security infrastructure was perfectly adequate decades ago.
The basic Unix security model is horrible. Actually, the Windows model has been
better since NT4, the difference has only been that Windows programmers and
users don't bother to use it, while writing secure programs despite POSIX
compatibility has often been tried.
The whole idea of one all-mighty superuser and a bunch of equally-created
ordinary users is stupid. What you really want is a fine-grained role
concept, or better, a capability-based system. The idea of "privileged ports"
is outright dangerous, the only practical consequence is that network servers
need to be able to write/etc/passwd to start up, while any attacker can just
fake the source port of IP packets, or use an OS that doesn't enforce priv
ports. The filesystem security attributes are rudimentary. Many APIs have
confusing or dangerous behaviour by default, and you cannot really call yourself
a unix-like system until you implement interfaces that simply cannot be safely
used (think gets(3)).
There is a reason why no self-respecting Unix-like OS today works solely with
the ancient Unix ways of doing things. They all support extended file access
control lists, fine-grained capabilities, more sophisticated authentication
schemes like PAM, mandatory access control etc. (Linux may still require
some kernel patch or the other for some of them, and BSDs other than FreeBSD 5
may also lack some of these features. But they all move in that direction.). The problem however is that they all
try to be "plain Unix" by default, and "plain Unix" is bad, security-wise. I
do not know any system that would actually use a sane capability scheme in the
default install. Most Unix admins are probably not even aware of the tools they
have.
In a sense, it would be way better to start from scratch with a new system,
kind of like what Eros tries to do. Of course, this would mean not only using
a completely new operating system, but completely new applications that
benefit from it as well. This is not going to happen anytime soon, and from
an administrators point of view, being an early adopter does not make any
sense - a well debugged Unix app is still a better choice to get the job done
than a from-scratch reimplementation that nobody but you uses.
The selling point for Unix today, unless you count Windows 98 as the only
alternative, is not security, it is performance and backwards-compatibility.
The latter is not a good foundation to build a long-time stategy upon.
Maybe the reason Eros was excluded from a study about real-worl server
attacks was that there - hopefully - are no real-world Eros servers?
If you care about security, and that would be one of few reasons to care
about Eros, you don't run unfinished early development versions of an
operating system, even if it has the potential to be really good once
it is finished.
The reason why KeyKOS wasn't mentioned is probably the same as the one for
information on ITS, Genera and Multics not making it into the headline.
Not being used by anyone it generally a good strategy for software to
prevent being exploited.
Just like most commercial Unixes missing (which could be explained by them
simply not being exploited, or at least no data being available on these
break-ins) is pretty suspicious, the result that "the BSDs" are most secure
is quite useless. We are talking about pretty different systems here - I
guess that NetBSD and Mac OS X differ widely in their typical usage scenarios
and the background of their admins, and that will certainly be reflected in
how they get r00ted.
What, you think Belgium is small? How about Andorra (~67.000 inhabitants), Liechtenstein (~32.000) or San Marino (~27.000)? Even Iceland has a population of less than half a million.
Oh, and the Vatican is a state of its own, too - with less then 1000 people on a whopping 3.2 square kilometers. It probably also has the lowest birth rate of all countries.
Slashdot Mirror
The GPL explicitly says that derived works must be redistributed under exactly the terms of the GPL. You cannot take the code and redistribute it as a part of a derived work under the X11 license, the MPL or the MS EULA.
See the difference?
Go to apache.org some time, the web server is by far not the only important project of theirs any more. They are probably the second biggest free software metaproject, after GNU.
- CMU CL: natively compiled
- SBCL: natively compiled
- MCL: natively compiled
- OpenMCL: natively compiled
- Xanalys LispWorks: natively compiled
- Allegro Common Lisp: natively compiled
- Corman Common Lisp: natively compiled
- Scieneer Common Lisp: natively compiled
- Embeddable Common Lisp: natively compiled, via GCC
- GNU Common Lisp: natively compiled, via GCC
- GNU CLISP: bytecode compiled
- Armed Bear Lisp: Interpreted, only used as an extension language for an unpopular editor
As for programming constructs introduced by Lisp and other high-level languages, no need to refer to obscure things like the Boost Greenspun^WLambda library. How about garbage collection, recursion, symbolic computing, or conditionals? (Lisp was the first language to have an "if"-like construct, before that it was all FORTRAN-style computed GOTOs)Well... that would probably be ESRs job, wouldn't it?
With "current MySql versions", you mean the pre-alpha development release which for example will have (potentially crude) stored procedures? As opposed to the current unsupported beta version, which is the first to finally have subqueries (of course, after years of telling customers that you don't want them anyway, just as MySQL AB did with all other basic DBMS features they only now promise to support in a few years)?
Configuration, what you seem to be talking about, is not rocket science either. Of course it is harder than configuring MySQL, because it does more. In the case of access permissions, PostgreSQL seperates database permissions (GRANT SELECT ON some_table TO some_user) and the right to connect to the server in the first place (which you set up in pg_hba.conf). This is more work than the pure GRANT-based scheme of MySQL, where GRANTs not only based on user id, but also the remote host etc. It is also more flexible - For example, PostgreSQL can authenticate a connection with Kerberos or PAM - as far as I know, this is not possible, or at least not trivial, with MySQL.
As always, both have their place. If you want easy, use MySQL. If you want flexible, use PostgreSQL. Firebird's claim to fame in this regard has to be filled in by someone else, I don't know it well enough :-)
Well, how hard is rendering CSS anyway? Just display text/css the same way as text/plain, and everyone is happy.
In practice, it doesn't matter. The term "relational database" used to describe a real piece of software does not neccessarily imply strict conformance to the relational model as defined in CS textbooks. It is just another example of the same word used to refer to slightly different concepts in different contexts.
It is a little like saying that Objective Caml is not a functional programming language, because it allows side effects. In one sense, it is true, but not in the sense people care about.
There already is a fine way to reliably prevent buffer overflows: Check each access. Prove that you don't overwrite anything. Too hard or too annoying? How about using a language that does this for you, like about every freaking programming language except C and C++? You'll get rid about another one of the most frequently exploited "features" as well, namely format string errors.
Given however that we are stuck with piles of buggy C programs, which will have buffer overflows and can't make use of dynamic programming techniques that might make W^X a hassle anyway, this oh so amazing new feature might in the end be worth it. But compare it to the state of the art of the early 80ies, where some processors had full builtin support for sophisticated type checks, this once again shows how ridiculously lousy "modern" systems, and the x86-derived architectures in particular, are. x86 is really the perfect match for Microsoft, no wonder that their success has been so closely coupled - a lousy, sub-par operating system for a lousy, sub-par processor architecture.
I doubt that the Opteron conforms to that standard.
I heard they have some ways to deal with that in the vatican.
Many of the core Subversion developers are former CVS hackers. If they say the code they worked on for years is unmaintainable I believe them. CVS had fundamental (and obvious) architectural issues which you cannot solve by adding a bugfix here and a new feature there. Sure, it took a few years to make svn just do everything CVS already does, but did it harm anyone? From now on there is a much cleaner codebase which is easier to extend with new features, has less surprising corner cases for users, and makes it easier for new developers to start hacking it.
Although I am still undecided whether svn or arch will replace CVS for me (arch is nice, but its non-portability sucks, and whoever came up with the idea that using all kinds of funky hard-to-type script-unfriendly characters in filenames would make a vc system better in any way should be taken out and shot), I completely support the decision of the svn team to start from scratch.
But why is it? Subversion works fine without apache 2, just use svnserve. (Without the httpd, that is, you still need the APR)
This is probably more of an issue for free software projects, where contributors might feel a desire to hack while travelling, or live in areas without good connectivity. If everyone has a dedicated development workstation connected to a CVS-server in the same LAN, it doesn't matter much.
Not to mention that people do not understand that they should not run arbitrary email attachments. Every few weeks we have a major worm outbreak because millions of people happily run every piece of malicious code they find.
As for "real" worms that don't require a collaborative user to spread, it can hardly get worse than it is now, with all the knowledge and awareness we have. The really ugly ones spread in minutes, faster than anyone can react. (Also, they never seem to die, Nimda for example is still active.)
TAOCP will not be finished. Period. Knuth is too much of a genius, and a perfectionist, to actually manage to complete it in his lifetime. It will end up like Karl Marx' Kapital (which was planned to have 6 volumes, and he died early in preparing the third - which some people argue was only the third part of volume 1), with few people actually understanding all of it, and heated debates of what things might mean in the light of the never-written later parts.
With the exception that fewer people will die because of such controversies in Knuth' case, because there aren't too many militant guerilla groups fighting for the right way to do seminumerical algorithms.
Nobody uses the OpenBSD default install on a server, because it just doesn't serve anything. (Same goes for many other OSes, including the other free BSDs and many Linux distros). Few people use a default Windows install on a server either, because they know what services they want to offer to the public, and DCOM might not be one of them.
In general, I think it is about as much work to make an OpenBSD server do exactly what you want than it is to make a Windows one. The difference is what happens when you make a mistake - in the OpenBSD case, you failed to enable something properly, which will be easy to detect by clients complaining; on Windows, everything keeps working, and you only notice that too much is working when you are owned.
Thus, given that the study is about publically reachable servers, it comes down to a measurement of average admin braindeadness. The systems talked about are not home-user preinstalled vanilly systems, they are set up by people paid for keeping them working. In that light, I think it is not unthinkable that the percentage of idiots setting up a public server without being qualified and knowing what they are doing that use Linux is pretty hight - after all, "Linux is not hard for the average guy to use" and "Linux is great for servers" are both claims not unheard of... Just combine these marketing memes, and you have a timebomb.
Then again, this ignores that this particular study is really not worth discussing...
The basic Unix security model is horrible. Actually, the Windows model has been better since NT4, the difference has only been that Windows programmers and users don't bother to use it, while writing secure programs despite POSIX compatibility has often been tried.
The whole idea of one all-mighty superuser and a bunch of equally-created ordinary users is stupid. What you really want is a fine-grained role concept, or better, a capability-based system. The idea of "privileged ports" is outright dangerous, the only practical consequence is that network servers need to be able to write /etc/passwd to start up, while any attacker can just
fake the source port of IP packets, or use an OS that doesn't enforce priv
ports. The filesystem security attributes are rudimentary. Many APIs have
confusing or dangerous behaviour by default, and you cannot really call yourself
a unix-like system until you implement interfaces that simply cannot be safely
used (think gets(3)).
There is a reason why no self-respecting Unix-like OS today works solely with the ancient Unix ways of doing things. They all support extended file access control lists, fine-grained capabilities, more sophisticated authentication schemes like PAM, mandatory access control etc. (Linux may still require some kernel patch or the other for some of them, and BSDs other than FreeBSD 5 may also lack some of these features. But they all move in that direction.). The problem however is that they all try to be "plain Unix" by default, and "plain Unix" is bad, security-wise. I do not know any system that would actually use a sane capability scheme in the default install. Most Unix admins are probably not even aware of the tools they have.
In a sense, it would be way better to start from scratch with a new system, kind of like what Eros tries to do. Of course, this would mean not only using a completely new operating system, but completely new applications that benefit from it as well. This is not going to happen anytime soon, and from an administrators point of view, being an early adopter does not make any sense - a well debugged Unix app is still a better choice to get the job done than a from-scratch reimplementation that nobody but you uses.
The selling point for Unix today, unless you count Windows 98 as the only alternative, is not security, it is performance and backwards-compatibility. The latter is not a good foundation to build a long-time stategy upon.
The reason why KeyKOS wasn't mentioned is probably the same as the one for information on ITS, Genera and Multics not making it into the headline. Not being used by anyone it generally a good strategy for software to prevent being exploited.
Just like most commercial Unixes missing (which could be explained by them simply not being exploited, or at least no data being available on these break-ins) is pretty suspicious, the result that "the BSDs" are most secure is quite useless. We are talking about pretty different systems here - I guess that NetBSD and Mac OS X differ widely in their typical usage scenarios and the background of their admins, and that will certainly be reflected in how they get r00ted.
Of course, because the biggest security problem are clueless admins, and installing upgrades without testing them first is a sure sign of competence.
Oh, and the Vatican is a state of its own, too - with less then 1000 people on a whopping 3.2 square kilometers. It probably also has the lowest birth rate of all countries.