From: Bill Todd on 24 Dec 2009 18:51
Andy "Krazy" Glew wrote:
> At the moment my newsreader (I switched back to Thunderbird from
> Seamonkey) is my only non-cloud based app. The only app that ties me to
> a particular machine, which I cannot use when that machine is not
You do know that you can place TBird's data (it's 'profile') anywhere
(e.g., somewhere in the cloud) such that you can use it from anywhere
you can run a (compatible) copy of TBird, right?
From: "Andy "Krazy" Glew" on 24 Dec 2009 21:15
Bill Todd wrote:
> Andy "Krazy" Glew wrote:
>> At the moment my newsreader (I switched back to Thunderbird from
>> Seamonkey) is my only non-cloud based app. The only app that ties me
>> to a particular machine, which I cannot use when that machine is not
> You do know that you can place TBird's data (it's 'profile') anywhere
> (e.g., somewhere in the cloud) such that you can use it from anywhere
> you can run a (compatible) copy of TBird, right?
> - bill
1) I did not know that. Thanks, I will look into it.
2) It doesn't help me, since I really want to read news from a machine
systems that can run tty apps in a browser window. I'm not aware of any
way to run Tbird on machine 1 from a browser on machine 2.
Am I missing that? Is there a non-X way of running Tbird?
From: Robert Myers on 24 Dec 2009 21:46
On Dec 24, 6:43 pm, Bill Todd <billt...(a)metrocast.net> wrote:
> Andy "Krazy" Glew wrote:
> > Robert Myers wrote:
> >> I can't see anything about channels that you can't do with modern PC I/O.
> > AFAIK there isn't much that IBM mainframe channels could do that modern
> > PC I/O controllers cannot do. Even a decade ago I saw SCSI controllers
> > that were more sophisticated than IBM channels.
> I may be missing something glaringly obvious here, but my impression is
> that the main thing that channels can do that PC I/O controllers can't
> is accept programs that allow them to operate extensively on the data
> they access. For example, one logical extension of this could be to
> implement an entire database management system in the channel controller
> - something which I'm reasonably sure most PC I/O controllers would have
> difficulty doing (not that I'm necessarily holding this up as a good
> PC I/O controllers have gotten very good at the basic drudge work of
> data access (even RAID), and ancillary DMA engines have added
> capabilities like scatter/gather - all tasks which used to be done in
> the host unless you had something like a channel controller to off-load
> them. But AFAIK channels they ain't.
So, let's see.
I'm still just trying to get at the heart of the matter.
I could (and did) hang a complete 32-bit processor off a PC/XT bus.
The 32-bit processor (which was a single board computer), depended on
the host OS for I/O. If I used concurrent DOS, I could do whatever I
wanted on the host 8-bit computer while the 32-bit mini ground away on
problems formerly done at great expense on a Cray. Which was the
channel? Why should I care? The most natural way of looking at it
(as you describe things) is to think of the "host" PC, which was
utterly programmable, as a mainframe channel, except that it cost
hundreds of thousands of dollars less and didn't come with that
priceless baby-blue logo.
Where's the magic? Or am I (as usual) dealing with people who have
drunk someone's Kool-Aid? How did DEC do similar things?
Mainframes and obscure JCL forever (not).
From: Del Cecchi on 24 Dec 2009 23:51
"Robert Myers" <rbmyersusa(a)gmail.com> wrote in message
On Dec 24, 8:33 am, Terje Mathisen <"terje.mathisen at tmsw.no">
> Robert Myers wrote:
> > On Dec 23, 12:21 pm, Terje Mathisen<"terje.mathisen at tmsw.no">
> >> Why do a feel that this feels a lot like IBM mainframe channel
> >> programs?
> >> :-)
> > Could I persuade you to take time away from your first love
> > (programming your own computers, of course) to
> > elaborate/pontificate a
> > bit? After forty years, I'm still waiting for someone to tell me
> > something interesting about mainframes. Well, other than that IBM
> > bet
> > big and won big on them.
> > And CHANNELS. Well. That's clearly like the number 42.
> Del have already answered, but since I know far less than him about
> systems, I'll try anyway:
> As Del said, an IBM mainframe has lots of dedicated slave
> think of them as very generalized DMA engines where you can do stuff
> seek to and read block # 48, load the word at offset 56 in that
> and compare with NULL: If equal return the block, otherwise use the
> at offset 52 as the new block number and repeat the process.
> I.e. you could implement most operations on most forms of diskbased
> structures inside the channel cpu, with no need to interrupt the
> before everything was done.
Thanks for that detailed reply, Terje.
I tend to think there is something important I am still missing.
Maybe my lack of appreciation of mainframes comes from never having
been involved in the slightest with the history, except briefly as a
frustrated and annoyed user.
I can't see anything about channels that you can't do with modern PC
O. You send "stuff" to a peripheral device and it does something with
it. It's generally up to the peripheral to know what to do with the
"stuff," whatever it is. In the case of a TCP/IP offload engine, the
what to do could be quite complicated.
The things you *can't* do mostly seem to have to do with not doing I/O
in userland, so that the programmability of anything is never exposed
to you unless you are writing a driver. Is that the point? With a
mainframe channel, a user *could* program the I/O devices, at least to
Sorry if I seem obtuse.
And there isn't anything the wright brothers could do with their plane
that you couldn't do with a cessna.
From: Mayan Moudgill on 25 Dec 2009 00:29
Bernd Paysan wrote:
> Sending chunks of code around which are automatically executed by the
> receiver is called "active messages".
I'm not so sure. The original Active Messages stuff from Thorsten von
Eicken et.al. was more like passing a pointer to a user space interrupt
handler along with an inter-processsor message, so that the message
could be handled with zero-copies/low-latency (OK, it wasn't always
quite that - but its close in flavor). The interrupt handler code was
already resident on the processor.
I've never heard of pushing code for execution on another processor
being called "active messages" - citations? references?