* AWS applications and domain hosting @ 2005-06-26 9:36 Martin Dowie 2005-06-26 10:51 ` Adrian Knoth ` (3 more replies) 0 siblings, 4 replies; 16+ messages in thread From: Martin Dowie @ 2005-06-26 9:36 UTC (permalink / raw) If I wanted to buy a domain name (e.g. www.<my_domain>.co.uk) and wanted to run an AWS application within it, what should I ask for when purchasing such a domain from a web hosting company? Cheers -- Martin ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: AWS applications and domain hosting 2005-06-26 9:36 AWS applications and domain hosting Martin Dowie @ 2005-06-26 10:51 ` Adrian Knoth 2005-06-26 12:36 ` Jacob Sparre Andersen ` (2 subsequent siblings) 3 siblings, 0 replies; 16+ messages in thread From: Adrian Knoth @ 2005-06-26 10:51 UTC (permalink / raw) Martin Dowie <martin.dowie@btopenworld.com> wrote: > If I wanted to buy a domain name (e.g. www.<my_domain>.co.uk) and wanted > to run an AWS application within it, what should I ask for when > purchasing such a domain from a web hosting company? I guess your AWS application does the socket handling on its own? Then you surely cannot use some kind of "CGI-enabled webspace", as you usually can't bind to your application-specific ports (i.e. 80 which will probably already be in use by the hoster's apache) You should look for something like a root-server or at least some kind of user-mode-linux. Anything will suffice if it offers you the ability to create own processes with own port bindings. -- mail: adi@thur.de http://adi.thur.de PGP: v2-key via keyserver nichts auf Erden ist so schwer zu halten wie der Mund. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: AWS applications and domain hosting 2005-06-26 9:36 AWS applications and domain hosting Martin Dowie 2005-06-26 10:51 ` Adrian Knoth @ 2005-06-26 12:36 ` Jacob Sparre Andersen 2005-06-26 13:18 ` Larry Kilgallen 2005-06-26 19:29 ` Marius Amado Alves 3 siblings, 0 replies; 16+ messages in thread From: Jacob Sparre Andersen @ 2005-06-26 12:36 UTC (permalink / raw) Martin Dowie wrote: > If I wanted to buy a domain name (e.g. www.<my_domain>.co.uk) and > wanted to run an AWS application within it, what should I ask for > when purchasing such a domain from a web hosting company? The domain name itself is a completely independent "product". What you want from your hosting company is probably: a) Access to run your own network daemons. b) A platform you also run "at home" or access to compile your daemons locally. c) A webserver running as a proxy in front of your own daemon - and maybe also serving plain documents. As long as you have access to run your own network daemons on the server and to configure the proxy server, you shouldn't need root access on the machine. I run a system like that at <http://da.speling.org/random_words/> using Apache as the front end proxy server. Greetings, Jacob -- "Preserve wildlife, pickle a duck." ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: AWS applications and domain hosting 2005-06-26 9:36 AWS applications and domain hosting Martin Dowie 2005-06-26 10:51 ` Adrian Knoth 2005-06-26 12:36 ` Jacob Sparre Andersen @ 2005-06-26 13:18 ` Larry Kilgallen 2005-06-26 19:29 ` Marius Amado Alves 3 siblings, 0 replies; 16+ messages in thread From: Larry Kilgallen @ 2005-06-26 13:18 UTC (permalink / raw) In article <d9lsv1$i85$1@nwrdmz03.dmz.ncs.ea.ibs-infra.bt.com>, Martin Dowie <martin.dowie@btopenworld.com> writes: > If I wanted to buy a domain name (e.g. www.<my_domain>.co.uk) and wanted > to run an AWS application within it, what should I ask for when > purchasing such a domain from a web hosting company? You purchase domains from domain registrars. You buy web hosting from web hosting companies. Bundling the two can confuse things and reduce your flexibility. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: AWS applications and domain hosting 2005-06-26 9:36 AWS applications and domain hosting Martin Dowie ` (2 preceding siblings ...) 2005-06-26 13:18 ` Larry Kilgallen @ 2005-06-26 19:29 ` Marius Amado Alves 2005-06-26 22:46 ` Jacob Sparre Andersen 2005-06-26 23:00 ` Björn Persson 3 siblings, 2 replies; 16+ messages in thread From: Marius Amado Alves @ 2005-06-26 19:29 UTC (permalink / raw) To: comp.lang.ada On 26 Jun 2005, at 10:36, Martin Dowie wrote: > If I wanted to buy a domain name (e.g. www.<my_domain>.co.uk) and > wanted to run an AWS application within it, what should I ask for when > purchasing such a domain from a web hosting company? This subject greatly interests me too, as I plan to deploy AWS-based websites soon. I'll add what little I know, and join the original poster in asking for help. As others have told, yes, domain and hosting are formally separate. But many hosts offer registration, e.g. Yahoo!, and often the package price beats buying the two things separately. Anyway, the information related to AWS belongs to the hosting part only. I think that, unlike someone else said, a separate web server, or proxy (Apache), is neither required nor useful. The host system only has to open a port (?) to AWS sockets, right? And allow the AWS-based executable to run with the right parameters/permissions/ownership/priorities... It is these (currently, to me, slightly fuzzy) elements that I'd love to see well described. They are in the realm of the operating system, or at the most of some network software (IP?), but in any case below the level of webserving or Apache, right? ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: AWS applications and domain hosting 2005-06-26 19:29 ` Marius Amado Alves @ 2005-06-26 22:46 ` Jacob Sparre Andersen 2005-06-30 20:00 ` Randy Brukardt 2005-06-26 23:00 ` Björn Persson 1 sibling, 1 reply; 16+ messages in thread From: Jacob Sparre Andersen @ 2005-06-26 22:46 UTC (permalink / raw) Marius Amado Alves <amado.alves@netcabo.pt> writes: > This subject greatly interests me too, as I plan to deploy AWS-based > websites soon. I'll add what little I know, and join the original > poster in asking for help. > > As others have told, yes, domain and hosting are formally > separate. But many hosts offer registration, e.g. Yahoo!, and often > the package price beats buying the two things separately. That's not my experience. > Anyway, the information related to AWS belongs to the hosting part > only. Yes. > I think that, unlike someone else said, a separate web server, or > proxy (Apache), is neither required nor useful. The host system only > has to open a port (?) to AWS sockets, right? And allow the > AWS-based executable to run with the right > parameters/permissions/ownership/priorities... The benefit of running through a proxy are: a) You don't have to implement plain handing out of static files yourself. b) Your daemon doesn't have to run as "root" (which is the case, if you want it to bind directly to port 80 on the system). And a side-effect of b) is that you may be able to get a cheaper solution since you don't need a complete (virtual) computer just for your site. > It is these (currently, to me, slightly fuzzy) elements that I'd > love to see well described. In Unix you have to be "root" to act as a server on any port in the range 0-1023. IIRC, Apache is started as "root", but downgrades its privileges as soon as it has grabbed port 80. I don't know exactly how it is done. Anybody who wants to put a service directly on the network should understand how to run it with minimal privileges. Although Apache isn't perfect, it is good enough for most of my needs, so I can't see the point in reimplementing all of Apache, just because I want to solve some particular problems which Apache can't handle. Jacob -- "You've got to build bypasses!" ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: AWS applications and domain hosting 2005-06-26 22:46 ` Jacob Sparre Andersen @ 2005-06-30 20:00 ` Randy Brukardt 2005-06-30 20:45 ` Pascal Obry [not found] ` <m23bqzcrew.fsf@hugin.crs4.it> 0 siblings, 2 replies; 16+ messages in thread From: Randy Brukardt @ 2005-06-30 20:00 UTC (permalink / raw) "Jacob Sparre Andersen" <sparre@nbi.dk> wrote in message news:m2mzpc20tu.fsf@hugin.crs4.it... ... > The benefit of running through a proxy are: > > a) You don't have to implement plain handing out of static files > yourself. That's such a trivial task (assuming that AWS includes appropriate handling of HTTP commands) that's it's pretty silly not to include it and avoid extra failure points. > b) Your daemon doesn't have to run as "root" (which is the case, if > you want it to bind directly to port 80 on the system). That must be one of the few advantages of Windows. :-) I run the AdaIC.com server as a service under a heavily restricted user account (it does not have permission to access most of the disk or other partitions or systems). No special permissions changes needed. While Apache is a fine program, if you're doing light-duty work (and almost all web programs outside of Google are light-duty), an all-Ada solution will perform adequately and will be much less likely to break. After all, I believe in security by not having unused services on the system. Generalized systems like Apache simply provide too many "features" of little value to be safe. "Turning off" unused services via a configuration file is much less safe (someone could rewrite the configuration file) than not having the services around in the first place. And every additional program will provide an additional failure point. Randy. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: AWS applications and domain hosting 2005-06-30 20:00 ` Randy Brukardt @ 2005-06-30 20:45 ` Pascal Obry 2005-06-30 23:58 ` Jacob Sparre Andersen [not found] ` <m23bqzcrew.fsf@hugin.crs4.it> 1 sibling, 1 reply; 16+ messages in thread From: Pascal Obry @ 2005-06-30 20:45 UTC (permalink / raw) "Randy Brukardt" <randy@rrsoftware.com> writes: > > a) You don't have to implement plain handing out of static files > > yourself. > > That's such a trivial task (assuming that AWS includes appropriate handling > of HTTP commands) that's it's pretty silly not to include it and avoid extra > failure points. This is indeed one of the AWS example. A static file server is built in AWS using a 10 lines procedure callback: << function Get (Request : in AWS.Status.Data) return AWS.Response.Data is URI : constant String := AWS.Status.URI (Request); Filename : constant String := URI (2 .. URI'Last); begin if OS_Lib.Is_Regular_File (Filename) then return AWS.Response.File (Content_Type => AWS.MIME.Content_Type (Filename), Filename => Filename); else return AWS.Response.Acknowledge (Messages.S404, "<p>Page '" & URI & "' Not found."); end if; end Get; >> This handles the 404 message too. Note that such routine is provided by AWS, see AWS.Services.Page_Server. If this is not sufficient there is another hight level service which also handles directory browing, see AWS.Services.Directory. Pascal. -- --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://www.obry.net --| "The best way to travel is by means of imagination" --| --| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: AWS applications and domain hosting 2005-06-30 20:45 ` Pascal Obry @ 2005-06-30 23:58 ` Jacob Sparre Andersen 2005-07-01 6:01 ` Pascal Obry 0 siblings, 1 reply; 16+ messages in thread From: Jacob Sparre Andersen @ 2005-06-30 23:58 UTC (permalink / raw) Pascal Obry wrote: > Randy Brukardt wrote: > > > a) You don't have to implement plain handing out of static > > > files yourself. > > > > That's such a trivial task (assuming that AWS includes appropriate > > handling of HTTP commands) that's it's pretty silly not to include > > it and avoid extra failure points. > > This is indeed one of the AWS example. A static file server is built > in AWS using a 10 lines procedure callback: > > << > function Get (Request : in AWS.Status.Data) return AWS.Response.Data is > URI : constant String := AWS.Status.URI (Request); > Filename : constant String := URI (2 .. URI'Last); > begin > if OS_Lib.Is_Regular_File (Filename) then > return AWS.Response.File > (Content_Type => AWS.MIME.Content_Type (Filename), > Filename => Filename); > > else > return AWS.Response.Acknowledge > (Messages.S404, "<p>Page '" & URI & "' Not found."); > end if; > end Get; > >> I wasn't aware of the AWS.Response.File function. Does this it stream the file? Or do you have to load it into memory first? If AWS knows how to stream files, my point about handing out files is clearly not valid. How about handling of content negotiation? Can AWS also do that for me? (yes, I _could_ read the manual) Or will I get the pleasure of implementing that myself? My example, <http://da.speling.org/random_words/>, will continue to run as described, since we have many different web sites on that machine, and I wouldn't like to force the other administrators to use AWS just because I run a small service implemented with AWS. - And restarting the whole HTTP daemon every time I feel like tweaking my toy isn't healthy either. -- But with what I've learnt now, I might try to implement a proper (for my purposes) web server using AWS for my own site. Jacob -- "Computer Science is to Science, as Plumbing is to Hydrodynamics" ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: AWS applications and domain hosting 2005-06-30 23:58 ` Jacob Sparre Andersen @ 2005-07-01 6:01 ` Pascal Obry 2005-07-02 20:28 ` Jacob Sparre Andersen 0 siblings, 1 reply; 16+ messages in thread From: Pascal Obry @ 2005-07-01 6:01 UTC (permalink / raw) Jacob Sparre Andersen <sparre@nbi.dk> writes: > I wasn't aware of the AWS.Response.File function. Does this it stream > the file? No this routine does not stream the file but it does not read all the file in memory. It reads bit of it at a time and send it over. See the AWS.Net.Buffered. > Or do you have to load it into memory first? If AWS knows > how to stream files, my point about handing out files is clearly not > valid. It knows too. See AWS.Resources.Streams.Disk, AWS.Resources.Streams.Disk_Once, AWS.Resources.Streams.Memory, AWS.Resources.Streams.Memory, AWS.Resources.Streams.Memory.Zlib. Is that enough ? A Streams.Memory read/create byte directly from memory. Disk is obvious, Disk_Once read the file and then delete it (useful when sending over a file created from the user for example, you really want to delete it when sent). It is also possible to create your own stream method by deriving from AWS.Resources.Streams... And there is much much more ! Be sure to read the manual :) > How about handling of content negotiation? Can AWS also do that for > me? (yes, I _could_ read the manual) Or will I get the pleasure of > implementing that myself? Don't know what you are calling "content negotiation" ? Pascal. -- --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://www.obry.net --| "The best way to travel is by means of imagination" --| --| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: AWS applications and domain hosting 2005-07-01 6:01 ` Pascal Obry @ 2005-07-02 20:28 ` Jacob Sparre Andersen 2005-07-02 21:50 ` Pascal Obry 0 siblings, 1 reply; 16+ messages in thread From: Jacob Sparre Andersen @ 2005-07-02 20:28 UTC (permalink / raw) Pascal Obry wrote: > Jacob Sparre Andersen <sparre@nbi.dk> writes: > It knows too. See AWS.Resources.Streams.Disk, > AWS.Resources.Streams.Disk_Once, AWS.Resources.Streams.Memory, > AWS.Resources.Streams.Memory, AWS.Resources.Streams.Memory.Zlib. Is > that enough ? I think so. :) > And there is much much more ! Be sure to read the manual :) I thought I had done that already. It must be to long ago. > > How about handling of content negotiation? Can AWS also do that > > for me? (yes, I _could_ read the manual) Or will I get the > > pleasure of implementing that myself? > > Don't know what you are calling "content negotiation" ? It is specified somewhere in the HTTP 1.1 RFC. It means that the HTTP server chooses between different documents depending on the language and file type preferences of the client. Jacob -- "Sleep is just a cheap substitute for coffee" ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: AWS applications and domain hosting 2005-07-02 20:28 ` Jacob Sparre Andersen @ 2005-07-02 21:50 ` Pascal Obry 0 siblings, 0 replies; 16+ messages in thread From: Pascal Obry @ 2005-07-02 21:50 UTC (permalink / raw) Jacob Sparre Andersen <sparre@nbi.dk> writes: > It is specified somewhere in the HTTP 1.1 RFC. It means that the HTTP > server chooses between different documents depending on the language > and file type preferences of the client. I would say no. It does that for compressed vs. non-compressed document if the client support it. You could certainly do the same by requesting the proper header filed received from the client. Pascal. -- --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://www.obry.net --| "The best way to travel is by means of imagination" --| --| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595 ^ permalink raw reply [flat|nested] 16+ messages in thread
[parent not found: <m23bqzcrew.fsf@hugin.crs4.it>]
* Re: AWS applications and domain hosting [not found] ` <m23bqzcrew.fsf@hugin.crs4.it> @ 2005-07-01 1:45 ` Randy Brukardt 0 siblings, 0 replies; 16+ messages in thread From: Randy Brukardt @ 2005-07-01 1:45 UTC (permalink / raw) "Jacob Sparre Andersen" <sparre@nbi.dk> wrote in message news:m23bqzcrew.fsf@hugin.crs4.it... > Randy Brukardt wrote: ... > > While Apache is a fine program, if you're doing light-duty work (and > > almost all web programs outside of Google are light-duty), an > > all-Ada solution will perform adequately and will be much less > > likely to break. After all, I believe in security by not having > > unused services on the system. Generalized systems like Apache > > simply provide too many "features" of little value to be > > safe. "Turning off" unused services via a configuration file is much > > less safe (someone could rewrite the configuration file) than not > > having the services around in the first place. And every additional > > program will provide an additional failure point. > > Changing the configuration file is slightly easier than dumping in a > modified binary - but not so much that I think it is a fair critique. > > Still, you're right that with a system like Apache you're more likely > to have a few more features activated than you need. - On the other > hand; you reduce the risk of implementing new security holes, when you > use code more people have looked at, and my web server would still be > off-line, if I had had to implement it using AWS instead of just > installing and configuring Apache [1]. In one sense, I'd say it would be hard to argue. But in another sense, I rather disagree. HTTP is a fairly simple protocol. Since there is no state, it's pretty hard for it alone to be a security hole. Secondly, when your application is written in Ada (and you haven't suppressed checks), the opportunties for bugs causing trouble are quite small. Most bugs in the AdaIC.com server simply result in a message in the main log and a connect reset - not a security hole. So that only leaves systematic problems. For pure file serving, the only real problem is serving files that are outside of the web root. That isn't too hard to prevent (you do have to look for funny sequences of ".."), and anything unusual can just be rejected (unlike Apache's authors, I *know* that there aren't going to be any files with names including funny characters on our web site!). The real security problems come from the advanced stuff that you write, but you'll have those issues in any case if you've written using AWS. (Well, the worst problems come from Apache running Perl and PHP stuff, but you probably won't do that.) Of course, if you have to share the system as you mentioned, certainly use Apache as a front-end; it's certainly better than not writing your stuff in Ada in the first place. But if not, you can certainly run an all-Ada web server as I do for AdaIC.com -- it runs several domains, the spotlight server, and the Ada search engine without making much a dent in the machine. (Only the last takes much CPU time.) Randy. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: AWS applications and domain hosting 2005-06-26 19:29 ` Marius Amado Alves 2005-06-26 22:46 ` Jacob Sparre Andersen @ 2005-06-26 23:00 ` Björn Persson 2005-06-26 23:45 ` Marius Amado Alves 2005-06-29 2:42 ` tmoran 1 sibling, 2 replies; 16+ messages in thread From: Björn Persson @ 2005-06-26 23:00 UTC (permalink / raw) Marius Amado Alves wrote: > As others have told, yes, domain and hosting are formally separate. But > many hosts offer registration, e.g. Yahoo!, and often the package price > beats buying the two things separately. You might want to make sure that it's you and not the hosting company who owns the domain, so that you can change the hosting solution without losing your domain name. > I think that, unlike someone else said, a separate web server, or proxy > (Apache), is neither required nor useful. The host system only has to > open a port (?) to AWS sockets, right? And allow the AWS-based > executable to run with the right > parameters/permissions/ownership/priorities... If we're talking web servers, we're talking HTTP. HTTP builds on TCP which builds on IP. TCP has the notion of ports. A port is a number that serves to keep separate connections distinct. Clients need to know which port the server is listening for connections on. HTTP normally uses port 80. (TCP's "little sister" protocol UDP has an identical but separate set of ports.) In Unixy operating systems, the kernel implements IP and TCP. Applications access the network through the sockets API. A program that wants to act as a web server opens a listening TCP socket on port 80. (This will fail if another process is already listening on port 80. Only one process at a time can use a given port number.) When traffic to port 80 arrives, the TCP layer in the kernel sets up a connection. The program recieves a connection socket from its listening socket. Server and client can then start speaking HTTP. To use port numbers below 1024 you must be root in Unixy systems. (There might be exceptions.) But programs shouldn't run as root if it can be avoided, because then they can do a lot of damage if anything goes wrong. The usual solution is to start the program as root, but as soon as it has opened its listening socket, the program switches to an unprivileged user account and runs as that user from then on. Anyway, you need root access to let your program use port 80. According to what I've read about AWS, it implements HTTP and interfaces to the sockets API, so it doesn't need Apache. I can imagine that it might be useful to have a regular web server beside an AWS application, but then one of them will have to use a nonstandard port. Some kind of proxy could of course accept a connection on port 80, open another connection to an AWS application on another port, and forward traffic between them. If your application isn't meant to be used by humans through web browsers, it may make more sense not to use port 80. IPP for example, the Internet printing protocol, is built on top of HTTP but has its own port � number 631. -- Bj�rn Persson PGP key A88682FD omb jor ers @sv ge. r o.b n.p son eri nu ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: AWS applications and domain hosting 2005-06-26 23:00 ` Björn Persson @ 2005-06-26 23:45 ` Marius Amado Alves 2005-06-29 2:42 ` tmoran 1 sibling, 0 replies; 16+ messages in thread From: Marius Amado Alves @ 2005-06-26 23:45 UTC (permalink / raw) To: comp.lang.ada Bjorn, excellent information about Unix network deamons. Thanks a lot. > According to what I've read about AWS, it implements HTTP and > interfaces to the sockets API, so it doesn't need Apache. Exactly. > If your application isn't meant to be used by humans through web > browsers, it may make more sense not to use port 80. IPP for example, > the Internet printing protocol, is built on top of HTTP but has its > own port – number 631. Human, machine, port number, irrelevant. URLs may include the port number. You just redirect your-cool-domain-name.net to your-account-at.superduper-hosting.com:12345 and get done with it. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: AWS applications and domain hosting 2005-06-26 23:00 ` Björn Persson 2005-06-26 23:45 ` Marius Amado Alves @ 2005-06-29 2:42 ` tmoran 1 sibling, 0 replies; 16+ messages in thread From: tmoran @ 2005-06-29 2:42 UTC (permalink / raw) > ... it may make more sense not to use port 80. ... If your traffic is light you might just want to run your own server on your own computer using either a static IP address or, if dynamic, a dynamic DNS provider (see for instance the free service from www.dyndns.org). I do that with a specialized version of smplsrvr. I do that with an old Windows machine connected via DSL using a modified version of smplsrvr. It uses a port other than 80 since it's not intended for mass usage and the relevant web references can say www.xxx.yyy/aaa:nnnn I also added a simple SMTP server to smplsrvr on port 25 to receive and process text messages from my cellphone. ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2005-07-02 21:50 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-06-26 9:36 AWS applications and domain hosting Martin Dowie 2005-06-26 10:51 ` Adrian Knoth 2005-06-26 12:36 ` Jacob Sparre Andersen 2005-06-26 13:18 ` Larry Kilgallen 2005-06-26 19:29 ` Marius Amado Alves 2005-06-26 22:46 ` Jacob Sparre Andersen 2005-06-30 20:00 ` Randy Brukardt 2005-06-30 20:45 ` Pascal Obry 2005-06-30 23:58 ` Jacob Sparre Andersen 2005-07-01 6:01 ` Pascal Obry 2005-07-02 20:28 ` Jacob Sparre Andersen 2005-07-02 21:50 ` Pascal Obry [not found] ` <m23bqzcrew.fsf@hugin.crs4.it> 2005-07-01 1:45 ` Randy Brukardt 2005-06-26 23:00 ` Björn Persson 2005-06-26 23:45 ` Marius Amado Alves 2005-06-29 2:42 ` tmoran
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox