Re: fixhrefgz unnecessary when fixing web-browsers in the correct wayR
On 29 Jun 1997, Karl M. Hegbloom wrote: >> "Christoph" == Christoph Lameter <[EMAIL PROTECTED]> writes: > >Christoph> This wont work as we already have said again and >Christoph> again. You are modifying the HTTP protocol with this >Christoph> and creating a new .html.gz extension in essence. And >Christoph> sometimes the web browser will get those files >Christoph> compressed and sometimes not. > >The gzipped files are served as application/x-gzip, and an entry in >"/etc/mailcap" tells the browser how to uncompress it prior to >display rendering. The protocol isn't changed at all. This is the earlier approach: Again: I dont have /etc/mailcap on my Win95 workstation nor on my MacOS machines. And I strongly object to reconfiguring the whole world of Web-Browsers just to accomodate reading Debian Documentation. This is a non-standard extension of the http protocol! > Please read my earlier post regarding Apache run from `inetd' (or >better, from `xinetd'), and mod_rewrite. I think we could set up an >..htaccess file for "/usr/doc" with some rewrite rules that would make >it so that if someone clicks a link in a Debian manual, the link will >be to http://localhost/doc/thing.html and the mod_rewrite will make it >so `apache' will grab that if it exists or grab thing.html.gz if /that/ >exists, and failing either, will grab http://www.debian.org/doc/thing.html, >where the similar thing happens; the docs there can be gzipped as >well. .htaccess is not supported by all web-servers. boa does not support it. --- +++ --- +++ --- +++ --- +++ --- +++ --- +++ --- +++ --- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: fixhrefgz - tool for converting anchors to gzipped files
On Sat, 28 Jun 1997, Jim Pick wrote: > > You are proposing that a web-server is supposed to be searching > > through the .html code it serves and replace all links referring to > > .html.gz by .html links? > > dwww does this - it's not trivial. This is definitely not the job of a > web server. I agree 100%. A web server should NOT mess with the content. If we do this then we will make it difficult (or impossible) to serve .gz compressed files from debian-based web-servers. remember that not all .gz files are compressed documentation that needs to be decompressed on the fly. e.g. you put the linux kernel source on your web server for anyone to download. Do you really want apache or whatever to decompress a 6+MB .tar.gz file on-the-fly while sending it out to someone? > So here's my stand: > > - let's munch up the links to point to ".html.gz" files. Ugly, I know, > and a bit of work, but then we don't need to force people to install a > web server. I think it's pretty important that we don't force people > to run stuff they don't want. no, that will make it a pain to download files which are already compressed. The "smarts" should be in the web browser. > - we should compress html, because lots of people (like me) are using > Debian on machines with almost no hard drive. > > - Lynx and Netscape work with the compressed links (correct me if I'm wrong), > and we could use a web server/dwww combination to allow other browsers > to work too. I think that the correct place for this translation is in the web browser (as many others have suggested). modify lynx, mosaic, chimera, etc so that: 1. when a NON- .gz link is selected, try to fetch it. 2. if it fails, try to fetch .gz version and decompress it. 3. if that fails too, report an error to user. 4. if the link was pointing to a .gz file then DO NOTHING TO IT. If I download a compressed file from the net, then i want to save it as a compressed file. I certainly dont want my browser mangling the file for me. point 2. should probably be restricted to localhost or `hostname -d`. i don't know. will have to think some more about it. It may also be worthwhile doing this for file managers like mc, git, tkdesk. It would definitely be worthwhile to use less' LESSPIPE feature to do this. we can't patch netscape, but that's not our problem. people using netscape will just have to use dwww (which should be the preferred way of browsing debian docs anyway). I can't wait for the Mnemonic project to get off the ground...an extensible, modular, freeware web browser written using the Gimp's GTK widget set: Heaven! I'm getting really tired of netscape 4.0b5 crashing when I do Really Bad Things like click on a page to select a link or foolishly try to use it's drag and drop feature (it worked in 4.0b3, crashes almost 100% of the time under 4.0b5), or leave a netscape window idle for a while and have it just die for no apparent reason. Netscape is becoming yet another example of why free software is better than commercial/non-free. craig -- craig sanders networking consultant Available for casual or contract temporary autonomous zone system administration tasks.
Re: Sub-categorizing the /usr/doc directory.
On Sun, 29 Jun 1997 11:57:49 -0400 , Joey Hess wrote: > Karl M. Hegbloom: > > I think it would be good to divide the "/usr/doc" directory into sub > > directories. It should be divided in the same as the Debian ftp site, > > and packages should put their documentation into the same slot as the > > one they got ftp'd from. > > > > The directory is very large when you have a lot of packages > > installed, and it takes a lot of processing to open it with a file > > manager, web browser, or dired. > > I completly agree. I have 434 items in /usr/doc, and that's too many. > Splitting it up by package section is a very good idea. Would you take a look at /usr/bin, then? I have 912 items there. Nowadays I do a 'ls -lrt /usr/doc' when I have updated many packages. Then I can easily go to another console and look at the changelogs in the latest changed directories. No need for remembering which packages I updated, the list is on screen. Splitting up the /usr/doc directory would only make this more difficult. Remco -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: fixhrefgz unnecessary when fixing web-browsers in the correct wayR
On Sun, 29 Jun 1997, Christoph Lameter wrote: > This is a non-standard extension of the http protocol! I support your idea of using a WWW server for documentation, but you're saying wrong things and making people be angry with you.. =) The HTTP protocol DOESN'T rely on extensions. No HTTP compliant WWW browser decides what to do with a file looking in the extension. Think about a cgi program returning an html file and another cgi program returning a GIF (counters do this). The facts about having a WWW server are (IMO): * It isn't slow. We need just a small binary called by inetd, as heavy as `cat'. * It's safe. The debian docs could be accessed through a non-standard port... and this port could be restricted for use from localhost only (tcpd, xinetd, a check in the binary...). * It's clean. The upstream doc's wouldn't be touched/patched. * It's a *lot* more flexible. Think of this: The server could check if some document exist in the local host, and if it doesn't it would issue a redirect to the document location in the WWW. It could even use HTTP features to check if a newer version than the local one exists and fetching it, and thus maintaining an updated local version. * It's small. This system would be smaller than 100kb. * It doesn't use resources when it isn't running (since it's started from inetd). * It's network friendly. Somebody could easily browse documentation in other machines (telling the server to accept non-local connections first). -- Nicolás Lichtmaier.- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Sub-categorizing the /usr/doc directory.
On Sun, 29 Jun 1997, Jim Pick wrote: > One complication I can think of - dselect and the ftp sites have the > concept of "overrides", where Guy can change the section a package > is assigned to. This wouldn't be reflected in the /usr/doc > directory - of course, this might not really matter. I think it does matter, as an undesired source of confusion. It'd be a bad thing to have docs for foo in /usr/doc/utils/foo, for example, if foo is in section devel and not section utils. On Sun, 29 Jun 1997, Brian White wrote: > From a "use" point of view, the user knows what package documentation > he's looking for when going into /usr/doc, so why does a large directory > make any difference? > > Let's leave it the way it is. Splitting it will only make things more > difficult for users. someone else (I missed the aqttribution) said: > > > The directory is very large when you have a lot of packages > > > installed, and it takes a lot of processing to open it with a file > > > manager, web browser, or dired. > > > > I completly agree. I have 434 items in /usr/doc, and that's too many. > > Splitting it up by package section is a very good idea. I'd agree that a directory with over 400 items in it is probably excessively unwieldy. How about creating directories /usr/doc/[a-z], and putting package doc files into subdirs based on the initial char of the package name? That would reduce the unwieldiness of /usr/doc with less potential for confusion. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Sub-categorizing the /usr/doc directory.
Bill Mitchell: > someone else (I missed the aqttribution) said: Me :-) > > > I completly agree. I have 434 items in /usr/doc, and that's too many. > > > Splitting it up by package section is a very good idea. > > I'd agree that a directory with over 400 items in it is probably > excessively unwieldy. > > How about creating directories /usr/doc/[a-z], and putting package > doc files into subdirs based on the initial char of the package > name? That would reduce the unwieldiness of /usr/doc with less > potential for confusion. Seems reasonable, though it's a little ugly. -- see shy jo -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
fiat mode on regarding WWW and documentation
On Sun, 29 Jun 1997, Christoph Lameter wrote: > This is a non-standard extension of the http protocol! This is a pretty silly argument. The web server has complete control over how a compressed document is presented. It can send the document as "Content-Type: text/html" or as "Content-Type: application/gzip". The web server can completely hide compression from the browser. I think we've reached the point of absurdity as far as making browsers browse Debian documentation directly is concerned. It presents us with a number of un-resolvable problems: 1. It doesn't allow browsing the Debian documentation from another computer. I often run Netscape on Valerie's windows system and use it to read documentation served by "boa" on my Debian system. This is something a network admin or anyone else who has to know about the system and doesn't necessarily have it on their desk might want to do. We should support this form of use. 2. It requires hacking of the browsers, or worse, hacking the filesystem, if you want to handle compression transparently for all browsers. Ugh! Servers handle this so well, let's use them. 3. It forces us to make changes in the system and its tools that have little to do with presenting documentation. So far I'm not convinced by the "let's compress the filesystem" argument. It doesn't work off of a CD, and it limits the user from using "foriegn" filesystems that we otherwise fully support. At this point I'm convinced that dwww should depend on a web server, and that the server should be able to handle compressed documents. I am willing to take the (small) hit for "boa" or something else small and fast. I am willing to support browsers on the system that can browse the documentation directly, but am not willing to insist that all browsers do so. Thanks Bruce -- Bruce Perens K6BP [EMAIL PROTECTED] 510-215-3502 Finger [EMAIL PROTECTED] for PGP public key. PGP fingerprint = 88 6A 15 D0 65 D4 A3 A6 1F 89 6A 76 95 24 87 B3 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: fixhrefgz unnecessary when fixing web-browsers in the correct wayR
> Hi, > > Also, 11M may not be a typical install. I get a far higher number: > __> du -s /usr/doc > 92026 /usr/doc > > Uncompressing this is very likely to annoy me. 11M was for my old 386 box (no X installed) - I'm only using about 200M total on that system. That works out to about 5% of the disk space. The system is quite ancient, but it works great as a Linux machine. If you've 92M of documentation - you probably have a much larger disk - but the % of space dedicated to documentation is probably still around 5%. (My development system has 123M of docs out of a 2GB filesystem - 6.1%) I think you'll find that if we compromise, and store most of the documents in compressed format, except for the HTML documents, your overall disk consumption will not increase by much (as a percentage of the overall disk usage) - maybe the percentage of disk space used for documentation would increase to 7-8% at the most. I'd gladly buy more disk space in order to install more documentation only packages (if they were available). Buying disks to store on-line documentation (even fully uncompressed) is a bargain compared to buying off-line books from Tim O'Reilly and company. Cheers, - Jim pgpxbuMEWh7i2.pgp Description: PGP signature
Modula 3 packages
[please cc any responses to me.] Is anybody busy working on these? I ask because I'm fairly close to (hopefully :) creating a working set of rules/control files/etc. for compiling SRC Modula-3, and associated programs. If all goes well, I should have them finished within a week or two. I really, really, really don't have time this semester to maintain them properly, though ... when November rolls around, I'll be happy to do so, but before then, I'll be flat out with honours related things (including the project... joy. Not.. ;) If anybody would be willing to maintain them properly, I'll be happy to send off a copy of the Debian files, and appropriate diffs. Otherwise, they'll probably languish in orphaned obscurity ;) Oh, yes - one other problem is that the bootstrap compiler is provided as source code. i386 assembler source, that is. [EMAIL PROTECTED] (last time I tried it - some months back) indicated that SRC M3 is not really being supported by DEC in any significant way - so it's unlikely it'll be available for the m68k, Alpha, PowerPC, MIPS, Sparc, ... ports (unless one of the other bootstrap sets can be used instead.. this might be possible for the Alpha. I don't know; I only have a 486.) Cheers, Stuart. (One time Debian developer, hoping to find the time once his course is finished to rejoin. :) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
debian-non-US mirrors (was Re: debmake)
> I couldnt help but notice that there are no Canadian or even American > (South or Central) mirrors of debian with the non-us category. Actually, I do have one on my server (in Canada): ftp://ftp.jimpick.com/pub/mirrors/debian-non-US/ Canada doesn't have a NSA-like organization that has to protect it's turf - so the regulations are pretty loose. The only thing not permitted is re-exporting crypto stuff that was illegally exported from the US, AFAIK. Cheers, - Jim pgpn5L0mKxfq1.pgp Description: PGP signature
Re: fiat mode on regarding WWW and documentation
On Sun, 29 Jun 1997, Bruce Perens wrote: >On Sun, 29 Jun 1997, Christoph Lameter wrote: >> This is a non-standard extension of the http protocol! > >This is a pretty silly argument. The web server has complete control over >how a compressed document is presented. It can send the document as >"Content-Type: text/html" or as "Content-Type: application/gzip". >The web server can completely hide compression from the browser. The web-browser does not have complete control about what kind of decompressors are installed if any. Ok the term I used is probably not very good. My precision of expression is really lacking ... . May I would better have said: This is a non-customary extension to the functionality available in common web-browsers on non-Linux platforms. >At this point I'm convinced that dwww should depend on a web server, and >that the server should be able to handle compressed documents. I am willing >to take the (small) hit for "boa" or something else small and fast. I am >willing to support browsers on the system that can browse the documentation >directly, but am not willing to insist that all browsers do so. Good. I think the security issue could be taken care of easily since the developer of boa is a debian developer. We are fortunate to have such capable people among us! Certainly he might be able to help us with any functionality we find lacking on the server side. --- +++ --- +++ --- +++ --- +++ --- +++ --- +++ --- +++ --- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Vision of new installation method using webserver
Since we were talking about including a web-server in the base system here some thoughts. I often maintain headless servers. I always have to attach a screen for the initial install or if something is seriously wrong with the machine. Lets say I have a new machine fine tuned by the dealer (who put 95 or something else we dont need on it) in front of me. I'd like to do the following 1. Insert Floppy disk and boot A) The installation disk will detect frequently used ethernet boards and configures an IP address obtained using BOOTP or DHCP. I can then usually locate the IP address either via the BOOTP logs on a Linux machine or via the NT DHCP display. B) The web-server will start running C) There is NO user interaction up to this point. Video is not used at all. 2. I can then use my laptop attached to the ethernet or a nearby workstation with any web-browser and connect to the webserver on the new machine 3. Use a web-driven configuration process - initial partitioning and formatting - running dselect (dwebselect?) This would simplify the installation process extremely. I could just sent the installation disk to a customer far away and tell him to insert that disk into a new machine and I could remotely set it up from home! I have a customer in Minneapolis for example and I needed someone to do the initial install before I could take over the system. He put RH on it since he knew nothing else. I then had to upgrade the system to Debian via telnet. Uggh. If the base disks also would include a small textbased web-browser then we might be able to use the same user interface both for remote and local installations. Another benefit would be that those machine actually could be ordered without any video board at all leaving room for more expansion. Right now we leave a cheap video board in for emergencies. This move would give us a tremendous advantage over RH in the business world. If anything is wrong just tell the customer to put in the rescue disk and we can remotely fix things worldwide (hardware willing to cooperate of course). --- +++ --- +++ --- +++ --- +++ --- +++ --- +++ --- +++ --- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Vision of new installation method using webserver
In your email to me, Christoph Lameter, you wrote: > > Since we were talking about including a web-server in the base system here > some thoughts. > > I often maintain headless servers. I always have to attach a screen for > the initial install or if something is seriously wrong with the machine. > > Lets say I have a new machine fine tuned by the dealer (who put 95 or > something else we dont need on it) in front of me. I'd like to do the > following > > 1. Insert Floppy disk and boot >A) The installation disk will detect frequently used ethernet boards > and configures an IP address obtained using BOOTP or DHCP. I can > then usually locate the IP address either via the BOOTP logs on a > Linux machine or via the NT DHCP display. >B) The web-server will start running >C) There is NO user interaction up to this point. Video is not used at > all. > > 2. I can then use my laptop attached to the ethernet or a nearby >workstation with any web-browser and connect to the webserver on >the new machine > > 3. Use a web-driven configuration process >- initial partitioning and formatting >- running dselect (dwebselect?) > > This would simplify the installation process extremely. I could just sent > the installation disk to a customer far away and tell him to insert that > disk into a new machine and I could remotely set it up from home! > > I have a customer in Minneapolis for example and I needed someone to do > the initial install before I could take over the system. He put RH on it > since he knew nothing else. I then had to upgrade the system to Debian > via telnet. Uggh. > > If the base disks also would include a small textbased web-browser then we > might be able to use the same user interface both for remote and local > installations. > > Another benefit would be that those machine actually could be ordered > without any video board at all leaving room for more expansion. Right now > we leave a cheap video board in for emergencies. > > This move would give us a tremendous advantage over RH in the business > world. If anything is wrong just tell the customer to put in the rescue > disk and we can remotely fix things worldwide (hardware willing to > cooperate of course). This is a GREAT idea! A few years ago, I took a look at Plexus (I think it was written by Tony Samders). It's a complete server written in Perl. Since we have perl on the resc disk I'll have to see if I can find another copy. Being all text source based, it should compress fine to save space. Tim -- (work) [EMAIL PROTECTED] / (home) [EMAIL PROTECTED] - http://www.buoy.com/~tps Actually, I *do* know everything. I just don't get paid enough to show it. ** Disclaimer: My views/comments/beliefs, as strange as they are, are my own.** -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Vision of new installation method using webserver
Sounds slick. It wouldn't be too hard to do. It would be slick to have some more network smarts (like DHCP, and dialup to an ISP) on the boot disks (or some variant thereof). As for configuration via the web - check out the GPL'd Java telnet applet I've got installed on my webserver (http://www.jimpick.com/telnet/) - a simple solution would be to put that on the install disks, along with a small web server and some CGI scripts to do the initial configuration - and bingo, you can configure the machine from any Netscape or Internet Explorer machine than can talk HTTP, FTP, and Telnet to it. (of course, firewalls can be a pain) Cheers, - Jim pgpdEqCFsa6KB.pgp Description: PGP signature
Re: fiat mode on regarding WWW and documentation
From: Christoph Lameter <[EMAIL PROTECTED]> > This is a non-customary extension to the functionality available in common > web-browsers on non-Linux platforms. As far as I can tell you could have written it as "we really need a web server here, unless all web browsers are guaranteed to be able to do uncompression, and just maybe we need them to do _transparent_ uncompression. I still have a problem understanding why one would not do all of this in the server. Sure, using a direct browser is potentially faster, so use one when you can, don't make everyone use one. Bruce -- Bruce Perens K6BP [EMAIL PROTECTED] 510-215-3502 Finger [EMAIL PROTECTED] for PGP public key. PGP fingerprint = 88 6A 15 D0 65 D4 A3 A6 1F 89 6A 76 95 24 87 B3 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Vision of new installation method using webserver
No, we don't have perl on the rescue disk. However really tiny servers that handle CGI are probably possible. Bruice -- Bruce Perens K6BP [EMAIL PROTECTED] 510-215-3502 Finger [EMAIL PROTECTED] for PGP public key. PGP fingerprint = 88 6A 15 D0 65 D4 A3 A6 1F 89 6A 76 95 24 87 B3 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
