linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* RE: Flame Linus to a crisp!
@ 2003-04-24 22:10 Downing, Thomas
  2003-04-24 22:36 ` Jamie Lokier
  0 siblings, 1 reply; 130+ messages in thread
From: Downing, Thomas @ 2003-04-24 22:10 UTC (permalink / raw)
  To: Jamie Lokier; +Cc: Daniel Phillips, Kernel Mailing List

> From: Daniel Phillips [mailto:phillips@arcor.de]
> > To join a game, you'd have to be able to prove you're running code
> > that is secure all the way from boot to reboot, where everything
> > from network driver to physics engine is known to be compiled from
> > open source that all participants agree is good.
> 
> How would you do that?  What's the protocol?

Public key exchange lets you communicate securely over an insecure link.

> So, the game server and the BIOS have a chat, through the operating
> system (which counts as an insecure link), and the BIOS tells the
> server that it is the correct DRM BIOS, and it loaded a signed kernel.

How does the server _know_ that the BIOS is what it says it is? Again,
what's the protocol?  Saying that they 'have a chat' is bypassing
the hard bits.

If I have the BIOS, any secrets it holds are now knowable to me.
This means that any protocol that relies on a secret in the BIOS is
broken from the start.  So now you need to define a protocol which
does not rely on any secret being known to the BIOS.  What is this
protocol?

> Substitute "broadcaster" for "game server" and you see that the same
? methods ensure that you really have the TV switched on and you are not
> recording the show.

The proposed 'end-to-end' copy protection schemes for entertainment
media etc, rely on proprietary _hardware_.  This is still beatable,
although at a higher cost.  Nor is the problem quite parallel.  The
broadcast problem is 'how do we keep content encrypted till the
last possible moment?' and 'how do we keep the decryption engine tamper
proof reverse engineering proof'.  The first part is easy.  The second
part is not possible in an absolute sense.  It can only be made more 
or less dificult.  Hence the DMCA etc.

> They also ensure you are not recording a screenshot of a politically
> sensitive article about Iraq that was accidentally shown on CNN's web
> site for 10 minutes.  We can't have people recording things like that.

God forbid! ;-)


^ permalink raw reply	[flat|nested] 130+ messages in thread
* RE: Flame Linus to a crisp!
@ 2003-04-28  9:30 Martin_List-Petersen
  0 siblings, 0 replies; 130+ messages in thread
From: Martin_List-Petersen @ 2003-04-28  9:30 UTC (permalink / raw)
  To: viro; +Cc: linux-kernel


>> We've seen this before. Remember when dongles were plentiful in the
>> software world? People literally had problems with having dongles on top
>> of dongles to run a few programs. They all died out, simply because
>> consumers _hate_ that kind of lock-in thing.
>
>Not all of them.  And they had spawned similar software turds - ask
>any sysadmin who'd dealt with FlexLM and its ilk and you'll hear a
>_lot_ of horror stories about the induced inconveniencies and breakage.
 
Uhh .... don't give me that. ModelSim is just one of these FlexLM horrors.
The best thing is, if you have multiple licenses on one dongle (to share on
the network) and the darn thing doesn't release them, when people stop using
the software.

Or people who simply couldn't get the stuff to work, because of some silly
printerport issues (voltage issues, whatsoever).

Regards,
Martin List-Petersen


^ permalink raw reply	[flat|nested] 130+ messages in thread
* RE: Flame Linus to a crisp!
@ 2003-04-25 12:57 Downing, Thomas
  0 siblings, 0 replies; 130+ messages in thread
From: Downing, Thomas @ 2003-04-25 12:57 UTC (permalink / raw)
  To: John Bradford, jamie; +Cc: core, miller, phillips, wli, torvalds, linux-kernel

From: John Bradford [mailto:john@grabjohn.com]

>> > I'd like to see an x86 completely in perf board. I thought my high
>> > school digital electronics type stuff looked bad...
>> 
>> You could do it nowadays using dynamic binary translation, and an
>> absurdly simple CPU capable of accessing a large memory.  You'd need a
>> DIMM for the large memory, but get away with discrete logic for the
>> CPU if you really wanted to.
>> 
>> At perf board sizes using discrete logic, expect it run run quite slow :)
>
> Could we not take this idea to it's logical extreme, and simply
> calculate the results of every opcode, on every value, for every state
> of all of the registers, and store them in an array of DIMMs, and
> simply look up the necessary results?  I.E. a cpu which is one _huge_
> look up table :-).
>
> John.

NOW your'e talking! Alan Turing meets Julian Barbour.

^ permalink raw reply	[flat|nested] 130+ messages in thread
* RE: Flame Linus to a crisp!
@ 2003-04-25 12:41 Downing, Thomas
  0 siblings, 0 replies; 130+ messages in thread
From: Downing, Thomas @ 2003-04-25 12:41 UTC (permalink / raw)
  To: Daniel Phillips, Alan Cox; +Cc: Jamie Lokier, Linux Kernel Mailing List

From: Daniel Phillips [mailto:phillips@arcor.de]

>On Fri 25 Apr 03 00:45, Alan Cox wrote:
>> On Iau, 2003-04-24 at 22:42, Daniel Phillips wrote:
>> > A more mundane goal would be to prevent the 3D driver from letting you
>> > see through polygons that are supposed to be opaque.
>>
>> In the MUD world we solved that by not telling anyone about objects they
>> can't see.
>
> Doing the visibility calculations on the server, down to the pixel, is 
> possible but not really practical.
>
> Regards,
>
> Daniel

Just goes to show that the VDU was the acme of the compute world,
it's been all down hill since... ;-)

^ permalink raw reply	[flat|nested] 130+ messages in thread
* RE: Flame Linus to a crisp!
@ 2003-04-25 12:36 Downing, Thomas
  2003-04-27  7:25 ` Adrian Bunk
  0 siblings, 1 reply; 130+ messages in thread
