Thanks, I'll look at those.
From: Dan Gahlinger
Sender: cctalk-bounces at classiccmp.org
To: cctalk at classiccmp.org
ReplyTo: General Discussion: On-Topic and Off-Topic Posts
Subject: RE: Recommend an IRC server
Sent: 3 Nov 2011 12:40
Unreal is crap. :)
check out InspIRCd
though I used to use UltimateIRC
> Date: Thu, 3 Nov 2011 10:57:48 +0000
> From: vintagecoder at aol.com
> To: cctalk at classiccmp.org
> Subject: Re: Recommend an IRC server
> From: Daniel Seagraves <dseagrav at lunar-tokyo.net>
> > I run an Unreal ircd for a friend, it doesn't suck up too much. If you
> > don't need services it should be pretty straightforward.
> I prefer to avoid GPL-anything but it's not always possible. I'll look into
> this one a bit.
> Thank you.
Can anyone recommend an open source IRC server, preferably BSD or MIT-style licensed, that doesn't have dependencies on scripting languages or much else? I'd like a pure C, C++ etc. solution if possible.
I'm looking for something to test socket applications against. It doesn't have to be a super duper server or have zillions of features. Something basic would be good enough, but I will want to build and run it on several platforms.
On Tue, 1 Nov 2011 20:53:59 +0000 (GMT), ard at p850ug1.demon.co.uk (Tony
> You all know what I meant by the vacuum 'leaking out' of a CRT, right
> :-). Perhaps this analogy will help to explain why I said it.
Of course, it was perfectly obvious, although rather a nice way of
putting it I thought.
The analogy that immediately came to my mind was that of holes in a
semiconductor constituting a current of positive charges.
I suppose one could also say that debt leaks into my bank account and
is removed when my salary gets paid. All the while leaving a negative,
reducing charge of debt in the account.
I've been trying to contact Paul Anderson <useddec at gmail.com> for a couple
weeks but haven't gotten a reply. Does anyone know what's up? Paul, if
you're reading this, would you please contact me by private email?
dgriffi at cs.csubak.edu
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
Q: What is the most annoying thing in e-mail?
Has anyone sat down and worked out interchangeability of memory parts on
16-bit core based systems. I'm thinking in terms of things like PDP-11s
HP 21xx and DG Novas. I'm curious if anyone has compiled such a thing,
aside from direct part number comparison -- or has guidance of non-like
core stack replacement. I'm not planning on attempting to do anything of
the kind just now, but it might be useful to know what's possible as
----- Original Message -----
From: <cctalk-request at classiccmp.org>
To: <cctalk at classiccmp.org>
Sent: Wednesday, October 26, 2011 6:00 PM
Subject: cctalk Digest, Vol 98, Issue 78
>You have to consider the wife factor as well. A friend of mine gave
>me an Apple //+ a while back, and she threatened to insert it in him
>rectally. I have loads of my future 8-bit computer museum hidden in
>my loft for after the divorce... (;
(Raises hand) - so would this be an embedded processor?
> Does the diellectric strength increase back to its original value on
> cooling again? If so, then this is not really a problem if you happen to
> heat a CRT part (pin, bit of the envelope) with a soldering iron while
> working on the device.
That would seem likely since the glass was once melted in order to make
the CRT. Whether continuous arcing damages the glass permanently or not
is another question. I would guess that the heat in itself does nothing
irreversible, but arcing does.
I found this in a text about types of glass and manufacturing procedures
for CRTs. It did not mention whether the damage was reversible or not.
Your observation about connecting a glass rod across the mains and
heating it certainly supports their warnings about reduced dielectric
On the other hand, I would suppose that severe localised heating could
cause the glass to crack due to local expansion creating excessive
stresses, so I would still be very careful with the soldering iron.
Al Kossow wrote:
> And what prevents them from "archiving" anything you send them?
I'm not really sure what you mean by that. People send us stuff to
archive. Sure, there is not much point sending SPS stuff if it's not
in scope for the project because that project is only concerned with
preservation of unmodified and undamaged commercial software. Our
commercial venture KryoFlux does provide a service to help people
generate IPFs. That is something else entirely and completely
independent from SPS (other than the same people are involved, and it
uses technology developed for SPS). That is a professional service as
you would expect, any data generated is destroyed as per an agreed
Nothing stops anyone "archiving" other people's data. Most people
don't do it because it is unethical - I am not sure why you might
think it would be different for us?
> My feelings exactly. I can't imagine any professional archive taking this group seriously, and it is
> completely opposite of CHM's policy of preserving and making available any information on underlying
> media formats that we find.
I'd be interested to understand why you think this. What are we doing
wrong? Is it wrong to want to fund our preservation work by starting a
commercial venture? What are we not making available? We've released
the IPF library source, including an extremely accurate, cycle exact
FDC emulator. We also have tons and tons of information on the SPS
website about how things work (WIPs). IPF files contain the
information about each disk formats, and now that is open, I am not
really sure what else we can do? I am genuinely interested, because we
do want to do the right thing (even if it might take us a while).
Steven Hirsch wrote:
>> From their FAQ.
> Thanks for pointing that out. They are welcome to use whatever
> business/IP model they wish, but this one bothers me enough that I would
> avoid the device.
That section of the FAQ is not actually completely relevant in this
case. It refers to producing IPFs. If you want to write sector images,
then there is of course no real need to create IPFs anyway in this
case I guess.
Our IPF creation software is a commercial product, and helps fund our
preservation activity. Now that the IPF library has been open source,
there isn't anything stopping somebody creating something similar of
course, so that FAQ is out of date too.
Steven Hirsch wrote:
> I'm pleased to see the project opening up (release of library source,
> etc). I was a bit uncomfortable with what I perceived to be a proprietary
> approach earlier on.
We got there eventually at least. :)
> What would really be the clincher for me is the ability to take a sector
> image of the various machines, e.g. an Apple ProDOS or DOS 3.3 "*.po"
> image and write it to a diskette. I get the impression that it currently
> has the ability to read flux transitions and extract such sector images,
> but nothing mentions the capability of re-creating a track image and
> writing them out to media.
That is not currently supported, no. We decided to do the hardest part
first, writing IPF files, and doing it really well. As stated on our
forums, other files, such as sector images, will come later. We are
doing some C64-related work at the moment, but the plan is to support
sector images for writing next.
It almost goes without saying that, if it's sector images somebody
needs for writing, then wait for that before getting a device.
> I have an interest in archiving, but I'm also an avid tinkerer with old
> hardware and often need to generate "real" diskettes from a sector image.
Yes, absolutely. This is definitely a missing piece right now.
I hope that helps clarify things.