Slashdot Mirror

With the others, you replace them with other versions. Glibc isn't the *only* c library. Bash isn't the *only* shell (hell, it isn't even the only Bourne shell.)

Olson should know. He is one of a select few looking to review the current GPL and recommend updates for the public review process, which he says should happen before the end of the year.

Olson should know. He is one of a select few looking to review the current GPL and recommend updates for the public review process, which he says should happen before the end of the year.

Los Alamos Computers

I'm sure a lot of Slashdotters know the feeling when you get on the tech support line and feel like they treat you like you know nothing, when in fact they're the ones that don't know what they're talking about...

Well, with LAC, they'll treat you as a peer. First off, they request special instructions when you order, if you'd like a RAID setup, what runlevel you'd like to use, what display manager, what desktop environment, etc. They're also cooperative. For example, if I say something is broken, and tell them how I tested it to determine that, they don't run me through some inane troubleshooting sequence on the phone anyway. They picked up on what I was saying right away and shipped out a new part that day. Their response time to emails is very fast as well, about an hour or so in my experience.

Anyway, I'm not getting a kickback or anything, but it is the first time I've had a universally good experience with a computer vendor. I found out about them from a pretty good list of pre-installed Linux vendors over at the Debian site.

girls?

Yes. http://women.alioth.debian.org/

-Stephen

I wonder if the Debian guys and girls...

girls? are you're fuckin kidding me.

http://women.alioth.debian.org

Hope this helps.

Sure, their drivers are perfect. Must be why several other people have had problems with them too.

I got a powerbook after they were updated in Feburary. I was all set to wipe OS X and install Debian on it. In fact I did, and afterwords I couldn't, for the life of me, get the the mouse to work. This is my original post to the debian powerpc list:

http://lists.debian.org/debian-powerpc/2005/02/msg 00180.html

It turns out they changed their touchpad significantly for the newest versions of the powerbook. I eventually gave up and started using OS X. I'm pretty happy with it, but it's still a little different.

So if you have a newer powerbook (bought since Febuary), I'd look in to the mouse problem before I considered installing linux (yellow dog or otherwise).

you have the wrong guy mister. That and I'm not a homophobe. My *nix system is fine, I don't need a prettier looking one. Yes I know I'm just feeding a troll.

check it out

Everything is else just plain slow.

Just what we need to increase confusion. Look - I agree that there some justification to put this out, but do we *really* need yet another distro? A few well placed distros, each appealing to a market segment would be much better than this helter skelter rush for every man and their (yellow) dog to have a distro.

Wouldn't it be better to have 3 distros, one for techies, one for desktops and one for servers with paid with support. I know that those of you who use distro 'X' will yell "But {Debian,Mandrake,RHEL} doesn't quite match my requirements". Those 3 key distro's are very good, and I'm sure if theres some feature on some other distro, it will be available on one of these when all that hacking talent goes to just support them.

I'd rather we were all talking about and backing 3 very very good distros than over 100quite good ones.

While I am not sure I would go so far as to say ruby is "incredibly" slow, it is definately quite a bit slower than python. Check out http://shootout.alioth.debian.org/. There's a very big difference in speed for things like object creation, method calls, etc. Core language functionality that can't be made into a C module. And of course, python still lets you make C modules too, its still nice to have your normal code execute faster though.

You can submit your faster programs here

A quick search on KeyKOS makes one wonder: Does it have anything in common with GNU's microkernel efforts? Anyone cares to post a brief overview of KeyKOS, possibly in connection and/or comparison to Mach/HURD?

Short answer: yes it does, and it is actually one of the main reasons why I look forward to use Debian GNU/Hurd in the future. Let me quote my old post from January with some background and interesting links to more informations about KeyKOS:

Still, you can't block every hole in security. Sometimes you just have to hope, right?

Yes, you can. No you don't. Software is just an applied form of discrete mathematics. "Beware of bugs in the above code; I have only proved it correct, not tried it," as Donald Knuth once said. It is possible to present a formal proof of correctness for any algorithm. It is nearly impossible and certainly impractical when you have a big mess of spaghetti code like with most of software that is utter crap, but it is possible nonetheless when you know what are you doing and design appropriately, with very clean, small and isolated parts of your system responsible for enforcing its security policies. Take a look at such operating systems as KeyKOS and EROS. E.g. read Verifying Operating System Security paper by J. S. Shapiro and S. Weber: "This paper presents a proof of correctness of the EROS operating system architecture with respect to confinement." Read some essays by Norman Hardy, especially those on Capability Theory. This is hardly a new idea, see GNOSIS: A Prototype Operating System for the 1990s paper by Bill Frantz, Norm Hardy, Jay Jonekait and Charlie Landau, written more than 25 years ago. The bottom line is: it is certainly possible to have a 100% secure system, but developers don't bother because users don't care.

And here is a newer post of mine asking exactly your question about KeyKOS capabilities in connection to the recent development of The Hurd, in the First Program Executed on L4 Port of GNU/HURD discussion two months ago:

When the first programs run, it is just a matter of time before there is a functional L4 port of Debian GNU/Hurd (or just Debian GNU?). I really like the design of the Hurd, but what I'd like to see the most are not the "POSIX capabilities" but the real capabilities as described in the 1975 paper by Jerome Saltzer and Michael Schroeder, The Protection of Information in Computer Systems. (For those who don't know what am I talking about, I recommend starting from the excellent essay What is a Capability, Anyway? by Jonathan Shapiro, and then reading the capability theory essays by Norman Hardy. As a sidenone I might add that I find it amusing that people who say that there are other advantages than only Digital Restrictions Management of using TCPA/Palladium-like platforms usually quote security fe

A quick search on KeyKOS makes one wonder: Does it have anything in common with GNU's microkernel efforts? Anyone cares to post a brief overview of KeyKOS, possibly in connection and/or comparison to Mach/HURD?

Short answer: yes it does, and it is actually one of the main reasons why I look forward to use Debian GNU/Hurd in the future. Let me quote my old post from January with some background and interesting links to more informations about KeyKOS:

Still, you can't block every hole in security. Sometimes you just have to hope, right?

Yes, you can. No you don't. Software is just an applied form of discrete mathematics. "Beware of bugs in the above code; I have only proved it correct, not tried it," as Donald Knuth once said. It is possible to present a formal proof of correctness for any algorithm. It is nearly impossible and certainly impractical when you have a big mess of spaghetti code like with most of software that is utter crap, but it is possible nonetheless when you know what are you doing and design appropriately, with very clean, small and isolated parts of your system responsible for enforcing its security policies. Take a look at such operating systems as KeyKOS and EROS. E.g. read Verifying Operating System Security paper by J. S. Shapiro and S. Weber: "This paper presents a proof of correctness of the EROS operating system architecture with respect to confinement." Read some essays by Norman Hardy, especially those on Capability Theory. This is hardly a new idea, see GNOSIS: A Prototype Operating System for the 1990s paper by Bill Frantz, Norm Hardy, Jay Jonekait and Charlie Landau, written more than 25 years ago. The bottom line is: it is certainly possible to have a 100% secure system, but developers don't bother because users don't care.

And here is a newer post of mine asking exactly your question about KeyKOS capabilities in connection to the recent development of The Hurd, in the First Program Executed on L4 Port of GNU/HURD discussion two months ago:

When the first programs run, it is just a matter of time before there is a functional L4 port of Debian GNU/Hurd (or just Debian GNU?). I really like the design of the Hurd, but what I'd like to see the most are not the "POSIX capabilities" but the real capabilities as described in the 1975 paper by Jerome Saltzer and Michael Schroeder, The Protection of Information in Computer Systems. (For those who don't know what am I talking about, I recommend starting from the excellent essay What is a Capability, Anyway? by Jonathan Shapiro, and then reading the capability theory essays by Norman Hardy. As a sidenone I might add that I find it amusing that people who say that there are other advantages than only Digital Restrictions Management of using TCPA/Palladium-like platforms usually quote security fe

if you feel you have better python code to perform a task on the benchmark, feel free to submit it.

try http://shootout.alioth.debian.org/sandbox/benchmar k.php?test=mandelbrot&lang=all&sort=fullcpu=all for example.

producing code speaks louder than complaining that the benchmark is useless.

Python is a nice language, but it's excruciatingly slow. It's below Tcl on The Computer Language Shootout, which is telling.

Ruby is the second slowest scripting language (PHP is slower), and its by a huge margin. Python is significantly faster, and can often be sped up even more using psyco. Even better, use pike. Its about as fast as python with psyco, but its portable, more feature complete (?:, switch, for), and has a nice, sane C++ like syntax.

Check out http://shootout.alioth.debian.org/great/

...doesn't Debian have more exposure to running on alternative kernels? (i.e. Debian/NetBSD, Debian/HURD)

...doesn't Debian have more exposure to running on alternative kernels? (i.e. Debian/NetBSD, Debian/HURD)

That doesn't mean there's not some good stuff in Debian, but no admin I respect as as an admin would ever run Debian Unstable on a real server. And far fewer are running Stable, either, because it's so old; the world's moved on.

If only there were some sort of middle of the line release which was neither as cutting edge as unstable or as refined and old as stable...

This assessment of debian as out-of-date is a bogus argument, which I think is more often made by people who don't use debian, because it doesn't match the experience of using it. In actuality, debian offers you a range. Perhaps people would be less confused if instead of "unstable", "testing", and "stable", the releases were named "cutting-edge", "normal", and "old-sturdy". With apt_preferences, you even have the capability to choose packages from each release and hybridize the release you are using.

There are occasionally individual packages which lag behind other distributions, but similarly there are individual packages which are ahead of other distributions. Most of these differences are minor, average out, and work themselves in the long run.

Debian users don't vote for the DPL, Debian Developers do.

Any objections Debian people have against it should now be strongly justified rather than vaguely hinted at, so we can stop getting these silly bug reports which escalate a vague licence issue to full-scale removal without a proper discussion.

• The copyright license is terminated if you attempt to defend your patent rights against Apple.
• The license requires you to publish any local modifications if you deploy public services based on the Covered Code, which discriminates against a field of endeavour.
• The license includes a choice of venue clause forcing all licensees to accept the jurisdiction of the Northern District of California, which is discriminatory against persons located outside this district by exposing them to unequal legal expense.

What exactly does Bruce Perens do? ESR codes (well, he used to, sort of) and is a well known right-wing crackpot. Torvalds is a kernel engineer. RMS codes and goes on speaking tours. What does Perens do except sit around and armchair-quarterback the FOSS community? I can't think of a single qualification the guy has that makes him fit for the sort of "leadership" position the guy has fashioned for himself.

link

I wrote the Electric Fence malloc() debugger, and some pieces of Debian.

It is amazing what passes as insightful commentary now days. Others have commented on the statistics. I wanted to point out that Manoj is male. Perhaps you just assumed a female would occupy the Secretary position. We are underrepresented by female developers. We even have a dedicated mailing list to encourage more women to get involved with the Debian project. There are some very talented women already contributing to the project. We would like to see more though.

Whether any of this causes people to vote earlier remains to be seen. We use a Condorcet voting system and our typical motto is to 'vote early and vote often' which obviously has not been followed. We do have scaling issues with all our new developers over the last few years. The New Maintainer process is evolving to meet our needs. Maybe we just need to add another question asking the applicants how they feel about voting ;-)

