PDP-10 Archive migration plan
Tim Shoppa
http://pdp-10.trailing-edge.com/
from the large, heavy, power-hungry VMSCluster to a small,
lightweight, and efficient linux PC.
Ignore the relation to the VMS vs Unix vs PDP-10 thread that has
been taking up so much space in this newsgroup. The main reason
for this migration is nothing more than power efficiency - I can
keep a little PC (drawing less than 50 Watts) up for hours on a
cheap UPS, while keeping the older cluster up for more than a few
minutes on a big UPS is a hassle.
Not only will the webserver and files reside on a different machine,
but there will also be a number of other changes:
1. No longer will *.TPC (DECUS TPC-style, blocks are preceded by 16-
bit block length) tape archives be listed. The archive of tape images
will be offered solely as as *.tap (emulator-style, blocks are
preceded *and* followed by their 32-bit block length) images.
Internally I will continue to use *.TPC tape archives for some
purposes. But my impression is that the emulator community is
much better served by the *.tap style images. If anyone disagrees
with me, speak up!
2. The compression method for tape images will change as well:
Instead of gzipped (*.tap.gz), they will now be compressed with
bzip2 and filenames will be of the form *.tap.bz2. Bzip2 offers
significantly better compression (10-20%) on these images, and
it adds up when there are many thousands of megabytes of them.
More bzip2 informattion is available at
http://sources.redhat.com/bzip2/
3. The extracted files will now be prepared using the "backup10"
and "read20" programs, which I have been patching up over the
past month to the point that I am very happy with their capabilities.
My patched versions of these very useful tools will be made available
shortly.
4. The web pages that index into the archives will be more CSS
(style-sheet) oriented and less table-oriented. I aim to make the
resulting pages easily viewed on both graphical *and* text-based
browsers. At the same time, I will also be making use of
server-side includes to make web site maintenance easier for me.
(Read that as: if you point out an error on the home page, I hope
to be able to fix it more quickly than the couple of months it
now takes me to get around to it!)
5. A site search engine will allow searching of the extracted files
quickly and efficiently.
6. An index of scanned and line-printer documents will eventually
happen.
Many of the above elements can be seen already at the "test site",
http://new-pdp-10.trailing-edge.com/
but not all the above elements have yet been combined (for example,
as of Sunday morning the test site still uses tables extensively.)
The actual switchover will occur early in the morning of
21-Jan-2002 EST. The old archive will remain up and going even
after the switchover at
http://old-pdp-10.trailing-edge.com/
for at least a few weeks, as I perfect the redirects and rewrites
of URL's. Besides, if I shut the old cluster down at this time of
year the basement would get too chilly :-).
Tim. (sho...@trailing-edge.com)
Arthur Krewat
>
> Ignore the relation to the VMS vs Unix vs PDP-10 thread that has
> been taking up so much space in this newsgroup. The main reason
> for this migration is nothing more than power efficiency - I can
> keep a little PC (drawing less than 50 Watts) up for hours on a
> cheap UPS, while keeping the older cluster up for more than a few
> minutes on a big UPS is a hassle.
Also, keep in mind you are reducing greenhouse gases as you do this :)
Unless, of course, you are going to leave the cluster running, and then
you're nothing but a power-hungry glutton like me !
aak
Zane H. Healy
> As announced over a month ago, I am migrating the PDP-10 archive
> http://pdp-10.trailing-edge.com/
I just checked to see how the site looks now. It's looking pretty good!
You've done some major improvements since the last time I looked!
> from the large, heavy, power-hungry VMSCluster to a small,
> lightweight, and efficient linux PC.
Can't imagine why you'd want to move to something that doesn't suck up so
much electricity.
Zane
Tim Shoppa
>
> In alt.sys.pdp10 Tim Shoppa <sho...@trailing-edge.com> wrote:
> > As announced over a month ago, I am migrating the PDP-10 archive
>
> > http://pdp-10.trailing-edge.com/
>
> I just checked to see how the site looks now. It's looking pretty good!
> You've done some major improvements since the last time I looked!
Even better, sometime this evening I'll make the tools that unpack
tapes and create the web indices publicly available. They're nothing
fancy - just some small fixes and a features added onto backup10
and read20, and a few Perl scripts.
The improvements are not done yet: there is still work to be done
for non-<TABLE> display of some of the indices. It'll be a preformatted
document inside of <PRE> tags, and ought to look pretty good
under lynx (or any other browser, for that matter!).
I hope to also learn about Apache's URL-rewrite engine so that
most of the existing links into the old archive URLs get meaningful
redirects. (Right now they get sent to a search page, which is
better than nothing.)
> > from the large, heavy, power-hungry VMSCluster to a small,
> > lightweight, and efficient linux PC.
>
> Can't imagine why you'd want to move to something that doesn't suck up so
> much electricity.
UPS hang-time :-).
Tim.
sfm...@bellatlantic.net
what version of linux are you running? Just curious,
bob - using a diff screen name...still bad bob
Tim Shoppa
> Tim,
> what version of linux are you running? Just curious
It's a system built entirely from sources, not deviating very
far from what anyone would get after following the LFS 3.1
instructions:
http://www.linuxfromscratch.org/
It has a number of things layered on top of the bare-bones
minimum, like Apache, ProFTPd, Postfix, MRTG, ssh, ht:/dig,
sensors, etc.
No AOL-Linux for me :-).
Tim.
Zane H. Healy
> far from what anyone would get after following the LFS 3.1
> instructions:
> http://www.linuxfromscratch.org/
This brings an interesting question to my mind. Would people be interested
in a striped down, minimalistic version of Linux that is designed with using
it as a host OS for emulators in mind? It's something I've been considering
putting together.
Zane
Ben Franchuk
The one flaw with linux it does not have installable device drivers,
like DOS did. This means you have to rebuild the kernel for every
bit of custom hardware. I have a 486-66 with 16 Meg of memory,
if I wanted to run a PDP-10 emulator on this machine how fast would
it run compared to the old iron? Note too this machine runs DOS so
you would need a stand alone executable with a DOS extender.
PS. I like Debian linux as you can upgrade over a modem/serial internet
link.
Also less 'Know it all' attitude of red hat.
--
Ben Franchuk - Dawn * 12/24 bit cpu *
www.jetnet.ab.ca/users/bfranchuk/index.html
Roland Hutchinson
<bfra...@jetnet.ab.ca> wrote, apropos of using Linux as a platform
for PDP-10 emulators:
> The one flaw with linux it does not have installable device drivers,
> like DOS did. This means you have to rebuild the kernel for every
> bit of custom hardware.
Don't loadable kernel modules provide for installable device drivers?
Normally you only have to compile the module against the headers for
the current kernel; there's no need to need to recompile the kernel
itself, and there's no need to reboot the machine.
I'm posting from a machine that uses loadable kernel modules to
support both its PCMCIA Ethernet card and its <pftui> Lucent-chipset
winmodem.
Theres a very brief tutorial article on Linux device drivers and
kernel modules at
http://www.linuxplanet.com/linuxplanet/tutorials/1019/1/
And of course there's always "man modprobe" and "man insmod", the
kernel module HOWTO, and no lack of books from O'Reilly and other
fine publishers.
Please correct me if I've misunderstood the nature of the flaw
complained of, or somehow botched my explanation. I'm not a kernel
hacker, just a former PDP-10 user looking forward to playing with an
emulator in my copious free time.
(PS am I back on topic yet?)
--
Roland Hutchinson Will play viola da gamba for food.
NB mail to rolands....@usa.net is heavily filtered to remove
spam. If your message looks like spam I may not see it.
Eric Smith
> The one flaw with linux it does not have installable device drivers,
> like DOS did. This means you have to rebuild the kernel for every
> bit of custom hardware.
Wrong, wrong, completely brimming over with wrongability.
Sergio Pedraja
> I'm posting from a machine that uses loadable kernel modules to
> support both its PCMCIA Ethernet card and its <pftui> Lucent-chipset
> winmodem.
Is an OT: but I approach the oppotunity. I have one Compaq 1455XL that
supposedly only can manage Windows ME (Ha, ha, ha). I have Linux Slackware
working on it, but I need some device drivers to put in work the dammned
Winmodem that comes with the machine. I don't know exactly its chipset.
Thanks and Greetings
Sergio
Rupert Pigott
Eric Smith <eric-no-s...@brouhaha.com> wrote in message
news:qhg04yv...@ruckus.brouhaha.com...
He'd have made more headway with claiming OpenBSD suffered from this...
But that's by a very deliberate choice, as it happens it can also load
stuff into the kernel at run time. :)
Cheers,
Rupert
Tim Shoppa
>
> As announced over a month ago, I am migrating the PDP-10 archive
>
> http://pdp-10.trailing-edge.com/
>
> from the large, heavy, power-hungry VMSCluster to a small,
> lightweight, and efficient linux PC.
> 2. The compression method for tape images will change as well:
> Instead of gzipped (*.tap.gz), they will now be compressed with
> bzip2 and filenames will be of the form *.tap.bz2. Bzip2 offers
> significantly better compression (10-20%) on these images, and
> it adds up when there are many thousands of megabytes of them.
>
> More bzip2 informattion is available at
>
> http://sources.redhat.com/bzip2/
The only vocal complaint I've received about the archive migration is
that the tape images linked to from the web page are bzip2'ed
instead of gzipped. Just to sound out the wider community:
* Has anyone had difficulty building bzip2 tools or using bzip2'ed
files on their machine? If so, what platform/OS and what was
the difficulty?
I try not to be too bleeding-edge, but I've been using bzip2
for a couple years now and I'm pretty used to it - to the point
that I hardwired it into a few of the Perl scripts I use to build
and maintain the archives. I *could* go back to gzip, but I'd
like to be a little more forward-looking in this area if it'll cut
down on bandwidth usage and download times.
In any event, for the next few months gzipped tape images are
still available at ftp://ftp.trailing-edge.com/
Tim.
Eric Smith
> * Has anyone had difficulty building bzip2 tools or using bzip2'ed
> files on their machine? If so, what platform/OS and what was
> the difficulty?
My dislike for bzip2 is not because of portability problems, but because
it is much slower than gzip, for both compression and decompression.
Zane H. Healy
> that the tape images linked to from the web page are bzip2'ed
> instead of gzipped. Just to sound out the wider community:
I know I prefer gzip to bzip2, but I understand why you're doing this.
Besides I made a private mirror a while back so I'm good to go :^) Though
I'd be real happy if you added new stuff so I have to then deal with bzip2
:^) BTW, I won't admit to how long I used compress after gzip was widely
available.
> * Has anyone had difficulty building bzip2 tools or using bzip2'ed
> files on their machine? If so, what platform/OS and what was
> the difficulty?
I have, but I don't remember the specifics, and it's probably been at least
a couple years ago. It looks like the GNV project has bzip2 running on VMS
now.
Zane
William Hamblen
<bfra...@jetnet.ab.ca> wrote:
>The one flaw with linux it does not have installable device drivers,
>like DOS did. This means you have to rebuild the kernel for every
>bit of custom hardware.
Paraphrasing Johnny Hart: "Kernels got modules!"
Ben Franchuk
Paraphrasing dilbert. "Oh-No a PDP user , here's a wooden nickel buy
your
self a UNIX box."
The point is that you can't easily change devices on a linux system.
Modern OS's can't boot even from a floppy nowadays unless compressed
in some fashion. And tar is never on the boot/rescue discs, how is
guy to back up the the system?
Daniel Seagraves
> Paraphrasing dilbert. "Oh-No a PDP user , here's a wooden nickel buy
> your
> self a UNIX box."
>
> The point is that you can't easily change devices on a linux system.
> Modern OS's can't boot even from a floppy nowadays unless compressed
> in some fashion. And tar is never on the boot/rescue discs, how is
> guy to back up the the system?
And windows is much better?
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
Douglas H. Quebbeman
news:Oe538.14619$h31.1...@e420r-atl1.usenetserver.com...
How stripped-down? There's been talk of grafting a display console
emulator onto SIMH for use by the PDP-1 and PDP-6 emulators.... would
you exclude X?
-dq
Bob Supnik
<sho...@trailing-edge.com> wrote:
>Tim Shoppa wrote:
>The only vocal complaint I've received about the archive migration is
>that the tape images linked to from the web page are bzip2'ed
>instead of gzipped. Just to sound out the wider community:
>
>* Has anyone had difficulty building bzip2 tools or using bzip2'ed
> files on their machine? If so, what platform/OS and what was
> the difficulty?
>
As one of the lone Windoze users in this community, my complaint would
be that bzip2 is not, for some reason, supported by the defacto
compression tool, Winzip. There are reasonable bzip2-cognizant tools
out there (like PowerArchiver), but it's another step for the Windoze
user to go through in getting started. Gzip, tgz, tar, etc are all
includes in Winzip.
/Bob
Charles Richmond
--
+-------------------------------------------------------------+
| Charles and Francis Richmond <rich...@plano.net> |
+-------------------------------------------------------------+
Rupert Pigott
news:3C4E1C8B...@jetnet.ab.ca...
> William Hamblen wrote:
[SNIP]
> The point is that you can't easily change devices on a linux system.
> Modern OS's can't boot even from a floppy nowadays unless compressed
> in some fashion. And tar is never on the boot/rescue discs, how is
> guy to back up the the system?
Err... With Linux and OpenBSD (I assume that FreeBSD and NetBSD are
no different) you can actually fit quite a bit onto a "standalone"
floppy. Most of them work by using a stripped down kernel which will
boot on 99.9% of the machines out there and decompressing some file
system image into a ram disk which becomes the root filesystem.
Take a look, there's lots of stuff out there for the free UNIXes
where they actually *do* fit an OS with a bunch of useful utilities
onto a disk. Seriously, have a look. Two which come to mind, which
may well be defunct are "Linux Router Project" and "PicoBSD".
Also, before you despair, there are other approaches to backing
and restoring. Try asking about VAX "Stand Alone Backup". :)
Cheers,
Rupert
David Eppstein
Bob Supnik <bsu...@nauticusnet.com> wrote:
> As one of the lone Windoze users in this community, my complaint would
> be that bzip2 is not, for some reason, supported by the defacto
> compression tool, Winzip. There are reasonable bzip2-cognizant tools
> out there (like PowerArchiver), but it's another step for the Windoze
> user to go through in getting started. Gzip, tgz, tar, etc are all
> includes in Winzip.
Just tried an experiment and was pleasantly surprised to learn that they
are supported by the de facto standard decompression tool on the Mac,
Stuffit Expander. I had thought I had to use MacBzip2 (which works ok but
is less widely distributed)...
--
David Eppstein UC Irvine Dept. of Information & Computer Science
epps...@ics.uci.edu http://www.ics.uci.edu/~eppstein/
CBFalconer
I think there are a few more (windoze users). However, I don't
have winzip, nor want it. I can handle .zip, .lzh, .rar, .arj,
.zoo, .tar, .gz, .tgz, .pak, .arc, .ark, .lbr, .?z?, .?q?, and
possibly more compressed formats. The total space taken by all
the utilities is much smaller than winzip, and much more
controllable.
I don't have a bzip utility though. Nor can I handle MAC stuffit
files.
--
Chuck F (cbfal...@yahoo.com) (cbfal...@XXXXworldnet.att.net)
Available for consulting/temporary embedded and systems.
(Remove "XXXX" from reply address. yahoo works unmodified)
mailto:u...@ftc.gov (for spambots to harvest)
Ben Franchuk
Well good news to all windows lovers, at BZIP'S home
page they have a windows executable.
http://sources.redhat.com/bzip2/index.html
Tim Shoppa
>I have, but I don't remember the specifics, and it's probably been at least
>a couple years ago. It looks like the GNV project has bzip2 running on VMS
>now.
??? I was running it on VMS a couple of years ago - all I had to do
then was download the sources, compile, and link. Is there something
I'm missing?
In any event, I'm getting the impression that bzip2 isn't desired by
the emulator community at large. Maybe I'm (for once!) ahead of my time!
Tim.
Bill Pechter
Ben Franchuk <bfra...@jetnet.ab.ca> wrote:
>
>The one flaw with linux it does not have installable device drivers,
>like DOS did. This means you have to rebuild the kernel for every
>bit of custom hardware.
Actually you can build the modular kernel with all the drivers known to
man in it and only load the ones you need. They can be dynamically
loaded and unloaded (as can the *BSD kernel modules).
I do this at work all the time. I've also been known to compile x86
kernels for Linux for 386cpu with all the possible bus and module types
so I've got a bootable disk for just about any PC I find.
Bill
--
--
d|i|g|i|t|a|l had it THEN. Don't you wish you could still buy it now!
bpec...@shell.monmouth.com|pec...@ureach.com
CBFalconer
> page they have a windows executable.
> http://sources.redhat.com/bzip2/index.html
Guess I'll have to take a look. If it isn't a command line
utility I don't want it.
Bruce Hoult
> As one of the lone Windoze users in this community, my complaint would
> be that bzip2 is not, for some reason, supported by the defacto
> compression tool, Winzip. There are reasonable bzip2-cognizant tools
> out there (like PowerArchiver), but it's another step for the Windoze
> user to go through in getting started. Gzip, tgz, tar, etc are all
> includes in Winzip.
Use Stuffit Expander. It's not only nicer to use than Winzip, it also
handles more formats:
StuffIt(TM) (.sit, .sea)
Zip (.zip),
UU (.uu, .uue, .enc)
BinHex (.hqx)
GZip (.gz, .tgz)
Arc (.arc)
MIME/Base 64 (.mime)
Bzip (.bzip, .bz, .bz2, .tbz)
LHa (.lha, .lzh)
Arj (.arj)
Rar (.rar)
Eric Smith
> The point is that you can't easily change devices on a linux system.
Yes, you can. More easily than on most OSes.
> Modern OS's can't boot even from a floppy nowadays unless compressed
> in some fashion.
Old OS's can't boot even from a floppy. Try booting TOPS-10 or TOPS-20
from a floppy sometime.
What the heck is your point?
Zane H. Healy
> How stripped-down? There's been talk of grafting a display console
> emulator onto SIMH for use by the PDP-1 and PDP-6 emulators.... would
> you exclude X?
If I were to include X, it would be totally optional. Part of what I'm
currently trying to decide is would I want this to be based on Slackware, or
do I want to base it on the "Linux from Scratch" project. I've built my own
Linux systems by hand before, but these days would prefer to base what I'm
doing on something that already exists (to many projects, to little time).
Zane
Zane H. Healy
>>I have, but I don't remember the specifics, and it's probably been at least
>>a couple years ago. It looks like the GNV project has bzip2 running on VMS
>>now.
> ??? I was running it on VMS a couple of years ago - all I had to do
> then was download the sources, compile, and link. Is there something
> I'm missing?
Probably not. I've never tried running it, but noticed it was part of what
is apprently included in GNV.
Zane
Zane H. Healy
> I don't have a bzip utility though. Nor can I handle MAC stuffit
> files.
Don't know about bzip, but you can get a free decompression program for
Windows and Linux for Stuffit files from the publisher.
Zane
Rupert Pigott
You might want to consider OpenBSD, I've stuck with it because it reminds
of Slackware in the "good old days". But it's even simpler. :P
Cheers,
Rupert
Zane H. Healy
> You might want to consider OpenBSD, I've stuck with it because it reminds
> of Slackware in the "good old days". But it's even simpler. :P
I like OpenBSD for certain things, but in this case I believe Linux to be
the correct solution. Of course said Linux box should probably be behind an
OpenBSD Firewall.
The perfect example of why Linux is the best choice, is TS10. Basically all
the emulators run on Linux, but not all of them run on the various BSD's.
Zane
JD
binaries as well or better. So, it does seem that Linux would be a good choice,
but so would FreeBSD. They used to have tools to create a custom floppy
boot also.
John
Rupert Pigott
news:ZMH38.1309$vb1.1...@news1.iquest.net...
[SNIP]
> Unless someone does something 'special', FreeBSD will often run Linux
> binaries as well or better. So, it does seem that Linux would be a good
choice,
> but so would FreeBSD. They used to have tools to create a custom floppy
> boot also.
OpenBSD also has Linux emulation... So you can run an
emulator under a Linux emulation. That's kinda sick.
Mind you if it's really the case that these emulators
simply won't run or port under *BSD, he's probably better
off KISS.
- Rupert
Zane H. Healy
> emulator under a Linux emulation. That's kinda sick.
> Mind you if it's really the case that these emulators
> simply won't run or port under *BSD, he's probably better
> off KISS.
There is also the issue that OpenBSD doesn't have multiprocessor support
yet, and NetBSD is just getting it. That means the only real choice is
Linux or FreeBSD. I'm familiar with Linux and OpenBSD. So, by process of
elimination that leaves Linux as the hands down winner.
Zane
Zane H. Healy
> I really hate it when people keep switching formats, and IMHO, 10% isn't worth
> it. 50%, maybe, but not 10%
When Tim is maintaining a archive with over a Gigabyte of tape images of
PDP-10 software, I think 10% is worth it to him. Remember, he's the one
providing the network bandwidth.
OTOH, under normal circumstances I'm in total agreement with you.
Zane
Eric Sosman
>
> "Zane H. Healy" wrote:
> >
> > In alt.sys.pdp10 Tim Shoppa <sho...@trailing-edge.com> wrote:
> > > It's a system built entirely from sources, not deviating very
> > > far from what anyone would get after following the LFS 3.1
> > > instructions:
> >
> > > http://www.linuxfromscratch.org/
> >
> > This brings an interesting question to my mind. Would people be interested
> > in a striped down, minimalistic version of Linux that is designed with using
> > it as a host OS for emulators in mind? It's something I've been considering
> > putting together.
> >
> What color would the stripes be??? (You did say it was "striped down"...)
He doesn't know what color the striped kernel is
because he brushed the striped paint onto it wrong
side out. Easy mistake; done it myself.
Christopher Stacy
Eric> Ben Franchuk <bfra...@jetnet.ab.ca> writes:
>> The point is that you can't easily change devices on a linux system.
Eric> Yes, you can. More easily than on most OSes.
>> Modern OS's can't boot even from a floppy nowadays unless compressed
>> in some fashion.
Eric> Old OS's can't boot even from a floppy. Try booting TOPS-10 or
Eric> TOPS-20 from a floppy sometime.
I only did it a few times, so I might well be confused, but I think I
have a recollection of booting a TOPS-20 machine using a floppy disk:
didn't the PDP-11 front-end console processor boot from a floppy disk,
which was then used to load the KL bootstrap program?
CBFalconer
That's the famous Zebra kernel. Comes in two basic colors, with a
single choice of stripe colors for each. The Tiger kernel is a
derivative, and quite rare today, but more colorful and much
noisier. It can climb binary trees.
jmfb...@aol.com
/BAH
Subtract a hundred and four for e-mail.
Steve O'Hara-Smith
"Zane H. Healy" <hea...@shell1.aracnet.com> wrote:
ZHH> There is also the issue that OpenBSD doesn't have multiprocessor support
ZHH> yet, and NetBSD is just getting it. That means the only real choice is
ZHH> Linux or FreeBSD. I'm familiar with Linux and OpenBSD. So, by process of
ZHH> elimination that leaves Linux as the hands down winner.
Before you abandon FreeBSD completely look at the PicoBSD setup which
enables you to (very easily) make customised stripped down systems. It sounds
to me like PicoBSD is exactly what you need (if it will run the emulators), I
can kick in some help with porting if needed.
--
C:>WIN | Directable Mirrors
The computer obeys and wins. |A Better Way To Focus The Sun
You lose and Bill collects. | licenses available - see:
| http://www.sohara.org/
Stan Barr
<Dark...@btinternet.com> wrote:
>JD <dy...@jdyson.com> wrote in message
>news:ZMH38.1309$vb1.1...@news1.iquest.net...
>[SNIP]
>> Unless someone does something 'special', FreeBSD will often run Linux
>> binaries as well or better. So, it does seem that Linux would be a good
>choice,
>> but so would FreeBSD. They used to have tools to create a custom floppy
>> boot also.
>
>OpenBSD also has Linux emulation... So you can run an
>emulator under a Linux emulation. That's kinda sick.
Only kinda...me running a CP/M emulator under dosemu under Linux and
displayed on a Mac...now _that's_ sick!
--
Cheers,
Stan Barr st...@dial.pipex.com
The future was never like this!
Bill Pechter
JD <dy...@jdyson.com> wrote:
>
>Unless someone does something 'special', FreeBSD will often run Linux
>binaries as well or better. So, it does seem that Linux would be a good
> choice, but so would FreeBSD. They used to have tools to create a custom
> floppy boot also.
>
>John
Yup... but the linux emulation may be a bit large to pack on the floppy
with ts10.
A bootable CDROM with FreeBSD, ts10 and an emulated writeprotected
master TOPS10 and TOPS20 pack would be slick. Mount an old writeable
500mb IDE as a couple of RP06's... automagically copy the images over if
the structures are noth there and run.
I'll take a look at building a custom 4.5 with ts10, though.
John J Francini
Healy" <hea...@shell1.aracnet.com> wrote:
Really? Go to CompUSA and the SMALLEST capacity IDE disk you can buy is
around 20 GB. For not much more you can get 40, 60, 80, 100 or more GB.
Since the archive is now living on a Linux PC with ostensibly modern disks,
storage capacity is really be a non-issue.
Bandwidth is, however, a bigger one, I agree -- however, is it worth it to
have a whole bunch of people need to pick up YADP (Yet Another
Decompression Program) just to save 10% on bandwidth?
I don't think so...
I'm both surprised and pleased to see that Stuffit Expander supports bzip2.
As I'm running the KLH emulator under MacOS X (Darwin based), I was
concerned about running yet another decompression program.
I admit that I tend to forget that the UNIX environment on MacOS X (as
presented by the shells available through the Terminal application) is
actually running on the same machine as the cool GUI. I keep tending to
believe that the UNIX stuff is on some other system that I'm Telnet'ed to,
not my Mac laptop. Yes, an admittedly strange bifurcation, but there it
is...
John
--
John Francini
Subtract Ten Twenty-Six for e-mail.
+------------------------------------------------------------------------------+
| "I have come to the conclusion that one useless man is called a disgrace; |
| that two or more are called a law firm; and that three or more become |
| a Congress. And by God I have had _this_ Congress!" |
| -- John Adams |
+------------------------------------------------------------------------------+
Sam Weiner
There was a configuration which had 8" floppies on the -11
instead of DECtapes. I forget which models though and the
book which describes the various options is buried somewhere.
Sam
CBFalconer
>
> In article <xxJ38.24750$h31.2...@e420r-atl1.usenetserver.com>, "Zane H.
> Healy" <hea...@shell1.aracnet.com> wrote:
>
> >In alt.sys.pdp10 Ms. 4.88's <> wrote:
> >> I really hate it when people keep switching formats, and IMHO, 10% isn't
> worth
> >> it. 50%, maybe, but not 10%
> >
> >When Tim is maintaining a archive with over a Gigabyte of tape images of
> >PDP-10 software, I think 10% is worth it to him. Remember, he's the one
> >providing the network bandwidth.
> >
> >OTOH, under normal circumstances I'm in total agreement with you.
> >
> > Zane
>
> Really? Go to CompUSA and the SMALLEST capacity IDE disk you can buy is
> around 20 GB. For not much more you can get 40, 60, 80, 100 or more GB.
>
> Since the archive is now living on a Linux PC with ostensibly modern disks,
> storage capacity is really be a non-issue.
>
> Bandwidth is, however, a bigger one, I agree -- however, is it worth it to
> have a whole bunch of people need to pick up YADP (Yet Another
> Decompression Program) just to save 10% on bandwidth?
>
> I don't think so...
According to that philosophy we would still be using SQ and USQ.
If you allow some progress we can use ARC and lzw (patented !!)
compression. LHARC and ARJ should never have been born, let alone
ZIP. Unixen would depend solely on COMPRESS.
If there is any real objection to bzip2 it is that it requires
something like 4 meg of data space. This makes it impossible to
port to small machinery, even as purely an uncompressor. LZ
encoding, on the other hand, has a very simple and fast decoder
that needs virtually no working memory.
BTW, 10% of a 40G disk is 4G. This probably represents about $20
today. Will everybody who objects to the use of bz2 kindly send
me the $20 and I will then shut up. :-) I am throwing in wear and
tear on the comm lines for free.
<thread-drift>
When I was in school I had a professor, H.G.I. Watson, who
measured everything in beers. (draft/draught at a local pub).
"Don't break this instrument, it costs 200 beers". That was
todays cost of 4G in those days.
</thread-drift>
jmfb...@aol.com
franci...@mac.com (John J Francini) wrote:
>In article <xxJ38.24750$h31.2...@e420r-atl1.usenetserver.com>, "Zane H.
>Healy" <hea...@shell1.aracnet.com> wrote:
>
>>In alt.sys.pdp10 Ms. 4.88's <> wrote:
>>> I really hate it when people keep switching formats, and IMHO, 10%
isn't
>worth
>>> it. 50%, maybe, but not 10%
>>
>>When Tim is maintaining a archive with over a Gigabyte of tape images of
>>PDP-10 software, I think 10% is worth it to him. Remember, he's the one
>>providing the network bandwidth.
>>
>>OTOH, under normal circumstances I'm in total agreement with you.
>>
>> Zane
>
>Really? Go to CompUSA and the SMALLEST capacity IDE disk you can buy is
>around 20 GB. For not much more you can get 40, 60, 80, 100 or more GB.
>
>Since the archive is now living on a Linux PC with ostensibly modern
disks,
>storage capacity is really be a non-issue.
It is Tim who doing all of the _work_. If it is easier
for him to do this flavor of encoding, then it should be
so. He has a day job, a night job, a family job, and (it
seems) a gazillion other things to do. Keep bitching and
I wouldnt blame him if he just said fuck it.
He asked for reasons why the new wouldn't work. NIH is
NOT a reason.
jmfb...@aol.com
wei...@TheWorld.com (Sam Weiner) wrote:
<snip>
>>I only did it a few times, so I might well be confused, but I think I
>>have a recollection of booting a TOPS-20 machine using a floppy disk:
>>didn't the PDP-11 front-end console processor boot from a floppy disk,
>>which was then used to load the KL bootstrap program?
>
>There was a configuration which had 8" floppies on the -11
>instead of DECtapes. I forget which models though and the
>book which describes the various options is buried somewhere.
Orange was floppies; Blue was DECtapes. IOW, the 1091 was
the floppy. 1090 was the DECtape. Another difference was
internal vs. external memory.
This was just a rule of thumb since we had a 1091 as our third
CPU on the SMP system. :-)
Tim Shoppa
>
> In article <xxJ38.24750$h31.2...@e420r-atl1.usenetserver.com>, "Zane H.
> Healy" <hea...@shell1.aracnet.com> wrote:
>
> >In alt.sys.pdp10 Ms. 4.88's <> wrote:
> >> I really hate it when people keep switching formats, and IMHO, 10% isn't
> worth
> >> it. 50%, maybe, but not 10%
> >
> >When Tim is maintaining a archive with over a Gigabyte of tape images of
> >PDP-10 software, I think 10% is worth it to him. Remember, he's the one
> >providing the network bandwidth.
And as if to prove your point, outgoing bandwidth from the archive has
been at 95%+ for most of the past day :-). Thanks for recognizing the
real issue.
> Really? Go to CompUSA and the SMALLEST capacity IDE disk you can buy is
> around 20 GB. For not much more you can get 40, 60, 80, 100 or more GB.
>
> Since the archive is now living on a Linux PC with ostensibly modern disks,
> storage capacity is really be a non-issue.
>
> Bandwidth is, however, a bigger one, I agree -- however, is it worth it to
> have a whole bunch of people need to pick up YADP (Yet Another
> Decompression Program) just to save 10% on bandwidth?
To put the "storage vs bandwidth" aspect into perspective, I'm currently paying
the equivalent of two 40GB drives a month for bandwidth. Admittedly,
that bandwidth is shared with other projects and users - who *do* suffer
somewhat when bandwidth is pegged.
While storage space costs were a plus in favor of doing the archive
migration, many of the other factors are not so easily quantified -
easier archive maintenance, more configurable web server, better UPS
hangtime, etc.
> I don't think so...
I would love to be able to save *much* more than 10% on bandwidth, but a
technology that will let me save 90% probably will also violate the 2nd
law of thermodynamics :-). As it is, bzip2 saves up to 35%
on bandwidth over gzip - and that's enough to convince me to keep it.
For most tape images, the savings is between 20 and 30%. (These figures
were all comparing the "default" bzip2 setting against the "best" (-9) gzip
setting.)
I thought that bzip2 wouldn't be such a big issue - after all, anyone
running a PDP-10 emulator has a rather modern platform which can
run the decompressor, and they also have the technical abilities to
download and run the bzip2 decompressor (after all, they've already downloaded
and built an emulator!). I still feel that's true, despite the complaints.
And I thought that the archive users would be more appreciative of
the fact that better compression saves them time in downloading, too :-)
Bzip2 is not only the future, it is also the present. Other sites that
are pressed for bandwidth and tight on money (e.g. www.kernel.org) are either
requiring or strongly encouraging users to switch to it. I'll do my
best to ease the transition, but it's the way I gotta go.
Tim.
Arthur Krewat
>
> Bzip2 is not only the future, it is also the present. Other sites that
> are pressed for bandwidth and tight on money (e.g. www.kernel.org) are either
> requiring or strongly encouraging users to switch to it. I'll do my
> best to ease the transition, but it's the way I gotta go.
F*&K em. Just put a link to the bzip2 sources so I can find them :)
aak
Brian Inglis
From bzip2 man page:
Here is a table which summarises the maximum memory usage
for different block sizes. Also recorded is the total
compressed size for 14 files of the Calgary Text Compres-
sion Corpus totalling 3,141,622 bytes. This column gives
some feel for how compression varies with block size.
These figures tend to understate the advantage of larger
block sizes for larger files, since the Corpus is domi-
nated by smaller files.
Compress Decompress Decompress Corpus
Flag usage usage -s usage Size
-1 1200k 500k 350k 914704
-2 2000k 900k 600k 877703
-3 2800k 1300k 850k 860338
-4 3600k 1700k 1100k 846899
-5 4400k 2100k 1350k 845160
-6 5200k 2500k 1600k 838626
-7 6100k 2900k 1850k 834096
-8 6800k 3300k 2100k 828642
-9 7600k 3700k 2350k 828642
--
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada
Brian....@CSi.com (Brian dot Inglis at SystematicSw dot ab dot ca)
fake address use address above to reply
tos...@aol.com ab...@aol.com ab...@yahoo.com ab...@hotmail.com ab...@msn.com ab...@sprint.com ab...@earthlink.com ab...@cadvision.com ab...@ibsystems.com u...@ftc.gov
spam traps
Tim Shoppa
>
>As announced over a month ago, I am migrating the PDP-10 archive
>
> http://pdp-10.trailing-edge.com/
>
>from the large, heavy, power-hungry VMSCluster to a small,
>lightweight, and efficient linux PC.
Now that the switchover is done, I want to get back to solving a problem
that is related to serving the 60,000-odd extracted PDP-10 files: (*not*
the tape images which was the bzip2 vs gz discussion):
Many of the extensions on those files are different than those
expected by most web servers or web browsers. Sometimes these are
36-bit binary files, for which there is no good MIME type anyway.
But other files - especially line-printer documents, which by
pre-Microsoft convention named "*.DOC" - are
always interpreted by Microsoft (Internet Explorer) browsers as
Microsoft Word documents.
Keep in mind that this is discussing individual files that are supposed
to be browsable, not the tape images that were the subject of the bzip2 vs
gzip discussion. Also keep in mind that many of these documents go back
to the 1960's, so simply saying "don't use *.DOC for them" is not only
impractical, it hits a raw nerve in a very broad community.
Note that this is somewhat related to the extended flame-war on filename
extensions - basically, IE always treats *.DOC files as if they were
Microsoft Word, despite all efforts of the browser-user or the webmaster.
A number of possible workarounds were proposed (beyond the solution of
"let IE explorer users suffer in hell"), and I think I have the technical
means to implement one of them:
First, serve all of the browsable extracted files up with *.html
extensions. Replacing existing extensions won't work because of
frequent name-space collisions. Instead, I will tack ".html" onto
the URL for each extracted file (i.e. "FILE.DOC" will become "FILE.DOC.html",
not "FILE.html".) The hyperlink in the file listing will not show
the *.html, it will show the usual PDP-10-formatted directory and filename.
Second, make this *.html document be a wrapper that includes the
served text inside of <PRE> tags. This way line-printer spacing will
come out correctly on the browser.
Finally, the stuff inside the <PRE> tags will have to fixed up a bit
to make up for the fact that it is still HTML. e.g. replace
"<" with "<", etc. And replace the line-printer formatting
with HTML formatting where appropriate (i.e. where the line-printer
document had CR-non-LF with a line of underscores, put in the
proper tags to underline, and the same for bolding.) This will
be good because the HTTP transport doesn't recognize CR-without-LF
as being any different than CR-with-LF as it is now anyway.
I think I have the technical means to implement all the above. But first,
a couple of questions that I'm looking for answers to (or at least highly
opinionated comments on!):
Will *.doc.html files be interpreted as being HTML, or will Internet
Exploder defeat this method too?
Will the fact that there is a HTML wrapper around every ASCII document
hurt people? I always intended for the "browsable documents" to be
there for browsing, so it doesn't go against *my* intentions for how people
should use them - but does it go against how people are *actually* using
the documents?
Do all browsers default to monospace fonts for stuff inside <PRE> tags?
(I can try to put in a stylesheet that will try to reinforce the fact
that they *should* be displayed in fixed-space fonts.)
And finally these two $64000 questions:
If I make the HTML document "wrapper" be more than just <PRE> tags - say
I put a navbar showing where this document is in the archive and
referencing the DEC 36-bit hobbyist license - will I be hated and despised?
If the extracted file really is a binary 36-bit file, would it be more
useful if the wrapper presented a disclaimer that it isn't
text and offered the ability to download a tarred and bzipped version
of the file? Notice that this is a way of dealing with the fact that there
are no 36-bit MIME types. The tarred and bzipped version will follow
some yet-to-be-decided-but-probably-already-existing convention for
packing 36-bit words into 8-bit bytes.
Tim.
Eric Smith
> Many of the extensions on those files are different than those
> expected by most web servers or web browsers. Sometimes these are
> 36-bit binary files, for which there is no good MIME type anyway.
> But other files - especially line-printer documents, which by
> pre-Microsoft convention named "*.DOC" - are
> always interpreted by Microsoft (Internet Explorer) browsers as
> Microsoft Word documents.
Or set the server to use the MIME type "text/plain" for .DOC files.
If you're using Apache, you can put the line:
AddType text/plain doc DOC
in either the global server config, or a .htaccess file in the directory.
Much easier than converting documents to HTML, and more useful too.
Because if you do convert to HTML, when people save the files to their
local disk (rather than extracting them from the tape image), they're
in the munged format.
Tim Shoppa
>Or set the server to use the MIME type "text/plain" for .DOC files.
That works for Netscape (and any standards-compliant browser),
but my understanding was that Internet Explorer ignores the MIME type
if the file name ends in *.DOC. (I don't have regular access to
a Windows box to test, but will attempt a re-test tonight.)
Tim.
a.carlini
> Will *.doc.html files be interpreted
> as being HTML, or will Internet
> Exploder defeat this method too?
How about hiding a piece of Javascript in the
preamble of each page that shuts down explorer
and fires up netscape in it's place :-)
>
> Will the fact that there is a HTML wrapper around every ASCII document
> hurt people? I always intended for the "browsable documents" to be
> there for browsing, so it doesn't go against *my* intentions for how people
> should use them - but does it go against how people are *actually* using
> the documents?
Why not provide the link as suggested above and
also a suitable icon (maybe a printer?) for each
file that resolves to the url for the untouched
file. Then you click on one icon for the pretty
viewing version and the other when you want to save
it. Assuming you can detect the browser type (either
in your server or with some javascript) you only need
do the above for IE. (I guess Lynx will be fine anyway,
I have no idea about Opera or the other browsers out
there).
Antonio
--
---------------
Antonio Carlini arca...@iee.org
Tim Shoppa
OK, I just did a test on the URL
http://old-pdp-10.trailing-edge.com/pdp-10/CUSTSUPCUSPMAR86_BB-X130B-SB/AID20A.DOC
This *is* served with MIME type text/plain, I have verified; when I
open it on a Windows machine, it launches MS Word and displays it there.
AFAIK nothing special has been done to this Windows box to make it override
the MIME type.
Tim.
P.S. Thanks for the hints about Apache MIME configuration; the "new" server
needs an attitude readjustment to several of its defaults :-). But the
URL above will do fine for testing.
Zane H. Healy
> been at 95%+ for most of the past day :-). Thanks for recognizing the
> real issue.
What I don't understand is that no one else seems to realize or care.
> I would love to be able to save *much* more than 10% on bandwidth, but a
> technology that will let me save 90% probably will also violate the 2nd
> law of thermodynamics :-). As it is, bzip2 saves up to 35%
> on bandwidth over gzip - and that's enough to convince me to keep it.
> For most tape images, the savings is between 20 and 30%. (These figures
> were all comparing the "default" bzip2 setting against the "best" (-9) gzip
> setting.)
Those kind of numbers are enough to convince me to switch over to bzip2for a
bunch of the stuff on my own site once I can find the time.
Does anything on the paths for downloading the tapes change other than the
file extension? I need to change the links on my Emulation Webpage to point
to your bzip2 files. Hopefully I can get a chance to do that in the next
couple weeks.
Zane
Lars Brinkhoff
> http://old-pdp-10.trailing-edge.com/pdp-10/CUSTSUPCUSPMAR86_BB-X130B-SB/AID20A.DOC
> This *is* served with MIME type text/plain
As expected, Mozilla 0.9.5 honors the MIME type.
--
Lars Brinkhoff http://lars.nocrew.org/ Linux, GCC, PDP-10
Brinkhoff Consulting http://www.brinkhoff.se/ programming
Eric Smith
> That works for Netscape (and any standards-compliant browser),
> but my understanding was that Internet Explorer ignores the MIME type
> if the file name ends in *.DOC.
Ah, typical MS stupidity. I am mercifully ignorant of such things.
I second someone a.carlini's suggestion to have a separate link for
the unfortunate people stuck with MSIE. If serving up such files as
foo.doc.html as you previously suggested works, all you need to do
is generate some symlinks.
Zane H. Healy
> extensions. Replacing existing extensions won't work because of
> frequent name-space collisions. Instead, I will tack ".html" onto
> the URL for each extracted file (i.e. "FILE.DOC" will become "FILE.DOC.html",
> not "FILE.html".) The hyperlink in the file listing will not show
> the *.html, it will show the usual PDP-10-formatted directory and filename.
Off the top of my head, I'd say to use 'FILE.DOC.txt'.
> If I make the HTML document "wrapper" be more than just <PRE> tags - say
> I put a navbar showing where this document is in the archive and
> referencing the DEC 36-bit hobbyist license - will I be hated and despised?
It depends. Will I still be able to access the page with 'lynx'?
Zane
Charles Richmond
a striped across version was available...
--
+-------------------------------------------------------------+
| Charles and Francis Richmond <rich...@plano.net> |
+-------------------------------------------------------------+
Charles Richmond
>
> Eric Sosman wrote:
> >
> > Charles Richmond wrote:
> > >
> > > "Zane H. Healy" wrote:
> > > >
> > > > In alt.sys.pdp10 Tim Shoppa <sho...@trailing-edge.com> wrote:
> > > > > It's a system built entirely from sources, not deviating very
> > > > > far from what anyone would get after following the LFS 3.1
> > > > > instructions:
> > > >
> > > > > http://www.linuxfromscratch.org/
> > > >
> > > > This brings an interesting question to my mind. Would people be interested
> > > > in a striped down, minimalistic version of Linux that is designed with using
> > > > it as a host OS for emulators in mind? It's something I've been considering
> > > > putting together.
> > > >
> > > What color would the stripes be??? (You did say it was "striped down"...)
> >
> > He doesn't know what color the striped kernel is
> > because he brushed the striped paint onto it wrong
> > side out. Easy mistake; done it myself.
>
> That's the famous Zebra kernel. Comes in two basic colors, with a
> single choice of stripe colors for each. The Tiger kernel is a
> derivative, and quite rare today, but more colorful and much
> noisier. It can climb binary trees.
>
Charles Richmond
>
> In article <d9kt4uomapb96853q...@4ax.com>, Bob Supnik
> <bsu...@nauticusnet.com> wrote:
>
> > As one of the lone Windoze users in this community, my complaint would
> > be that bzip2 is not, for some reason, supported by the defacto
> > compression tool, Winzip. There are reasonable bzip2-cognizant tools
> > out there (like PowerArchiver), but it's another step for the Windoze
> > user to go through in getting started. Gzip, tgz, tar, etc are all
> > includes in Winzip.
>
> Use Stuffit Expander. It's not only nicer to use than Winzip, it also
> handles more formats:
>
> StuffIt(TM) (.sit, .sea)
> Zip (.zip),
> UU (.uu, .uue, .enc)
> BinHex (.hqx)
> GZip (.gz, .tgz)
> Arc (.arc)
> MIME/Base 64 (.mime)
> Bzip (.bzip, .bz, .bz2, .tbz)
> LHa (.lha, .lzh)
> Arj (.arj)
> Rar (.rar)
>
And, IIRC, the Alladin Systems company...the one that created
StuffIt Expander...was started by Peter Deutsch. (This sentence
at least keeps the post on-topic for <a.f.c.>.
Foobar T. Clown
>
> OK, I just did a test on the URL
> http://old-pdp-10.trailing-edge.com/pdp-10/CUSTSUPCUSPMAR86_BB-X130B-SB/AID20A.DOC
>
> This *is* served with MIME type text/plain, I have verified; when I
> open it on a Windows machine, it launches MS Word and displays it there.
Hey Tim!
I'm running Netscape Navigator 4.something on a WinDoze PC. Navigator
opens your sample .DOC file as plain text. Why *NOT* let the IE users
suffer in Hell?
But really! I think that if you have the time and resources to make
this work, you should serve up each doc in *TWO* different forms: The
first form would be a .html file that re-creates the the way the
the original would have looked on paper (e.g., with over-strikes
translated to <B> and <U> tags) and the second form would be the
actual, original, unadulterated bits for the more sophisticated visitor
who still has a working line printer at home.
You could do like groups.google.com, and put a link at the top of the
.html version that says, "See this page in its original format."
-- Foo!
jrla...@shell.golden.net
Tim Shoppa <sho...@trailing-edge.com> wrote:
>I thought that bzip2 wouldn't be such a big issue - after all, anyone
>running a PDP-10 emulator has a rather modern platform which can
>run the decompressor, and they also have the technical abilities to
>download and run the bzip2 decompressor (after all, they've already downloaded
>and built an emulator!). I still feel that's true, despite the complaints.
Maybe what we need is a program to front all the nitty-gritty details of
doing compression/expansion. Something that uses a table to tell it how
to recognize how a file has been compressed and then call the right one
with an applicable command line. Something like fstab in Unix. Adding
another compression method would just require adding another line(s) to
that file.
--
john R. Latala
jrla...@golden.net
Mark Hittinger
>>I thought that bzip2 wouldn't be such a big issue - after all, anyone
>>running a PDP-10 emulator has a rather modern platform which can
>>run the decompressor, and they also have the technical abilities to
>>download and run the bzip2 decompressor (after all, they've already downloaded
>>and built an emulator!). I still feel that's true, despite the complaints.
>jrla...@shell.golden.net writes:
>Maybe what we need is a program to front all the nitty-gritty details of
>doing compression/expansion. Something that uses a table to tell it how
>to recognize how a file has been compressed and then call the right one
>with an applicable command line. Something like fstab in Unix. Adding
>another compression method would just require adding another line(s) to
>that file.
I think that we all have to be made to "upgrade" when we've gotten used to
using something. If bzip2 is slow then its a burden on us to profile it
and speed it up. If there are savings on Tim's hardware and Tim's bandwidth
that we are (for free) benefiting from then we ought to at least pony up some
effort :-)
BTW Wu-FTPD has a feature where it can run the compressor of choice on a
requested file download.
I'm not recommending Wu-FTPD because it has had some security issues in the
past and most likely still does - however - it is an interesting trick.
I can imagine the new compress tool - "welcome to the new omni-compression
tool. Unfortunately the instructions for this tool are written in EBCDIC..."
:-)
Later
Mark Hittinger
bu...@netcom.com
David Eppstein
wrote:
> Maybe what we need is a program to front all the nitty-gritty details of
> doing compression/expansion. Something that uses a table to tell it how
> to recognize how a file has been compressed and then call the right one
> with an applicable command line.
Something like a web browser?
--
David Eppstein UC Irvine Dept. of Information & Computer Science
epps...@ics.uci.edu http://www.ics.uci.edu/~eppstein/
Don Quixote
>Maybe what we need is a program to front all the nitty-gritty details of
>doing compression/expansion. Something that uses a table to tell it how
>to recognize how a file has been compressed and then call the right one
>with an applicable command line. Something like fstab in Unix. Adding
>another compression method would just require adding another line(s) to
>that file.
A long time ago there was something called SHEZ in x86 DOS, now I wonder
what its ancestors were.
Don Quixote
>OK, I just did a test on the URL
>http://old-pdp-10.trailing-edge.com/pdp-10/CUSTSUPCUSPMAR86_BB-X130B-SB/AID20A.DOC
>
>This *is* served with MIME type text/plain, I have verified; when I
>open it on a Windows machine, it launches MS Word and displays it there.
>AFAIK nothing special has been done to this Windows box to make it override
>the MIME type.
Data point: Here on a NT4 (x86) Opera 5.12 wants to open word and requires
handholding to view as text, Netscape 4.61 opens it as text. I saw no
point in attempting to use IE for this test. Or Word.
Phil Gustafson
>>
>> That's the famous Zebra kernel. Comes in two basic colors, with a
>> single choice of stripe colors for each. The Tiger kernel is a
>> derivative, and quite rare today, but more colorful and much
>> noisier. It can climb binary trees.
>>
>Inorder, preorder, postorder, or disorder???
>
Ph.
>+-------------------------------------------------------------+
>| Charles and Francis Richmond <rich...@plano.net> |
>+-------------------------------------------------------------+
--
Phil Gustafson <ph...@panix.com>
There is a tarantula in the song, of course. I remember when you
could ask your grocer to save one for you. -- Casady
Peter Ibbotson
"Tim Shoppa" <sho...@trailing-edge.com> wrote in message
news:a2sgi...@drn.newsguy.com...
>
http://old-pdp-10.trailing-edge.com/pdp-10/CUSTSUPCUSPMAR86_BB-X130B-SB/AID2
0A.DOC
>
> This *is* served with MIME type text/plain, I have verified; when I
> open it on a Windows machine, it launches MS Word and displays it there.
> AFAIK nothing special has been done to this Windows box to make it
override
> the MIME type.
Since I always use the open/save dialog box before downloading anything like
this not really a big problem.
Most of your users should be able to sort this out.
Personally providing Opera, Lynx and Netscape get the Mime type right, us IE
users should just live with it.
A note on the front page might not be a bad plan (same place as you explain
bzip2 perhaps?) but since I suspect most folks might well right-click-save
anyway... why worry.
Many thanks for asking your potential user base, but don't worry about this
one too much.
jmfb...@aol.com
>>
>> In article <xxJ38.24750$h31.2...@e420r-atl1.usenetserver.com>, "Zane
H.
>> Healy" <hea...@shell1.aracnet.com> wrote:
>>
>> >In alt.sys.pdp10 Ms. 4.88's <> wrote:
>> >> I really hate it when people keep switching formats, and IMHO, 10%
isn't
>> worth
>> >> it. 50%, maybe, but not 10%
>> >
>> >When Tim is maintaining a archive with over a Gigabyte of tape images
of
>> >PDP-10 software, I think 10% is worth it to him. Remember, he's the
one
>> >providing the network bandwidth.
>
>And as if to prove your point, outgoing bandwidth from the archive has
>been at 95%+ for most of the past day :-). Thanks for recognizing the
>real issue.
Whoa!! That's good news :-).
<snip>
>And I thought that the archive users would be more appreciative of
>the fact that better compression saves them time in downloading, too :-)
I'll apologize for one of them. I didn't get him trained well;
I was just too sick to finish that job.
>
>Bzip2 is not only the future, it is also the present. Other sites that
>are pressed for bandwidth and tight on money (e.g. www.kernel.org) are
either
>requiring or strongly encouraging users to switch to it. I'll do my
>best to ease the transition, but it's the way I gotta go.
Personally, I don't care if the improvement is a figment of your
imagination :-). You are the one doing the work and, if you think
it will help you, you should do it. I can't even imagine accurately
the amount of work you're putting into this project (but I know
how much time I spent trying to keep bits in tact and it's as
simple as some people may think despite all of my attempts to
teach them).
Paul Repacholi
> A number of possible workarounds were proposed (beyond the solution
> of "let IE explorer users suffer in hell"), and I think I have the
> technical means to implement one of them:
This is the ONLY solution. They have dug their pit, let them wallow
in it.
Don't pander to M$, you only help billygoat's greed spread even deeper
into everything. "Problems with exploder? FOAD"
--
Paul Repacholi 1 Crescent Rd.,
+61 (08) 9257-1001 Kalamunda.
West Australia 6076
Raw, Cooked or Well-done, it's all half baked.
EPIC, The Architecture of the future, always has been, always will be.
jmfb...@aol.com
Tim Shoppa <sho...@trailing-edge.com> wrote:
<snip>
>Keep in mind that this is discussing individual files that are supposed
>to be browsable, not the tape images that were the subject of the bzip2 vs
>gzip discussion. Also keep in mind that many of these documents go back
>to the 1960's, so simply saying "don't use *.DOC for them" is not only
>impractical, it hits a raw nerve in a very broad community.
<snip>
A little history on the TOPS-10 side...*.DOC files used to be
useful before we finally figured out how to ship the documentation
at the same time as the software. Before we did that DOC files
used to contain all of the technical information that was needed
to use new (or fixed) implementations. By the time I started
working on the packaging (early 80s), the DOC files were mostly
(there were exceptions) a waste of magtape space. One of the
my proposals was to eliminate all of the DOC files from the
TOPS-10 distribution tapes, but I lost that one because
people weren't ever looking at the contents but at the tradition.
I am not speaking for language distribution tapes nor TOPS-20
monitor distribution tapes. So they may have used those files
for something useful.
One of the things I'd like to bean Gates over the head is
his changing of the DOC extension meaning. He knew better.
Another tidbit of info is that DOC is the default extension of
RUNOFF output when the source has an extention of RND.
I don't have any good suggestions for your problem because
DOC had an implied meaning for the content of the file. If
you do have to change the extension to get around the Gates'
idiocy, I don't have a problem with it.
jmfb...@aol.com
"Foobar T. Clown" <fu...@gazonk.del> wrote:
>Tim Shoppa wrote:
>>
>> OK, I just did a test on the URL
>>
http://old-pdp-10.trailing-edge.com/pdp-10/CUSTSUPCUSPMAR86_BB-X130B-SB/AID
20A.DOC
>>
>> This *is* served with MIME type text/plain, I have verified; when I
>> open it on a Windows machine, it launches MS Word and displays it there.
>
>
>Hey Tim!
>
>I'm running Netscape Navigator 4.something on a WinDoze PC. Navigator
>opens your sample .DOC file as plain text. Why *NOT* let the IE users
>suffer in Hell?
>
>But really! I think that if you have the time and resources to make
>this work, you should serve up each doc in *TWO* different forms: The
>first form would be a .html file that re-creates the the way the
>the original would have looked on paper (e.g., with over-strikes
As the person who probably typed a lot of those files, ;-)
I didn't type them up to do overstrikes. We ran a test
to try it, but the quality turned out to be lousy.
/BAH
<snip>
Arthur Krewat
>
> Tim Shoppa <sho...@trailing-edge.com> writes:
>
> > A number of possible workarounds were proposed (beyond the solution
> > of "let IE explorer users suffer in hell"), and I think I have the
> > technical means to implement one of them:
>
> This is the ONLY solution. They have dug their pit, let them wallow
> in it.
>
> Don't pander to M$, you only help billygoat's greed spread even deeper
> into everything. "Problems with exploder? FOAD"
I tend to agree on this - in 10 years whatever workaround you do to get
it to work will no longer work - wait, 10 years? What am I saying?
10 MONTHS
<snip lots of my own anti-ms sentiment>
aak
Ben Clifford
> One of the things I'd like to bean Gates over the head is
> his changing of the DOC extension meaning. He knew better.
> Another tidbit of info is that DOC is the default extension of
> RUNOFF output when the source has an extention of RND.
When I was using MS-DOS, I think I used to use the .doc extension to
mean *any* word-processor's / text editor's output - I probably picked
this up from stuff downloaded off BBSes[1].
The extensions people used didn't seem to necessarily be design for
machine recognition.
The .me extension of the common READ.ME file would cause it to be hidden
from automatic recognisers.
That was(?is) a common cause of lost files (lost in the sense of can't
find them, not lost in the sense of deleted forever) on some sites where
I have done tech support: user saves a word file as letter.53 (they use
. because it is one of the obvious choices after discovering you can't
use <SPACE>), then goes to reload it - the file isn't there :-(
When you name a file, MS-Word would append the .doc extension
automatically, so you can just type in "letter" and get "letter.doc" by
magic.
If you type in "letter.53", it would detect that you have already
supplied an extension and doesn't add .doc.
Then when you go to load, it would only show files matching *.doc.
It was a feature that to begin with might have been useful, but as time
went by and they were trying to hide more and more of difficult to
understand concepts (like extensions!) from the user, it turned into a
bug.
Then W95 came along and you could put several dots in filenames, and you
got a whole different set of bugs :-(
[1]Or however one pluralises BBS.
--
Ben Clifford
http://www.hawaga.org.uk/ben/ GPG: 30F06950
webcam: http://barbarella.hawaga.org.uk/benc-cgi/watchers.cgi
Do not ever send e-mail to: phi...@hawaga.org.uk (seriously!)
Lars Poulsen
> Many of the extensions on those files are different than those
> expected by most web servers or web browsers. Sometimes these are
> 36-bit binary files, for which there is no good MIME type anyway.
> But other files - especially line-printer documents, which by
> pre-Microsoft convention named "*.DOC" - are
> always interpreted by Microsoft (Internet Explorer) browsers as
> Microsoft Word documents.
>
I am 100% in agreement with those who have paointed out that the HTTP
protocol
specification addresses this issue comprehensively (through the
Content-type tag),
and that the apparent problem here is entirely caused by Microsoft
arrogance, namely
that MSIE ignores the perfectly good MIME Content-type that comes with
the document
and insists on using the tail end of the filename to determine the
.content type.
What is even worse, is that even so, the design of the Windows desktop
provides
for entering into the registry multiple descriptions for the content
type implication
of the filename extension. When this is correctly configured, the
default "Open" action
associated with the file type in the desktop explorer is replaced by an
action named
"Open with ...", which brings up a dialog box to select the proper
application
to use for opening the file, selecting among only the two or three that
are "known"
to be candidates. I have seen this get set up for some of the graphical
image file
formats as a result of installing some image editors. Unfortunately, I
have no idea how
to do this, and I have spent a fair number of hours trying to fiddle
with the
suff in Explorer's "View:Folder Options:File Types".
Working around it by renaming the files is pretty broken, and is not a
true solution,
because of other Windows broken-ness: Out of the box, the Windows desktop
fodler options has the "Hide known file types" enabled, so that an
xxx.doc.txt
file on the local disk drive is displayed as "xxx.doc" with a NOTEPAD icon,
wihile a file truly named "xxx.doc" is displayed as "xxx" with a WINWORD
icon.
You can imagine the amount of confusion when people try to download
these files
to their local disk and rename them to something useful on the way in.
I have experienced this firsthand is dealing with the products put out
by my
workgroup: We supply firmware upgrades for some products in the form of
hex-encoded code images (S-records) with a file name ending in .DWN for
download. MSIE insists on downloading these as xxx.DWN.TXT or
.xxx.DWN.HTM,, causing lots of grief in talking people through a procedure
where we can't predict what they will see on their screen display because it
depends on how sanely - or not - they have adjusted their desktop settings.
So, let me assure you that your proposed workaraund will not FIX the
problem,
it will just shift it to an even moe squirrelly manifestation.
It it any wonder that so many of us HATE Microsoft?
jrla...@shell.golden.net
David Eppstein <epps...@ics.uci.edu> wrote:
>In article <a2t5vb$c6$1...@shell.golden.net>, jrla...@shell.golden.net
>wrote:
>
>> Maybe what we need is a program to front all the nitty-gritty details of
>> doing compression/expansion. Something that uses a table to tell it how
>> to recognize how a file has been compressed and then call the right one
>> with an applicable command line.
>
>Something like a web browser?
I thought of that as I was typing my post but I was thinking more of a
commandline utility of Unix. Actually a shell command might do nicely,
File to find out what kind of file it is, then grep the configuration file
to get the decompress command. Might be easier in perl.
Rich Alderson
> You're thinking of Apple Gunkies. They came in blue and aqua.
Oh my GOD! Suddenly I understand the color scheme on the original iMac!
* I only knew about "Blue Apple Gunkies"--and them only second-hand.
** Ewww. Does *that* conjure up the wrong picture!
--
Rich Alderson alders...@panix.com
"You get what anybody gets. You get a lifetime." --Death, of the Endless
Charlie Gibbs
writes:
>One of the things I'd like to bean Gates over the head is
>his changing of the DOC extension meaning. He knew better.
If he did, then it's all the more understandable. One of his
standard techniques is to pervert an existing standard - look at
Java, for instance. He hides his shenanigans behind fancy-sounding
phrases like "embrace and extend", but it's all part of the plot.
--
cgi...@sky.bus.com (Charlie Gibbs)
Remove the first period after the "at" sign to reply.
I don't read top-posted messages. If you want me to see your reply,
appropriately trim the quoted text and put your reply below it.
Charlie Gibbs
kre...@bartek.dontspamme.net (Arthur Krewat) writes:
Let me add my vote of agreement. Turnabout is fair play. After having
had too many sites tell me to FOAD if I refuse to download the latest
version of IE ("click here!") - a hell of a lot of good it'd do me on
my Amiga or Linux box - it'd be gratifying to give these people a dose
of their own medicine. Besides, I would think that most of the people
who are interested in this material wouldn't find it that great a
hardship to find another browser; in fact, those who haven't done
so already would probably appreciate the nudge.
><snip lots of my own anti-ms sentiment>
Ditto.
Peter Seebach
>I thought of that as I was typing my post but I was thinking more of a
>commandline utility of Unix. Actually a shell command might do nicely,
>File to find out what kind of file it is, then grep the configuration file
>to get the decompress command. Might be easier in perl.
Mine is in 'sh', and it does a pretty good job. It doesn't currently use a
config file, but it does a tolerable job at guessing what to use on most
files. It used to be named "open", but when I ported my utilities to OS X,
there was a name clash, so now it's "rezrov", which is a better name anyway.
-s
--
Copyright 2001, all wrongs reversed. Peter Seebach / se...@plethora.net
$ chmod a+x /bin/laden Please do not feed or harbor the terrorists.
C/Unix wizard, Pro-commerce radical, Spam fighter. Boycott Spamazon!
Consulting, computers, web hosting, and shell access: http://www.plethora.net/
jmfb...@aol.com
"Charlie Gibbs" <cgi...@sky.bus.com> wrote:
>In article <a2u9sa$7sr$2...@bob.news.rcn.net> jmfb...@aol.com (jmfbahciv)
>writes:
>
>>One of the things I'd like to bean Gates over the head is
>>his changing of the DOC extension meaning. He knew better.
>
>If he did, then it's all the more understandable. One of his
>standard techniques is to pervert an existing standard - look at
>Java, for instance. He hides his shenanigans behind fancy-sounding
>phrases like "embrace and extend", but it's all part of the plot.
>
Note that both he and Allen used the -10. By that time, we
had the naming conventions well documented, completely implemented,
and distributed. The names we picked were not just DEC-only. When
we picked names, other platforms had to be considered because
our customers had them hooked into their networks. (TOPS-10
had heterogenius(sp?) networks back then). There were a lot
of names that had been proposed but were rejected because other
companies already used them. <sheesh> We didn't design our
stuff in a vacuum.
Ian Stirling
>
>>Tim Shoppa <sho...@trailing-edge.com> wrote:
>>>I thought that bzip2 wouldn't be such a big issue - after all, anyone
>
>>Maybe what we need is a program to front all the nitty-gritty details of
>>doing compression/expansion. Something that uses a table to tell it how
> I think that we all have to be made to "upgrade" when we've gotten used to
> using something. If bzip2 is slow then its a burden on us to profile it
> and speed it up. If there are savings on Tim's hardware and Tim's bandwidth
I'm pretty sure it's inherently slow, from the very, very brief look I took,
there diddn't seem to be any obvious speedups.
--
http://inquisitor.i.am/ | mailto:inqui...@i.am | Ian Stirling.
---------------------------+-------------------------+--------------------------
Tad Williams has an interesting new fantasy: http://www.shadowmarch.com/
Frank da Cruz
Lars Poulsen <la...@beagle-ears.com> wrote:
: Tim Shoppa wrote:
:
: > Many of the extensions on those files are different than those
: > expected by most web servers or web browsers. Sometimes these are
: > 36-bit binary files, for which there is no good MIME type anyway.
: > But other files - especially line-printer documents, which by
: > pre-Microsoft convention named "*.DOC" - are
: > always interpreted by Microsoft (Internet Explorer) browsers as
: > Microsoft Word documents.
: ...
: It it any wonder that so many of us HATE Microsoft?
:
Everything Microsoft does is deliberately designed to stamp out plain text
as the basis for interoperability among diverse platforms. .DOC and .HLP
files are just the tips of the iceberg and yes, they knew better. Spaces
in filenames work only in GUI dialog boxes and break every text-mode
software program in existence (even their own "Command prompt" (*)).
Promulgating proprietary code pages and document formats all over the
Internet through e-mail and web authoring systems. Until Windows (well,
in fairness also the Macintosh) came along, there was always a plain-text
(perhaps lowest common denominator, perhaps not) way for the user of one
computer to access another computer and get an interactive command shell
and exchange data. But that promotes diversity.
OK, in more fairness, it isn't only Windows and Macintosh -- it really
started with CP/M and Apple II, so it's actually any desktop OS. Fine.
But it wasn't a problem as long as those OS's stayed on the desktop. So
really, the crime is trying (and succeeding!) to replace all the world's
computing history, culture, and accumulated wisdom with a desktop OS that
never was intended to be used except from its own physical keyboard, mouse,
and screen, and that took the state of the art about 12 steps backwards,
forcing all the hard-won concepts of the 1960s, 70s, and 80s
(multiprocessing, multiuser file systems, security, preemptive
multitasking, ...) to be reinvented and grafted on as aftertoughts,
usually in some perverted and fatally inadequate form.
There is some rather hilarious commentary in this vein here:
http://www.pbs.org/cringely/pulpit/pulpit20020117.html
I especially liked the bit at the end, describing how Microsoft will create
a new era of Trustworthy Computing.
(*) At the Command prompt in Windows XP 5.1.2600, try to CD to
C:\Program Files:
C:\> cd Program Files
Too many parmeters - files
C:\> cd "Program Files"
Parameter format not correct - "Program
C:\> cd Program" "Files
Parameter format not correct - "Files
- Frank
Robert Bonomi
Folks, there is an _existant_ protocol for this. it's even an RFC standard.
The magic word is "MIME" and the associated database. On Unix boxes its
generally called "mimecap". It consists ofthe MIME data-type, e.g.
"application/bzip", and the command-line that would be used to view the content,
including a place-holder to indicate where the actual filename should be
injected.
By simply adding that one line to the mimecap file (or equivalent), any MIME-
compliant web-browser, *and* any MIME-compliant mail-reader, AND _any_other_
MIME-compliant tools you might have on your system, will =ALL= "magically"
be able to handle bzip-compressed files.
The overall logic for MIME is "tag the data with the correct identification,
and let the far end figure out what to do with it". Every MIME-based tool
that _I_ have used gave you the option of 'save to disk', exactly as received,
if it was an 'unrecognized' format. Thus, you can download now, and find the
processing/viewing utility later.
On the "non MS-Word .DOC" file issue. the advice is WRITE TO THE STANDARDS.
In this instance, that means tag them as "text/plain", use the original file
names, and let the chips fall where they may. You're doing the right thing,
and it _will_ display properly on any browser that _follows_ the published
stnadards. Catering to broken software provides no incentive to the vendor
thereof to *fix* said broken software.
If you know that some widely-used POS software violates the standards, then
you _consider_ adding an "Important info for POS-software users" link -- that
warns about the issue. and discusses how to work around the problem, if a work-
around exists, that is.)
rob...@bonomi.invalid
Folks, there is an _existant_ protocol for this. it's even an RFC standard.
The magic word is "MIME", and the associated database. On Unix boxes its
generally called "mimecap". It consists of the MIME data-type, e.g.
"application/bzip", and the command-line that would be used to view the content,
including a place-holder to indicate where the actual filename should be
injected. Applications can let that output display directly, or capture it
for post-processing before display.
Ben Franchuk
I think the real problem is file extensions are a hint of what is
in a file, not really what you want to do with the file. *.c normally
is a C language file and normally you only edit or compile the file.
If I was writing a book chap1.a chap1.b chap1.c may be sections of
chapter is some weird typesetting language. MIME is ok for one or
two extensions but it does not promote a good way to manage files.
I use a text editor to edit my html pages, and I have fight the defaults
in the system all the time. This is a OS problem not a file problem
and the whole OS design logic is in question.
--
Ben Franchuk - Dawn * 12/24 bit cpu *
www.jetnet.ab.ca/users/bfranchuk/index.html
Mark Crispin
> (*) At the Command prompt in Windows XP 5.1.2600, try to CD to
> C:\Program Files:
>
> C:\> cd "Program Files"
This works just fine for me. I do it all the time, and have since NT3.1
One little hack that MS has is that end of line is an implicit close
quote, so
C:\> cd "Program Files
works. The only problem is, I then start forgetting the close quote on
UNIX, and end up doing
!!"
a lot...
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Charlie Gibbs
(Frank da Cruz) writes:
>(*) At the Command prompt in Windows XP 5.1.2600, try to CD to
> C:\Program Files:
>
> C:\> cd Program Files
> Too many parmeters - files
>
> C:\> cd "Program Files"
> Parameter format not correct - "Program
>
> C:\> cd Program" "Files
> Parameter format not correct - "Files
Wow, that's a new one. On my Win98 box, your second example
(cd "Program Files") works just fine. I guess Bill figured
it was time to break some more of the command-line interface.
By nibbling away at it a little at a time, he should be able
to do away with it completely before anybody realizes what's
happening.
Mark Crispin
> started with CP/M and Apple II, so it's actually any desktop OS. Fine.
Yup. Don't forget Atari and Commodore either.
And wasn't the original PC DOC file format from a program other than Word?
> But it wasn't a problem as long as those OS's stayed on the desktop. So
> really, the crime is trying (and succeeding!) to replace all the world's
> computing history, culture, and accumulated wisdom with a desktop OS
Frank, you of all people should know why the microcomputer revolution
happened.
> that took the state of the art about 12 steps backwards,
> forcing all the hard-won concepts of the 1960s, 70s, and 80s
> (multiprocessing, multiuser file systems, security, preemptive
> multitasking, ...) to be reinvented and grafted on as aftertoughts,
> usually in some perverted and fatally inadequate form.
I blame DEC much more for this than MS. DEC not only failed to preserve
these, in some cases DEC deliberately killed them.
DEC blew multiple opportunities to build a follow-on PDP-10 processor, and
when finally they had a technical failure rather than an internal
political failure they declared the PDP-10 to be "garbage" (you know as
well as I who used that word) and killed it.
VMS was an aberration, and hopefully will soon be nothing more than an
evil memory.
MS filled a vacuum. Had there been a viable world from the past, MS would
have remained a tiny company.
WinXP has its problems (oh does it have its problems!). But deep down
inside, there are lessons from the TOPS-20 world well-hidden. There are
even some erstwhile TOPS-20 developers working there.
I'm not interesting in fighting MS. I'm interested in conquering them
from within. Maybe by the time I retire we'll be back to where we were
in 1983.
Mark Crispin
> On the "non MS-Word .DOC" file issue. the advice is WRITE TO THE STANDARDS.
>
> In this instance, that means tag them as "text/plain", use the original file
> names, and let the chips fall where they may. You're doing the right thing,
> and it _will_ display properly on any browser that _follows_ the published
> stnadards. Catering to broken software provides no incentive to the vendor
> thereof to *fix* said broken software.
I agree. There's even some hope to getting MS to treat TEXT/PLAIN as text
even if the file ends with ".DOC".
Don Chiasson
"Frank da Cruz" <f...@columbia.edu> wrote in message
news:a318rr$3vb$1...@watsol.cc.columbia.edu...
<<snip>>
> (*) At the Command prompt in Windows XP 5.1.2600, try to CD to
> C:\Program Files:
>
> C:\> cd Program Files
> Too many parmeters - files
>
> C:\> cd "Program Files"
> Parameter format not correct - "Program
>
> C:\> cd Program" "Files
> Parameter format not correct - "Files
Interesting example of breaking things. I tried this same
command in Win98Se, Win ME, and Win95 and it worked
in all of them,
Don
e-mail: it's not not, it's hot.
Don Chiasson
"Don Chiasson" <don_ch...@notmail.com> wrote in message
news:Rn_48.5302$bIE....@news1.bloor.is...
.....Oops, I meant that C:\ cd "program files" (independent of
capitalization) worked in the three versions of windoze I have
here. Sorry.
Eric Smith
> I think the real problem is file extensions are a hint of what is
> in a file, not really what you want to do with the file. *.c normally
> is a C language file and normally you only edit or compile the file.
> If I was writing a book chap1.a chap1.b chap1.c may be sections of
> chapter is some weird typesetting language.
The files should probably be named "chap1.a.tex" etc. (substitute extension
used by your favorite weird typesetting language.)
Or, if for some reason you don't want a "proper" extension, or don't like
having two dots in the name, "chap1a", "chap1_a", "chap1a.tex", or
something.
You can obviously name your files however you like, subject to the
limitations of the file system. But if you don't follow conventions, then
you can't expect the default behavior of tools to be what you want.
Peter Ibbotson
news:3C530279...@beagle-ears.com...
> What is even worse, is that even so, the design of the Windows desktop
> provides
> for entering into the registry multiple descriptions for the content
> type implication
> of the filename extension. When this is correctly configured, the
> default "Open" action
> associated with the file type in the desktop explorer is replaced by an
> action named
> "Open with ...", which brings up a dialog box to select the proper
> application
> to use for opening the file, selecting among only the two or three that
> are "known"
Failing that you can hand edit the registry each fiile extenson lives under
HKEY_CLASSES_ROOT, giving a Mime type and the program to open with under the
OpenWithList sub entries.
On my XP system going to "open with" will let you add more file extensions.