From: Downing, Thomas @ 2003-04-25 12:36 UTC (permalink / raw)
  To: Adrian Bunk, Linus Torvalds; +Cc: William Lee Irwin III, Kernel Mailing List

From: Adrian Bunk [mailto:bunk@fs.tum.de]

>On Wed, Apr 23, 2003 at 10:43:37PM -0700, Linus Torvalds wrote:
>>...
>> And hey, the fact is (at least as far as I'm concerned), that as long as
>> you make the hardware, you can control what it runs.
>>...
>
>Linux is currently widely used and through this there comes some power. 
>Let me try to make examples where this might be important:

You cast these comments in the context of corporate use, so -

The primary reason corporations are beginning to adopt Linux is TCO
- and such adoption is in its early stages, though growing.  Such
adoption is _only_ to the extent that Linux will run specific
applications.

Companies do _not_ adopt Linux because it is the only OS on which
their critical applications run.  They don't adopt it because it's
the coolest OS out there.  All the corporate required applications 
run on other O$'s.  If support for a facility percieved as desirable
or necessary (in this case, DRM)is not available in Linux due to the
terms of the GPL, corporations will drop Linux in a heartbeat.

Some companies (viz certain very large financial institutions) are
only now just beginning to write applications _on_ Linux.  When
Linux has a majority market share, with the rest of the market in
disarray, _then_ you have some power; but only for a limitted time.

^ permalink raw reply	[flat|nested] 130+ messages in thread
* RE: Flame Linus to a crisp!
@ 2003-04-25 12:23 Downing, Thomas
  0 siblings, 0 replies; 130+ messages in thread
From: Downing, Thomas @ 2003-04-25 12:23 UTC (permalink / raw)
  To: Jamie Lokier; +Cc: Daniel Phillips, Kernel Mailing List



-----Original Message-----
Jamie Lokier [mailto:jamie@shareable.org]

>Downing, Thomas wrote:
>> How does the server _know_ that the BIOS is what it says it is? Again,
>> what's the protocol?  Saying that they 'have a chat' is bypassing
>> the hard bits.
>> 
>> If I have the BIOS, any secrets it holds are now knowable to me.
>> This means that any protocol that relies on a secret in the BIOS is
>> broken from the start.  So now you need to define a protocol which
>> does not rely on any secret being known to the BIOS.  What is this
> protocol?
>
>What makes you think you can read the BIOS?
If it is a BIOS in the PC-compatible sense, of course I can.
>
>> The proposed 'end-to-end' copy protection schemes for entertainment
>> media etc, rely on proprietary _hardware_.
>
>Yes, that's the severe version of DRM that we're talking about, for
>the game server scenario.
I though that this was in reference to a way to solve Quake etc.
cheating in the current hardware environment.  I you pull in 
extra hardware, the equation changes.
>
>> This is still beatable, although at a higher cost.  Nor is the
>> problem quite parallel.  The broadcast problem is 'how do we keep
>> content encrypted till the last possible moment?' and 'how do we
>> keep the decryption engine tamper proof reverse engineering proof'.
>> The first part is easy.  The second part is not possible in an
>> absolute sense.  It can only be made more or less dificult.  Hence
>> the DMCA etc.
>
>We don't know for sure that it's not possible to make something
>reverse engineering proof.  Although all current CPUs require code to
>be decrypted at some point, there may be modules of computation that
>don't require that, so there would be no way to extract the secret key
>or decryption process in a useful way even when you can see every
>electronic signal in a device.  The jury is out on it, despite what
>slashdotters believe.
>
>-- Jamie

Depends on who sits on the jury.  With few if any exceptions, the top
people in the security field would agree with what I said.  That's not
because I'm brilliant, it's because I'm just parrotting back what
they have said.

As is often said, security is all shades of grey.  It may well be
possible to make a device that is so hard to reverse engineer and so
hard to hack, that it offers protection that lasts as long as the
effective market life of the thing it is protecting.  At that point
it is good enough.  Now you have a foundation on which to base
the required protocol.  You are now done from the theoretic side,
and this debate comes to an end; you have your Quake-cheat blocker.

But if you go on to consider the practical side, even now you have
only solved the easy part: the tough part is correctly implementing
the entire 'soft' chain from this device to the corresponding device
on the server.  Now _that's_ not easy.

^ permalink raw reply	[flat|nested] 130+ messages in thread
* Re: Flame Linus to a crisp!
@ 2003-04-24 21:55 Daniel Callahan
  0 siblings, 0 replies; 130+ messages in thread
From: Daniel Callahan @ 2003-04-24 21:55 UTC (permalink / raw)
  To: linux-kernel; +Cc: pochini

----
On 24-Apr-2003 Giuliano Pochini wrote:
Free software is free. You can do anything with it, the only contraint
is it must stay free. But cryptography plays a bad role here. Someone
can make hw that accepts only that peice of signed free software. You
have the hw, you have the binaries, you have the sources. But the
sources are completely useless. GPL allows the user to modify it, but
the hw doesn't run the modified copy. DRM can turns free software into
half-proprietary software. I don't like it at all, but I don't see any
solution.
----
The solution lies outside of the GPL.  Not that you're guilty of this, but 
somehow hackerdom has mixed the GPL in with 'the Right to free binaries' and 
'the Right to have compatible hardware'.  And those two Rights are as real as 
the brontosaurus, (i.e., they ain't, despite what many want to believe).  

Free binaries and compatible hardware are privileges.  In the case of 
hardware, that's a damn shame, but there it is.  Apart from mutilating the 
GPL to outlaw development on secured hardware, I can't see the solution 
coming from that direction.  (And even if GPL were modified to cover 
"activities other than copying, distribution and modification", all it would 
do is fork the license.  Linus would use the older license (I'm guessing), 
others would use the anti-DRM license, and Bill Gates would be ROTFLHAO.)

So there's no solution except to learn to live with it *unless* someone is 
brave and savvy enough to create a General Hardware License and found the 
Free Hardware Foundation.  And that still wouldn't make the DRM issue vanish 
-- GNU didn't wipe out proprietary software; it didn't even prevent the Mac 
from using FreeBSD.  It would just create the opportunity for a hardware 
hacker to do what has been done with Linux.

So, if anyone really is waiting for a sign to start the Free Hardware 
Foundation, consider Linus' email to be it.

Daniel.

^ permalink raw reply	[flat|nested] 130+ messages in thread
* RE: Flame Linus to a crisp!
@ 2003-04-24 20:39 Downing, Thomas
  2003-04-24 21:28 ` Jamie Lokier
  0 siblings, 1 reply; 130+ messages in thread
From: Downing, Thomas @ 2003-04-24 20:39 UTC (permalink / raw)
  To: Daniel Phillips, Kernel Mailing List


From: Daniel Phillips [mailto:phillips@arcor.de]

> To join a game, you'd have to be able to prove you're running code that is

> secure all the way from boot to reboot, where everything from network
driver 
> to physics engine is known to be compiled from open source that all 
> participants agree is good.

How would you do that?  What's the protocol?

^ permalink raw reply	[flat|nested] 130+ messages in thread
* RE: Flame Linus to a crisp!
@ 2003-04-24 12:36 Downing, Thomas
  2003-04-24 14:12 ` Timothy Miller
  0 siblings, 1 reply; 130+ messages in thread
From: Downing, Thomas @ 2003-04-24 12:36 UTC (permalink / raw)
  To: Kernel Mailing List

IMHO the DRM issue is not one that will be settled in either the software
or hardware area, but in the legal one.

What is driving DRM is the desire to control content beyond the point of
sale or distribution.  This cannot be done in any absolute way by
purely technological means.  Any such scheme only sets the bar for how
difficult it is to access the media in a way not intended by the vendor.

This is the motivation behind DMCA, EULA, and all their ilk.  It does not
matter how open the software _and_ hardware are, if those with a vested
interest in strong control of media use have such laws, deep pockets, and
a willingness to aggressively prosecute those the consider in violation
of such laws.

If my contention is correct, then it follows that effective action against
abuses of DRM and related technologies are primarily political and legal,
not technological.  This is not to say the technological side isn't
important - DeCSS is a case in point.

So this leads me to a position I would have, without reflection, not taken;
while I despise the current subversion of fair use and first point of sale
undertaken by MPAA, RIAA, et al., I agree with what I understand Linus to
say - DRM yes or no should not be mandated by license.

^ permalink raw reply	[flat|nested] 130+ messages in thread
[parent not found: <20030424041004$113a@gated-at.bofh.it>]
* Flame Linus to a crisp!
@ 2003-04-24  3:59 Linus Torvalds
  2003-04-24  4:40 ` Joel Jaeggli
                   ` (11 more replies)
  0 siblings, 12 replies; 130+ messages in thread
From: Linus Torvalds @ 2003-04-24  3:59 UTC (permalink / raw)
  To: Kernel Mailing List


Ok, 
 there's no way to do this gracefully, so I won't even try. I'm going to 
just hunker down for some really impressive extended flaming, and my 
asbestos underwear is firmly in place, and extremely uncomfortable.

  I want to make it clear that DRM is perfectly ok with Linux!

There, I've said it. I'm out of the closet. So bring it on...

I've had some private discussions with various people about this already,
and I do realize that a lot of people want to use the kernel in some way
to just make DRM go away, at least as far as Linux is concerned. Either by
some policy decision or by extending the GPL to just not allow it.

In some ways the discussion was very similar to some of the software
patent related GPL-NG discussions from a year or so ago: "we don't like
it, and we should change the license to make it not work somehow". 

And like the software patent issue, I also don't necessarily like DRM
myself, but I still ended up feeling the same: I'm an "Oppenheimer", and I
refuse to play politics with Linux, and I think you can use Linux for
whatever you want to - which very much includes things I don't necessarily
personally approve of.

The GPL requires you to give out sources to the kernel, but it doesn't
limit what you can _do_ with the kernel. On the whole, this is just
another example of why rms calls me "just an engineer" and thinks I have
no ideals.

[ Personally, I see it as a virtue - trying to make the world a slightly
  better place _without_ trying to impose your moral values on other 
  people. You do whatever the h*ll rings your bell, I'm just an engineer 
  who wants to make the best OS possible. ]

In short, it's perfectly ok to sign a kernel image - I do it myself
indirectly every day through the kernel.org, as kernel.org will sign the
tar-balls I upload to make sure people can at least verify that they came
that way. Doing the same thing on the binary is no different: signing a
binary is a perfectly fine way to show the world that you're the one
behind it, and that _you_ trust it.

And since I can imaging signing binaries myself, I don't feel that I can
disallow anybody else doing so.

Another part of the DRM discussion is the fact that signing is only the 
first step: _acting_ on the fact whether a binary is signed or not (by 
refusing to load it, for example, or by refusing to give it a secret key) 
is required too.

But since the signature is pointless unless you _use_ it for something,
and since the decision how to use the signature is clearly outside of the
scope of the kernel itself (and thus not a "derived work" or anything like
that), I have to convince myself that not only is it clearly ok to act on
the knowledge of whather the kernel is signed or not, it's also outside of
the scope of what the GPL talks about, and thus irrelevant to the license.

That's the short and sweet of it. I wanted to bring this out in the open, 
because I know there are people who think that signed binaries are an act 
of "subversion" (or "perversion") of the GPL, and I wanted to make sure 
that people don't live under mis-apprehension that it can't be done.

I think there are many quite valid reasons to sign (and verify) your
kernel images, and while some of the uses of signing are odious, I don't
see any sane way to distinguish between "good" signers and "bad" signers.

Comments? I'd love to get some real discussion about this, but in the end 
I'm personally convinced that we have to allow it.

Btw, one thing that is clearly _not_ allowed by the GPL is hiding private
keys in the binary. You can sign the binary that is a result of the build
process, but you can _not_ make a binary that is aware of certain keys
without making those keys public - because those keys will obviously have
been part of the kernel build itself.

So don't get these two things confused - one is an external key that is
applied _to_ the kernel (ok, and outside the license), and the other one
is embedding a key _into_ the kernel (still ok, but the GPL requires that
such a key has to be made available as "source" to the kernel).

			Linus


^ permalink raw reply	[flat|nested] 130+ messages in thread

end of thread, other threads:[~2003-04-28 14:19 UTC | newest]

Thread overview: 130+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-04-24 22:10 Flame Linus to a crisp! Downing, Thomas
2003-04-24 22:36 ` Jamie Lokier
  -- strict thread matches above, loose matches on Subject: below --
2003-04-28  9:30 Martin_List-Petersen
2003-04-25 12:57 Downing, Thomas
2003-04-25 12:41 Downing, Thomas
2003-04-25 12:36 Downing, Thomas
2003-04-27  7:25 ` Adrian Bunk
2003-04-25 12:23 Downing, Thomas
2003-04-24 21:55 Daniel Callahan
2003-04-24 20:39 Downing, Thomas
2003-04-24 21:28 ` Jamie Lokier
2003-04-24 21:42   ` Daniel Phillips
2003-04-24 22:45     ` Alan Cox
2003-04-24 23:59       ` Daniel Phillips
2003-04-25  9:07         ` Helge Hafting
2003-04-25 13:01       ` David Luyer
2003-04-25  8:13   ` Andreas Jellinghaus
2003-04-25 19:12     ` Jamie Lokier
2003-04-25 20:56       ` Andreas Jellinghaus
2003-04-25 21:50         ` Jamie Lokier
2003-04-24 12:36 Downing, Thomas
2003-04-24 14:12 ` Timothy Miller
2003-04-24 22:48   ` Werner Almesberger
2003-04-25 12:29   ` Ragnar Hojland Espinosa
2003-04-25 15:45     ` Timothy Miller
     [not found] <20030424041004$113a@gated-at.bofh.it>
2003-04-24  4:53 ` Tony 'Nicoya' Mantler
2003-04-24  3:59 Linus Torvalds
2003-04-24  4:40 ` Joel Jaeggli
2003-04-24  4:43 ` Greg KH
2003-04-24  4:57   ` Linus Torvalds
2003-04-24  5:02     ` Clemens Schwaighofer
2003-04-24  5:39       ` viro
2003-04-24  5:56         ` Valdis.Kletnieks
2003-04-24  8:46           ` Dax Kelson
2003-04-24  9:46         ` Clemens Schwaighofer
2003-04-24 10:54       ` Felipe Alfaro Solana
2003-04-25  0:07         ` Clemens Schwaighofer
2003-04-24  4:54 ` Andre Hedrick
2003-04-24  5:16   ` Linus Torvalds
2003-04-24 13:08     ` Shawn
2003-04-24 20:12       ` Kenneth Johansson
2003-04-24 17:32     ` Andreas Boman
2003-04-24 17:41       ` William Lee Irwin III
2003-04-24 19:39         ` Balram Adlakha
2003-04-26 17:05       ` Riley Williams
2003-04-24  5:02 ` Mark J Roberts
2003-04-24  5:13   ` Clemens Schwaighofer
2003-04-24  5:15 ` William Lee Irwin III
2003-04-24  5:43   ` Linus Torvalds
2003-04-24  6:15     ` William Lee Irwin III
2003-04-24  7:44       ` Jamie Lokier
2003-04-24  8:03         ` Jan-Benedict Glaw
2003-04-25  1:16           ` Jan Harkes
2003-04-25  1:35             ` Stan Bubrouski
2003-04-24  8:16         ` John Bradford
2003-04-24  8:31           ` Jamie Lokier
2003-04-24  8:59             ` John Bradford
2003-04-24  8:50           ` Jamie Lokier
2003-04-24 14:45           ` Linus Torvalds
2003-04-24 15:00             ` Jeff Garzik
2003-04-24 19:03             ` Daniel Phillips
2003-04-24 19:32               ` Timothy Miller
2003-04-24 19:22                 ` Linus Torvalds
2003-04-24 20:19                   ` Jamie Lokier
2003-04-24 20:35                   ` Timothy Miller
2003-04-24 19:39                 ` Balram Adlakha
2003-04-24 21:02                   ` Jamie Lokier
2003-04-24 18:58         ` Daniel Phillips
2003-04-24 21:08           ` Jamie Lokier
2003-04-24 21:37             ` Timothy Miller
2003-04-24 21:30               ` Jamie Lokier
2003-04-24 21:38                 ` John Bradford
2003-04-25  3:20                   ` Shawn
2003-04-25  5:47                     ` Jamie Lokier
2003-04-25  7:02                       ` John Bradford
2003-04-25  8:52                         ` Helge Hafting
2003-04-25 14:03                   ` Mike Dresser
2003-04-24 21:42                 ` Russell King
2003-04-25  6:08               ` Jan-Benedict Glaw
2003-04-25 11:46                 ` Antonio Vargas
2003-04-24 10:57     ` Giuliano Pochini
2003-04-24 22:51     ` Adrian Bunk
2003-04-24  7:55 ` Jamie Lokier
2003-04-24  8:37 ` Andreas Jellinghaus
2003-04-24  8:59   ` Jamie Lokier
2003-04-24 12:52     ` Andreas Jellinghaus
2003-04-24 15:37     ` Timothy Miller
2003-04-24 18:35       ` Alan Cox
2003-04-24 20:46         ` Timothy Miller
2003-04-24 20:50           ` Jamie Lokier
2003-04-24 21:03             ` Chris Adams
2003-04-24 22:29         ` Werner Almesberger
2003-04-24 22:41           ` Jamie Lokier
2003-04-24 22:54             ` Werner Almesberger
2003-04-25  0:26               ` Jamie Lokier
2003-04-24 22:41           ` Alan Cox
2003-04-27 14:21           ` Matthias Andree
2003-04-27 16:13             ` Stephan von Krawczynski
2003-04-24 19:23       ` Jamie Lokier
2003-04-24 19:50         ` Balram Adlakha
2003-04-24  8:57 ` Arjan van de Ven
2003-04-24  9:19   ` Russell King
2003-04-24 11:38     ` Shachar Shemesh
2003-04-24 17:46       ` Shachar Shemesh
2003-04-24 14:59   ` Linus Torvalds
2003-04-24 12:39 ` Mark Mielke
2003-04-24 15:53 ` Elladan
2003-04-24 18:31 ` Daniel Phillips
2003-04-24 23:15   ` Werner Almesberger
2003-04-25 11:28     ` Eric W. Biederman
2003-04-27  1:31       ` Werner Almesberger
2003-04-27  1:59         ` David Wagner
2003-04-25 14:37     ` Daniel Phillips
2003-04-25 15:17       ` Valdis.Kletnieks
2003-04-25 17:37       ` Werner Almesberger
2003-04-26 21:59         ` Daniel Phillips
2003-04-26 13:00     ` Geert Uytterhoeven
2003-04-26 18:22       ` Linus Torvalds
2003-04-26 18:41         ` viro
2003-04-26 18:48           ` Linus Torvalds
2003-04-28 14:20           ` John Stoffel
2003-04-26 19:23         ` Michael Buesch
2003-04-28 10:35         ` Andre Hedrick
2003-04-28 12:12           ` Jörn Engel
2003-04-28 14:01           ` Zack Gilburd
2003-04-28 14:30             ` Geert Uytterhoeven
2003-04-26 18:21   ` Rik van Riel
2003-04-26 23:34     ` Jamie Lokier
2003-04-27  3:59     ` Werner Almesberger
2003-04-24 20:16 ` Nils Holland

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).