It is amazing what passes as insightful commentary now days. Others have commented on the statistics. I wanted to point out that Manoj is male. Perhaps you just assumed a female would occupy the Secretary position. We are underrepresented by female developers. We even have a dedicated mailing list to encourage more women to get involved with the Debian project. There are some very talented women already contributing to the project. We would like to see more though.

Whether any of this causes people to vote earlier remains to be seen. We use a Condorcet voting system and our typical motto is to 'vote early and vote often' which obviously has not been followed. We do have scaling issues with all our new developers over the last few years. The New Maintainer process is evolving to meet our needs. Maybe we just need to add another question asking the applicants how they feel about voting ;-)

I'm a Debian developer, and I haven't voted -- yet. I'll cast my DPL vote towards the end of the cycle, as usual. Here's why:

• At the start of the cycle, I hadn't made up my mind. That's generally the case, except in one or two General Resolution votes where I already understood the issue under consideration (e.g. the non-free vote.)
• I haven't finished reading the candidate platforms and debate material yet. When voting opens, the project leader debates are just freshly over. This year, since once again I couldn't attend them live, I have to read them afterward, which takes time. Last year the debate was cancelled, because an email debate had already occurred on debian-vote -- same situation. Voting in Debian is just like voting anywhere else, you often have to do a lot of reading to understand the issues. Debian developers are shy about this right now, because the Social Contract clarification vote a ways back opened a huge unforseen can of worms concerning the freeness of documentation, and derailed Sarge again, until a second vote was undertaken to put the issue off until post-Sarge.
• With Sarge at a release tipping point (RC3 on the installer, and the Vancouver proposal still kicking around), I delay voting so I can see how those issues play out and adjust my planned vote.
• My local Debian meetup is unpredictable, and there might be one, where some longtime DDs show up and can enlighten me on the machinations going on in the Debian functional committees. You know, all those smoke-filled rooms in which the ftpmasters and application managers and buildd administrators meet to shoot heroin and plot how they're going to sabotage the next planned release date and sell the sparc porters into slavery or whatever.
• I am a lazy procrastinating bastard.

