He's comparing the output of the encoders, once decoded. If he had a vorbis decoder that allowed him to get the information he needs, or course he could do a meaningful comparison. And it's the comparison I and probably many of us are most interested in. --
Re:There's really not much difference between the
on
GPG vs. PGP?
·
· Score: 2
Another plus for GPG in a unix environment is that it was designed to be used in unix. PGP works fine in unix of course, but its behavior can be a little strange since it was originally made to be used under DOS.
For example, pgp -kxa will prompt for the file it should write the key out to. gpg --export -a simply dumps the key to stdout, a behavior a unix person will find much more intuitive. --
Before I even get into this, I want to say that I have no idea if RMS is right about this. However, KDE's statement is clearly not logically sound:
The "solution" to this is simple: we remove the "tainted" code from kmidi and kghostview, release a "pure" version of each, then re-add those files. Since adding non-tainted code is fine, we would be
cleared.
Whoever wrote that needs to stop thinking like a computer programmer and start thinking like a lawyer. RMS is claiming that once you have violated the license to GPL'd software, your license to modify and distribute that software is revoked.
That software, not that particular string of bytes which you may (or may not) have violated the license of.
So let's assume he's right and walk through KDE's little recipe. (Read "hypothetically") before every third word, ok?):
we remove the "tainted" code from kmidi and kghostview
Ok so far, you now have some code that you wrote.
release a "pure" version of each
Ok, no problem, it's your code.
then re-add those files
Er, do what? You previously violated the license, so you have lost all rights to modify or distribute the code you violated the license of, according to RMS.
Since adding non-tainted code is fine, we would be
cleared.
And here is KDE's logical fallicy. The code they added back was still tainted. It's not the physical string of ones and zeros sitting on their hard drive that is "tainted", but instead, whatever a court of law would hold to be the same code. --
As others have pointed out, using testing will not be like upgrading to unstable every week.
I like to upgrade horrendously broken packages to unstable on wednesdays. If you happen to upgrade to unstable every thursday, you get a freshly broken system each week.
On the other hand, if you upgrade to testing each thursday, you won't get the nasty broken package I just uploaded.
Big difference.
"A new tree just seems like it will cause more work for the Debian people who(no offense) tend to move a little slowly already."
The really neat thing about AJ's work on testing is that it's intended to be populated automatically. It will surely create a bit more work, but he has all sorts of smart code that ties it in with our bug tracking system so it can find out that the package I uploaded last wednesday is buggy and shouldn't go to testing; and more code that makes it smart enough to realize that the other 10 packages I uploaded this week that depend on that new, very buggy package, cannot go into testing either. It's very cool.:-)
Great article. I do have one tiny little quibble this this:
Typically that's a nonprivileged "nobody" account. While this is never good, let's just note for the record that this is a read-only exploit unless the webserver is very poorly configured.
Access to any user on the system, even nobody, is still a very serious matter. Even if your web server is otherwise perfectly locked-down. Why?
Well, it automatically turns any other local exploits into effectively remote exploits. So an exploit in some dumb little suid game on your system, which would normally only let local users get root, suddenly mushrooms into an exploit that gives anyone root.
An attacker need only get in as user nobody, install a real backdoor, and wait. Eventually a local exploit will be found, and they can finish cracking the system. --
I suggest you think before _you_ post. I was saying if corel had bothered to contact any debian developer -- including me -- and shown us their system before it was released, we could have fixed their KDE problems in half an hour. --
Corel made some technical decisions to break compatability with Slink (if you were not careful).
That is 100% pure slashdot bullshit.
The ways Corel managed to produce broken debian packages that messed up upgrades from Corel Linux to Debian could have been fixed by any debian developer in about half an hour. Debian has ample infrastructure to allow people to do the kinds of things Corel needed to do; they neglected to learn about and use that infrastructure. --
So as an update to what Rob wrote, the
Ddebian web site now says "2.2 released!" all over it, and an announcement has indeed been posted to our announce list. Press conference tomorrow at LinuxWorld. It's real, folks.:-) --
There are, I would guesstimate, 5 or possibly 10 people working full time on Debian. I'm one of them since VA has hired me and a couple of other people to work on Debian.
But the money won't go to hiring someone to work on Debian. We'll probably use it to build up our infrastructure -- we can always use more disk space.
But, I just sort of have to look at that number and wonder how they manage to keep the all volnteer effort competitive with all the commercial Linux distributions
That's really quite simple. It's the same way the linux community as a whole manages to be competative with big compainies like Microsoft. We have a lot of people, and their odd hours here and there add up. And the people who work on it really care, are often at the top of their fields, and do things right. --
I have mailed this to the author of the paper under separate cover.
> I have not fully covered Slackware and Debian, with their ridiculously > slow release schedules.
I'm very disappointed on two levels: First that you provide such a comprehensive and useful report and yes omit one of the more popular linux distributions[6], and second that you have made such an erronous assumption about Debian's release methodology.
Your main mistake is that you have failed to realize that Debian releases timely security fixes, which are distributed to Debian users via the internet. Users can choose to configure their systems to receive these updates[1]. This makes release intervals orthagonal to whether users receive security fixes.
Moreover, Debian has _frequent_ minor releases. These releases consist mostly of security fixes, and they serve to get the security fixes out to fresh Debian installs, plus to anyone who installs from CD and does not set up their system to receive security fixes via the net. You may have missed these releases, since in Debian, "2.1" is a new major release (with an implied "r1"), while "2.1r2" is the first minor release -- an unusual nomecleture compared to the other distributions.
Interestingly, minor releases of Debian 2.1 have occurred more frequently than minor releases of Red Hat 6 (which, as you note, "shoves a new version out the door every 6 months like clockwork").
Debian 2.1 2.1r2 8 days 2.1r3 167 days 2.1r4 104 days 2.1r5 117 days
Red Hat 6.0 6.1 161 days 6.2 175 days
[ Interestingly, a poster on slashdot has numbers[5] that show that the other distribution you left out (Slackware) also releases just as frequently as Red Hat. ]
In light of these problems, I think it would be quite beneficial if you added Debian to your paper. Security announcement since 1998 are archived in both the archives of the debian-security-announce mailing list[3], and on http://security.debian.org/ (which also includes advisories from 1997). So, I dug up some numbers (I read the changelog pointed to by footnote 2, and counted security fixes. This is probably not as accurate as your numbers.)
Moving on to the second part of your paper, specific indicidents and how quickly distributions responded, I've looked up some data on Debian's responses.
Local root exploit in kernel 2.2.15, announced on June 8th. On June 12th, Debian announced[4] it had fixed the hole *before* the exploit was announced, and thus was not vulnerable.
fdmount, announced May 22. Debian has never installed it suid, and thus has never been vulnerable (as you noted -- thanks).
By the way, I think this section of your paper looked at too few holes to draw any real conclusions from. But Debian seems to have been near the head of the pack in this limited sampling.
In closing, I'd like to point out that the current 1 and a half 5 year -- not 2 year as you continually state -- gap between Debian 2.1 and 2.2 is so far an exception, and not -- as you continually imply -- a rule. Major Debian releases:
-- see shy jo, fond of lies, damn lies, and statistics
[1] (For instructions to configure a Debian system to receive such fixes, see for example, http://security.debian.org/, in the 5th paragraph.) [2] This information from ftp://ftp.debian.org/debian/dists/stable/Debian2.1 r5 [3] http://www.debian.org/Lists-Archives/debian-securi ty-announce-98/threads.htm http://www.debian.org/Lists-Archives/debian-securi ty-announce-99/threads.htm http://www.debian.org/Lists-Archives/debian-securi ty-announce-00/threads.htm [4] http://www.debian.org/security/2000/20000612 [5] http://slashdot.org/comments.pl?sid=00/07/25/14442 33&cid=141 [6] I'm not going to argue this in detail, but just see how people reacted to your ommissions on slashdot. Debian has a rather large mindshare, though its market share is less quantifiable. http://slashdot.org/article.pl?sid=00/07/25/144423 3&mode=nested
So who ever said a CLI was mathmatically oriented? It's not, it's linguistically oriented. And people are just as tuned toward language as toward space. --
Re:Where is this week's issue of Debian Weekly New
on
Ask 'Ian' From Debian
·
· Score: 1
I've nearly finished writing it. Last week's issue didn't happen, when I overslept. --
There are already free tools like aide that do the same job tripwire does. I don't have personal experience with any of them, so I cannot vouch for their quality, but I've heard good things about aide.
Tripwire cannot be open source for linux alone. Either it is open source, in which case it follows the rules of the open source definition, including rule 8, "License Must Not Be Specific to a Product." or, it is not open source at all. Of course, they are welcome to release a version of tripwire that only works in linux, and license it under the GPL -- but then any hacker may go make it work on another OS without violating that copyright.
The more I think about this, the more I feel my really long-term goal (10 to 15 years) is to find something to apply my skills to, outside the realm of just plain computers.
It's easy to lose sight of this, but computers are tools to make it easier to do certain types of work. When you find yourself devoting all your time to improving the tools, and never actually using them except as a way to build better tools, something is out of wack. Especially when you consider that software is moving so fast that it's likely that your improvements will be inconsequential in a few years.
This is why I admire people who use computers -- and program -- as a tool to accomplish some larger goal, be it modeling supernovas or helping people in the third world. My goal is to find something that interests me enough so I can move on from improving my already excellent tools, to actually using them.
Unfortunatly, I haven't had much luck so far, but I'll keep looking.. --
(Warning: it is orange. If you "can't get past the color" then I guess you'll have to let big browser companies determine the fate of the web.)
I stopped reading here, disgusted.
Let me get this straight. If I want to help determine the fate of the web, I must allow a web page to force me to view it in a particular color? And this is about usability? From his comment, it would seem it's more about big comanies forcing you to see what they want you to see on the web. No thank you.
Well that's a good question. I'm a Debian developer, although I have never touched a S/390.
The main debian S/390 porter at the point is not an actual official Debian developer. Debian is supporting him though, with a mailing list, &etc because such a port is a very cool thing.
Before such a port is actually blessed as official debian, it would have to be 100% free, which would mean it would have to use the fully free kernel port. However, pragmatically it doesn't make sense to force someone to wait until that is ready before they begin porting debian over to the platform
So in summary, debian is, and will continue to be, 100% free software. A correlary to that is that you may port debian to run under non-free software, like IBM's kernel modules, if you want to. Just like people who don't have access to mainframes can run it under the non-free vmware. --
Slashdot Mirror
He's comparing the output of the encoders, once decoded. If he had a vorbis decoder that allowed him to get the information he needs, or course he could do a meaningful comparison. And it's the comparison I and probably many of us are most interested in.
--
Another plus for GPG in a unix environment is that it was designed to be used in unix. PGP works fine in unix of course, but its behavior can be a little strange since it was originally made to be used under DOS.
For example, pgp -kxa will prompt for the file it should write the key out to. gpg --export -a simply dumps the key to stdout, a behavior a unix person will find much more intuitive.
--
--
Thank's for you're help!
--
.. That simply displays, each day, everything that appeared on usenet on the same day in 1981.
--
You're going to use maybe 10% of that ISO you're downloading.
Our mirror network, on the other hand, can deal with anything you're likely to throw at it.
--
As others have pointed out, using testing will not be like upgrading to unstable every week.
:-)
I like to upgrade horrendously broken packages to unstable on wednesdays. If you happen to upgrade to unstable every thursday, you get a freshly broken system each week.
On the other hand, if you upgrade to testing each thursday, you won't get the nasty broken package I just uploaded.
Big difference.
"A new tree just seems like it will cause more work for the Debian people who(no offense) tend to move a little slowly already."
The really neat thing about AJ's work on testing is that it's intended to be populated automatically. It will surely create a bit more work, but he has all sorts of smart code that ties it in with our bug tracking system so it can find out that the package I uploaded last wednesday is buggy and shouldn't go to testing; and more code that makes it smart enough to realize that the other 10 packages I uploaded this week that depend on that new, very buggy package, cannot go into testing either. It's very cool.
--
Well, it automatically turns any other local exploits into effectively remote exploits. So an exploit in some dumb little suid game on your system, which would normally only let local users get root, suddenly mushrooms into an exploit that gives anyone root.
An attacker need only get in as user nobody, install a real backdoor, and wait. Eventually a local exploit will be found, and they can finish cracking the system.
--
I suggest you think before _you_ post. I was saying if corel had bothered to contact any debian developer -- including me -- and shown us their system before it was released, we could have fixed their KDE problems in half an hour.
--
Corel made some technical decisions to break compatability with Slink (if you were not careful).
That is 100% pure slashdot bullshit.
The ways Corel managed to produce broken debian packages that messed up upgrades from Corel Linux to Debian could have been fixed by any debian developer in about half an hour. Debian has ample infrastructure to allow people to do the kinds of things Corel needed to do; they neglected to learn about and use that infrastructure.
--
You're obviosly not tried debian 2.2.
--
So as an update to what Rob wrote, the Ddebian web site now says "2.2 released!" all over it, and an announcement has indeed been posted to our announce list. Press conference tomorrow at LinuxWorld. It's real, folks. :-)
--
Anyway, we've discussed it less than you would expect so far. Common views include:
--
Kde is still not in debian, nor in non-free.
--
I don't think I'm going to touch this post, except to say you're sure to enjoy our next release, after potato.
As for the sig, it's a brainteaser -- figure it out yourself..
--
Well the user who needs the new feature is welcome to download it from unstable and use it.
Which is better than burdening everyone who doesn't need the new feature, when it turns out to be full of bugs.
--
Well, since we've never been in the red, that's hardly a problem.
--
There are, I would guesstimate, 5 or possibly 10 people working full time on Debian. I'm one of them since VA has hired me and a couple of other people to work on Debian.
But the money won't go to hiring someone to work on Debian. We'll probably use it to build up our infrastructure -- we can always use more disk space.
But, I just sort of have to look at that number and wonder how they manage to keep the all volnteer effort competitive with all the commercial Linux distributions
That's really quite simple. It's the same way the linux community as a whole manages to be competative with big compainies like Microsoft. We have a lot of people, and their odd hours here and there add up. And the people who work on it really care, are often at the top of their fields, and do things right.
--
I have mailed this to the author of the paper under separate cover.
1 r5 i ty-announce-98/threads.htm i ty-announce-99/threads.htm i ty-announce-00/threads.htm 2 33&cid=141 3 3&mode=nested
> I have not fully covered Slackware and Debian, with their ridiculously
> slow release schedules.
I'm very disappointed on two levels: First that you provide such a
comprehensive and useful report and yes omit one of the more popular linux
distributions[6], and second that you have made such an erronous assumption
about Debian's release methodology.
Your main mistake is that you have failed to realize that Debian
releases timely security fixes, which are distributed to Debian users
via the internet. Users can choose to configure their systems to receive
these updates[1]. This makes release intervals orthagonal to whether users
receive security fixes.
Moreover, Debian has _frequent_ minor releases. These releases consist
mostly of security fixes, and they serve to get the security fixes out
to fresh Debian installs, plus to anyone who installs from CD and does
not set up their system to receive security fixes via the net. You may
have missed these releases, since in Debian, "2.1" is a new major
release (with an implied "r1"), while "2.1r2" is the first minor release
-- an unusual nomecleture compared to the other distributions.
Interestingly, minor releases of Debian 2.1 have occurred more frequently
than minor releases of Red Hat 6 (which, as you note, "shoves a new version
out the door every 6 months like clockwork").
Debian
2.1
2.1r2 8 days
2.1r3 167 days
2.1r4 104 days
2.1r5 117 days
Red Hat
6.0
6.1 161 days
6.2 175 days
[ Interestingly, a poster on slashdot has numbers[5] that show that
the other distribution you left out (Slackware) also releases just as
frequently as Red Hat. ]
In light of these problems, I think it would be quite beneficial if you
added Debian to your paper. Security announcement since 1998 are
archived in both the archives of the debian-security-announce mailing
list[3], and on http://security.debian.org/ (which also includes
advisories from 1997). So, I dug up some numbers (I read the changelog
pointed to by footnote 2, and counted security fixes. This is probably
not as accurate as your numbers.)
Release Security Alerts
2.1 1
2.1r2 16
2.1r3 19
2.1r4 5
2.1r5
Moving on to the second part of your paper, specific indicidents and how
quickly distributions responded, I've looked up some data on Debian's
responses.
Local root exploit in kernel 2.2.15, announced on June 8th.
On June 12th, Debian announced[4] it had fixed the hole *before*
the exploit was announced, and thus was not vulnerable.
fdmount, announced May 22.
Debian has never installed it suid, and thus has never been
vulnerable (as you noted -- thanks).
By the way, I think this section of your paper looked at too few holes to
draw any real conclusions from. But Debian seems to have been near the
head of the pack in this limited sampling.
In closing, I'd like to point out that the current 1 and a half 5 year --
not 2 year as you continually state -- gap between Debian 2.1 and 2.2 is
so far an exception, and not -- as you continually imply -- a rule. Major
Debian releases:
1.1
1.2 6 months
1.3 7 months
2.0 12 months
2.1 8 months
2.2 (19 months?)
--
see shy jo, fond of lies, damn lies, and statistics
[1] (For instructions to configure a Debian system to receive such fixes,
see for example, http://security.debian.org/, in the 5th paragraph.)
[2] This information from ftp://ftp.debian.org/debian/dists/stable/Debian2.
[3] http://www.debian.org/Lists-Archives/debian-secur
http://www.debian.org/Lists-Archives/debian-secur
http://www.debian.org/Lists-Archives/debian-secur
[4] http://www.debian.org/security/2000/20000612
[5] http://slashdot.org/comments.pl?sid=00/07/25/1444
[6] I'm not going to argue this in detail, but just see how people reacted to
your ommissions on slashdot. Debian has a rather large mindshare, though
its market share is less quantifiable.
http://slashdot.org/article.pl?sid=00/07/25/14442
--
So who ever said a CLI was mathmatically oriented? It's not, it's linguistically oriented. And people are just as tuned toward language as toward space.
--
I've nearly finished writing it. Last week's issue didn't happen, when I overslept.
--
--
The more I think about this, the more I feel my really long-term goal (10 to 15 years) is to find something to apply my skills to, outside the realm of just plain computers.
..
It's easy to lose sight of this, but computers are tools to make it easier to do certain types of work. When you find yourself devoting all your time to improving the tools, and never actually using them except as a way to build better tools, something is out of wack. Especially when you consider that software is moving so fast that it's likely that your improvements will be inconsequential in a few years.
This is why I admire people who use computers -- and program -- as a tool to accomplish some larger goal, be it modeling supernovas or helping people in the third world. My goal is to find something that interests me enough so I can move on from improving my already excellent tools, to actually using them.
Unfortunatly, I haven't had much luck so far, but I'll keep looking
--
I stopped reading here, disgusted.
Let me get this straight. If I want to help determine the fate of the web, I must allow a web page to force me to view it in a particular color? And this is about usability? From his comment, it would seem it's more about big comanies forcing you to see what they want you to see on the web. No thank you.
Gag me with a spoon.
--
Well that's a good question. I'm a Debian developer, although I have never touched a S/390.
The main debian S/390 porter at the point is not an actual official Debian developer. Debian is supporting him though, with a mailing list, &etc because such a port is a very cool thing.
Before such a port is actually blessed as official debian, it would have to be 100% free, which would mean it would have to use the fully free kernel port. However, pragmatically it doesn't make sense to force someone to wait until that is ready before they begin porting debian over to the platform
So in summary, debian is, and will continue to be, 100% free software. A correlary to that is that you may port debian to run under non-free software, like IBM's kernel modules, if you want to. Just like people who don't have access to mainframes can run it under the non-free vmware.
--