Re: Dec DMX11--What was it?
Thanks! I found the PCL11 in the 1980 Terminals and Communications handbook, but the biggest thing they had was the COMM/IO/DUP micro-controller that ran up to 6 DZ11's for 48 terminals. And that was in the Customer Specific Solutions section. No mention of what the DMX11 was, but it must have been a beast: One thing I do see in this report is that DEC went nuts because the customer was holding them to an interesting set of requirements that changed mid-project. From what I can see, it was some sort of a "block mode" device that could support 64 terminals at a shot. Then the client/DEC also wanted it to drive VT52's in character mode as well because the "Terminal Concentrator Device" (no idea what that was) was not going to be supported by RSX11/D going forward. It was still supported in RSX11/M now I'm wondering what THAT device was as well. Anyway trying to stuff character mode and block mode in the same controller doubled the microcode requirements. Worse, they couldn't lay out the components on a nine board layout and the customer refused to allow more boards to make it fit. So it had "problems". So what was a TCD? Was that a pdt11/150 by chance? C On 10/25/2021 2:16 PM, Paul Koning wrote: On Oct 23, 2021, at 10:16 PM, Chris Zach via cctalk wrote: Anyone know about the Dec DMX11? It was apparently a 64 serial line Mux that plugged into pdp11 Unibus systems and had a fair amount of both intelligence and insanity on board. Reason is I'm looking into some old documentation about late 1970's Tote systems for Asian race tracks and the system they were building was beyond astronomical in terms of insanity. (As in an 8 way pdp11/70 system cluster, with 11/04's running these DMX11's to hundreds of terminals) The April 1983 Options & Modules List (see http://www.bitsavers.org/pdf/dec/modules/modulesAndOptions/) shows it on page 156. It is listed as a CSS product, 64 line mux controller (DMA both ways, so similar to the DH11) with separate 64-port line cards. Three flavors of line card: 20 mA loop, "EIA" (presumably that means RS-232) and "Differential" -- perhaps RS-422? Date is given as 08/1980, but that's the last update of the entry. Status is "6". The April 1983 document is missing its cover material which explains the codes, but the December 1975 edition (same Bitsavers directory) lists them. "6" means "Obsolete, but can still be custom-built". Given that it's a CSS device, documentation for it is likely to be hard to find, and software for it even harder. For example, while RSTS would be a natural OS to support this (given that it can handle 128 terminal lines) it doesn't and as far as I know never has. paul
Re: Dec DMX11--What was it?
> On Oct 23, 2021, at 10:16 PM, Chris Zach via cctalk > wrote: > > Anyone know about the Dec DMX11? It was apparently a 64 serial line Mux that > plugged into pdp11 Unibus systems and had a fair amount of both intelligence > and insanity on board. Reason is I'm looking into some old documentation > about late 1970's Tote systems for Asian race tracks and the system they were > building was beyond astronomical in terms of insanity. > > (As in an 8 way pdp11/70 system cluster, with 11/04's running these DMX11's > to hundreds of terminals) The April 1983 Options & Modules List (see http://www.bitsavers.org/pdf/dec/modules/modulesAndOptions/) shows it on page 156. It is listed as a CSS product, 64 line mux controller (DMA both ways, so similar to the DH11) with separate 64-port line cards. Three flavors of line card: 20 mA loop, "EIA" (presumably that means RS-232) and "Differential" -- perhaps RS-422? Date is given as 08/1980, but that's the last update of the entry. Status is "6". The April 1983 document is missing its cover material which explains the codes, but the December 1975 edition (same Bitsavers directory) lists them. "6" means "Obsolete, but can still be custom-built". Given that it's a CSS device, documentation for it is likely to be hard to find, and software for it even harder. For example, while RSTS would be a natural OS to support this (given that it can handle 128 terminal lines) it doesn't and as far as I know never has. paul
Re: Linux and the 'clssic' computing world
On Mon, 25 Oct 2021 at 11:39, Peter Corlett via cctalk
wrote:
>
> On Mon, Oct 25, 2021 at 10:18:51AM +0200, Sijmen J. Mulder via cctalk wrote:
> [...]
> > It's especially frustrating when, after having put in the work, projects
> > refuse even trivial patches for Solaris and derrivatives or sometimes even
> > BSDs because 'who uses that anyway'. (I include the patches in pkgsrc
> > instead.)
>
> Solaris is owned by Oracle, a bunch of litigious bastards who readily
> freeload off Linux and other Open Source projects but are rather reluctant
> to give back much beyond gateway drugs to their closed-source offerings. I
> note the existence of CDDL which appears deliberately designed to clash with
> the GPL. That sort of thing can leave a nasty taste in the mouth.
>
> The specific details differ, but this basically also applies to Microsoft
> and Windows.
I think "Solaris and derivatives" was a easier way than saying
SmartOS, Illumos and OpenIndiana as well as any poor souls running
Solaris (some of which may be running older versions on Sparc kit)
> Anyway, this hypothetical patch submitter has apparently put in minimal
> effort ("trivial patches") and now implicitly expects the project maintainer
> to integrate it immediately, and then do the thankless task of maintaining
> and testing it indefinitely on (multiple releases of) a closed-source
> platform which is actively hostile to their work. For free, presumably.
I'm... pretty sure SmartOS/Illumos are actively friendly to open
source work - last I checked Joyent provided pkgsrc config to build
around 20,000 packages and had a policy of trying to feed back changes
upstream https://pkgsrc.joyent.com/install-on-illumos/
> To a rough approximation, nobody uses Solaris. It's not a good use of any
> developer's time to support it unless they're being paid to do so.
You could easily s/Solaris/Solaris,BSD,non(x86,arm,riscv),etc/
Its obviously entirely up to the members of a project to decide on
what to spend their time, and specifically what they are interested in
supporting, though if there is an active policy to not want to support
certain platforms it would help to have a specific statement in the
README to avoid other people wasting their time and annoying project
members by sending in unwanted patches and then complaining that the
patches are being ignored.
If its a matter of the patches needing more work, then that's always a
perennial problem, for just about all platforms and projects. Maybe
submitters of patches orm some platforms need to do more work, so they
should be told that
tl;dr if there are hoops to jump through for some platform patches,
indicate the hoops. If the path is closed, make it clear up front..
David
Re: Linux and the 'clssic' computing world
On Mon, Oct 25, 2021 at 10:18:51AM +0200, Sijmen J. Mulder via cctalk wrote:
[...]
> It's especially frustrating when, after having put in the work, projects
> refuse even trivial patches for Solaris and derrivatives or sometimes even
> BSDs because 'who uses that anyway'. (I include the patches in pkgsrc
> instead.)
Solaris is owned by Oracle, a bunch of litigious bastards who readily
freeload off Linux and other Open Source projects but are rather reluctant
to give back much beyond gateway drugs to their closed-source offerings. I
note the existence of CDDL which appears deliberately designed to clash with
the GPL. That sort of thing can leave a nasty taste in the mouth.
The specific details differ, but this basically also applies to Microsoft
and Windows.
Anyway, this hypothetical patch submitter has apparently put in minimal
effort ("trivial patches") and now implicitly expects the project maintainer
to integrate it immediately, and then do the thankless task of maintaining
and testing it indefinitely on (multiple releases of) a closed-source
platform which is actively hostile to their work. For free, presumably.
To a rough approximation, nobody uses Solaris. It's not a good use of any
developer's time to support it unless they're being paid to do so.
Re: Linux and the 'clssic' computing world
Nemo Nusquam via cctalk : > I cannot agree. Many developers ensure that their software runs under > their particular distribution and then call it POSIX. Porting to UNIX > systems, such as Solaris or macOS, can be difficult and tedious. (Of > course, this is not a Linux issue.) It's especially frustrating when, after having put in the work, projects refuse even trivial patches for Solaris and derrivatives or sometimes even BSDs because 'who uses that anyway'. (I include the patches in pkgsrc instead.) Sijmen