I'm a Debian developer, and I haven't voted -- yet. I'll cast my DPL vote towards the end of the cycle, as usual. Here's why:

• At the start of the cycle, I hadn't made up my mind. That's generally the case, except in one or two General Resolution votes where I already understood the issue under consideration (e.g. the non-free vote.)
• I haven't finished reading the candidate platforms and debate material yet. When voting opens, the project leader debates are just freshly over. This year, since once again I couldn't attend them live, I have to read them afterward, which takes time. Last year the debate was cancelled, because an email debate had already occurred on debian-vote -- same situation. Voting in Debian is just like voting anywhere else, you often have to do a lot of reading to understand the issues. Debian developers are shy about this right now, because the Social Contract clarification vote a ways back opened a huge unforseen can of worms concerning the freeness of documentation, and derailed Sarge again, until a second vote was undertaken to put the issue off until post-Sarge.
• With Sarge at a release tipping point (RC3 on the installer, and the Vancouver proposal still kicking around), I delay voting so I can see how those issues play out and adjust my planned vote.
• My local Debian meetup is unpredictable, and there might be one, where some longtime DDs show up and can enlighten me on the machinations going on in the Debian functional committees. You know, all those smoke-filled rooms in which the ftpmasters and application managers and buildd administrators meet to shoot heroin and plot how they're going to sabotage the next planned release date and sell the sparc porters into slavery or whatever.
• I am a lazy procrastinating bastard.

I'm a Debian developer, and I haven't voted -- yet. I'll cast my DPL vote towards the end of the cycle, as usual. Here's why:

• At the start of the cycle, I hadn't made up my mind. That's generally the case, except in one or two General Resolution votes where I already understood the issue under consideration (e.g. the non-free vote.)
• I haven't finished reading the candidate platforms and debate material yet. When voting opens, the project leader debates are just freshly over. This year, since once again I couldn't attend them live, I have to read them afterward, which takes time. Last year the debate was cancelled, because an email debate had already occurred on debian-vote -- same situation. Voting in Debian is just like voting anywhere else, you often have to do a lot of reading to understand the issues. Debian developers are shy about this right now, because the Social Contract clarification vote a ways back opened a huge unforseen can of worms concerning the freeness of documentation, and derailed Sarge again, until a second vote was undertaken to put the issue off until post-Sarge.
• With Sarge at a release tipping point (RC3 on the installer, and the Vancouver proposal still kicking around), I delay voting so I can see how those issues play out and adjust my planned vote.
• My local Debian meetup is unpredictable, and there might be one, where some longtime DDs show up and can enlighten me on the machinations going on in the Debian functional committees. You know, all those smoke-filled rooms in which the ftpmasters and application managers and buildd administrators meet to shoot heroin and plot how they're going to sabotage the next planned release date and sell the sparc porters into slavery or whatever.
• I am a lazy procrastinating bastard.

Same anonymous coward here...

I agree with you that Debian is not meant for everyone and that the zealots are fools to market it as such. I run Debian Unstable, but personally I'm glad there are distros like Redhat and Mandrake, and I think they play an important role in the Linux community.

But I also think Debian plays an important role, albeit a more behind-the-scenes role, and it's a role the Debian Developers are very self-aware of. Much of the discussion lately on Debianplanet.org and within the community has been about dropping the release cycle altogether and letting distros like Ubuntu, etc. worry about a release cycle. This indicates that many of Debian's developers do not see their distro as a user-end product.

But this is the thing that really annoys me about this entire thread. Everyone is dissing Debian and moaning and groaning about how no one voted because "no one cares" when there are much clearer reasons for Debian developers to be disillusioned.

For one, the ftpmasters/release team recently proposed to drop about half of the supported architectures. Also, there was fuss over changes to the social contract. Finally, there are just more candidates than usual for developers to deliberate over (six!) and the decisions that are being debated by the candidates have a bigger impact than usual on the future of Debian. This is an important election for the DPL so I think the developers are just taking their times to make a decision. I think as usual with Debian, it's not that "no one cares"...it's that people care too much!

Same anonymous coward here...

I agree with you that Debian is not meant for everyone and that the zealots are fools to market it as such. I run Debian Unstable, but personally I'm glad there are distros like Redhat and Mandrake, and I think they play an important role in the Linux community.

But I also think Debian plays an important role, albeit a more behind-the-scenes role, and it's a role the Debian Developers are very self-aware of. Much of the discussion lately on Debianplanet.org and within the community has been about dropping the release cycle altogether and letting distros like Ubuntu, etc. worry about a release cycle. This indicates that many of Debian's developers do not see their distro as a user-end product.

But this is the thing that really annoys me about this entire thread. Everyone is dissing Debian and moaning and groaning about how no one voted because "no one cares" when there are much clearer reasons for Debian developers to be disillusioned.

For one, the ftpmasters/release team recently proposed to drop about half of the supported architectures. Also, there was fuss over changes to the social contract. Finally, there are just more candidates than usual for developers to deliberate over (six!) and the decisions that are being debated by the candidates have a bigger impact than usual on the future of Debian. This is an important election for the DPL so I think the developers are just taking their times to make a decision. I think as usual with Debian, it's not that "no one cares"...it's that people care too much!

He's back in the running, and I just tossed him my vote, and you should, too:

http://www.debian.org/vote/2005/platforms/branden

A big part of the problem is that they guy that a *lot* of users and developers would like to see run didn't...Long live Overfiend.

What are you talking about? Branden's running.

A big part of the problem is that they guy that a *lot* of users and developers would like to see run didn't...Long live Overfiend.

What are you talking about? Branden's running.

Bug 280859. The packager forgot to package the runtime library FFS. 138 days old. Unfixed.

Hi, my apologies for the late response.

After the original report came in, I had a moment of doubt, and went back to
check through the APSL 2.0. I came to pretty much the same conclusion (but I
do think there needs to be some kind of review of the DFSG and commonly used
new licenses, cf. Matthew's reply, yada yada).

Here's what I'm going to do about it:

* Propose that we remove howl from the archive in its entirety. It is not
the most beautiful implementation, and it does not have enormous buy-in
throughout the FOSS community so far (only 31 rdepends in sid atm).

* Talk to the Debian GNOME team about how much pain this will inflict on
them, offer to buy beer for them, etc.

* Make a public statement about howl's removal, in the hopes of inspiring
new, Free implementations to be finished (or written).

"When there's public debate and mass hysteria, that's when the patches
roll in." - Michael Meeks

Bug 280859. The packager forgot to package the runtime library FFS. 138 days old. Unfixed.

Hi, my apologies for the late response.

After the original report came in, I had a moment of doubt, and went back to
check through the APSL 2.0. I came to pretty much the same conclusion (but I
do think there needs to be some kind of review of the DFSG and commonly used
new licenses, cf. Matthew's reply, yada yada).

Here's what I'm going to do about it:

* Propose that we remove howl from the archive in its entirety. It is not
the most beautiful implementation, and it does not have enormous buy-in
throughout the FOSS community so far (only 31 rdepends in sid atm).

* Talk to the Debian GNOME team about how much pain this will inflict on
them, offer to buy beer for them, etc.

* Make a public statement about howl's removal, in the hopes of inspiring
new, Free implementations to be finished (or written).

"When there's public debate and mass hysteria, that's when the patches
roll in." - Michael Meeks

I installed debian 2.2 once, and learned a lot in the process. Had dial-up, so upgrading was difficult. Then I copied the installation to several other hard drives of various sizes (for the debian partition) and made improvements that I then had to backtrack to the others.
Now, I have gotten on the Knoppix bandwagon, and probably won't be going back to a hard drive Debian installation again, although I still have one running very well, and use it occasionally.
Thanks, debian, for apt-get, and for the many many packages that can be downloaded. There's a little debian in all of us.

It feels like the HURD of distros.

I went to the Debian website, but I didn't find where to cast my vote.
Maybe that's why there are so few votes.

Apple laptops are effectively unusable for unix users.

I am a long-time Unix user. That means I need to have the Ctrl key to the left of the A key. This is a genuine need, not merely a want; it is based upon ergonomics. The Ctrl key is heavily used in unix, and it must be easily accessable. It cannot be off in the lower left corner of the keyboard where it is difficult to get at, and where it distorts the position of your left hand such that you can't easily type other keys while holding the Ctrl key down.

Apple desktop keyboards are now all USB. They are all OK. The CapsLock key can be re-mapped into a Ctrl key.

Unfortunately, even in this modern age, all Apple laptops have built-in ADB keyboards. The ADB keyboard is broken-by-design. It is, in general, not possible to remap the CapsLock key into a Ctrl key.

There are some exceptions, but they are horrible kludges. They are horrible kludges because the original design of the ADB keyboard was a horrible kludge. The correct solution would be for Apple to re-design their laptop motherboards to use built-in USB keyboards. This hasn't happened yet. If you run Linux, use Debian's solution. For Mac OS X users, uControl works. There are no solutions (that I know of) for either NetBSD or OpenBSD. Please note once again that the "solutions" above are in fact kludges, because of the original bad design of the ADB keyboard.

Apple provides a technical note on how to remap the keyboard, but provides no solution to the hardware problems caused by the design of the ADB keyboard. This tech note helps foreign language users, but does nothing for the CapsLock/Ctrl problem.

Apple has now lost three opportunities to sell me hardware. I really wanted an Apple laptop for their superior battery life, and for the PowerPC with Altivec CPU. (The Altivec is vastly superior to the x86 line for DSP.) Because I can't live with the broken-by-design built-in ADB keyboard in all Apple laptops, Sony and IBM sold me laptops instead. If Apple fixes this problem, they will sell me a PowerBook next year; if they don't, I'll still be running OpenBSD on x86 hardware, and wishing I could use a Mac.

Checkout MegaHal. It's not quite AI based but has an interesting way of simulating conversation. I find it more fun to talk to than ALICE.

http://megahal.alioth.debian.org/ MegaHal's homepage

http://lists.debian.org/debian-devel-announce/2005 /03/msg00012.html Some info about the upcoming release.

This isn't as much the amount of platforms supported that slows down debian than the number of packages in the distribution.

Check out what Steve Langasek has to say about platform porting:

The four most common porting problems for software are endianness (differs between i386/amd64 and powerpc), word size (differs between i386/powerpc and amd64), char signedness (differs between i386/amd64 and powerpc), and use of non-PIC code in shared libs (which is a problem on *all* non-i386 platforms). A fifth, less significant portability issue involves arm-specific weirdness with floating point handling, which affects only a handful of packages that try to do their own direct manipulation of floats.

So which portability problems are the ones that we waste time fixing code for?

If you want to move a single application back and forth across displays, you're looking for xmove.

http://gforge.org/ - based on an OSS sourceforge version. this should cover the cvs, documentation, etc needs for any project.
its also getting to be quite popular eg rubyforge, http://alioth.debian.org/ etc.

Until they actually release an OS, all this discussion is pretty much theoretical. The horizons are fuzzy because we can't actually run the damned thing to refine it.

Then allow me to part the fog with a working release: http://www.debian.org/ports/hurd/hurd-cd

Please note that that is not an "official" release, but it should run.

An easier choice is to use the Bochs PC emulator and Hurd disk image, available here.

There are exceptions where you can link to a GPL lib and it is acceptable. An example would be the libc6 library

Let me stop you right there and point and out that libc is actually LGPL...

As for the MySQL client API, it is whatever the license of that package dictates (I'll leave that up to you to check...).

I hate to say it but the x86, powerpc, and sparc versions should be ahead and have a later version then the others.

There is a recent proposal being discussed in the Debian community which would do this. The idea is to establish a set of criteria to determine which architectures should be officially released. All of the other architectures would still be available, but only the official architectures would be part of the release process.

The architectures that currently meet the critera are ia32, ia64, amd64 and PPC. I think what knocked Sparc out was the requirement that 98% of the Debian packages build on the platform, so that's something people interested in Sparc could fix.

> I've e-mailed debian-security-private directly

From the FAQ - the proper place to send it is to security@debian.org

Well, actually, you are incorrect. Testing does get security updates. I doubt they are made available as quickly as the security fixes to stable, but I guess that depends on the individual package maintainer.

You can see my apt source for debian (TESTING)
security updates.

http://security.debian.org/debian-security/dists/t esting/