On 2022-01-29 20:46, Tony Nicholson wrote:
> On Sunday, January 30, 2022 at 3:06:23 AM UTC+11 Johnny wrote:
>
> On 2022-01-29 09:06, Tony Nicholson wrote:
> > [snip]
> Indeed. We browsers are becoming idiotically bloated, while removing
> useful functionality.
> Anotherone is that I'm now getting warnings when I want to look at pdf
> files that aren't over https. I bet I'm soon not going to be allowed to
> even access them...
>
>
> The other reason is security over "non-trusted" pathways. This is also
> why most recent Linux distributions don't install an ftp or telnet client by
> default. Protocols that can use unencrypted data (and pass authentication
> in clear text) are in the thoes of being deprecated.
Yes. But the thing is, not everything is actually a security risk/problem.
In fact, most things are not. And trying to imply it is, and insist that
everything have to be run over https becomes yet another case of
instilling a false sense of security into people.
If someone were to corrupt the content of those DEC manuals, the problem
is pretty much that I just don't have correct information. If someone
really want to go through the problem of creating that problem for me, I
would then have to realize the information is incorrect when trying to
use it, and then locate correct information from somewhere else. Wasting
some time for me, sure, but nothing else. And such broken/altered pdf
files can just as easily be provided through https, so nothing actually
improved by that layer. And if someone sees exactly what information I
access, I couldn't care less. It's already visible that I am accessing
the site, https or not, so it's only about what specific documents I'm
accessing. But of course, anyone on that site, or who breaks into it
will be able to find that piece of information out anyway. Meanwhile,
removing functions such as ftp (or http) will make my life that much harder.
Definitely the wrong tradeoffs here. When I actually am dealing with
sensitive information, the by all means, insist on https, but don't just
blindly insist on it everywhere.
(Sorry for ranting, and it isn't specifically against you, Tony.)
> > ; TS11 magtape (becomes tape drive MS0: under RSTS/E)
> > set ts enable
> > set ts0 locked
> > attach ts0 -r rstse_v10_1_install_sep10_1992.tap
>
> Interesting that you pick ts. Any special reason? I's usually go for
> TMSCP, which means TK50/TU81.
>
>
> A TMSCP device should work too (SIMH tq). I just picked it because
> this is what I used to use on a real PDP-11/70 :)
Ah. Yeah. I've only been using TU45, TU77 and TU81 on real 11/70s. TS
seemed a little unexpected, but of course perfectly legitimate.
> > Boot this tape (boot ts0) to install on the system disk. I
> usually use a
> > large drive like an RA92
> > on the RQDX3 controller (rq device) to allow plenty of "play" room.
>
> Technically that combination never existed. The RQDX3 is an MFM
> controller, while the RA drives are SDI. But since the controller
> speaks
> MSCP, it basically means disk types are meaningless anyway.
> Which is why I usually just create a very large disk. You can do
> that in
> simh by using RAUSER=nnnn. It will say it's an RA81 (if I remember
> right), but it will be with the size you specify.
> Not sure what the maximum size for disks are in RSTS/E. With RSX, it's
> 8G (if you attach something larger than 8G to RSX, it truncates it
> to 8G).
>
>
> I meant to type MSCP controller (SIMH rq device). I was watching the tennis
> while composing my message, and sometimes my fingers type things my brain
> might have been confused about! (Wasn't it a UDA50 on the UniBus?)
Yeah. On the Unibus you'd use the UDA50. And on Qbus it's the KDA50.
Or if you wanted SCSI, the DEC controller was the RQZX1.
> Could you setup some place with the documentation available ordered? I
> think bitsavers don't have all of it, and I know
Stacken.KTH.SE
> <
http://Stacken.KTH.SE> have
> some, but not sure how complete for V10. So it would be great if
> someone
> would give this some love.
>
>
> I no longer run an ftp server. If anyone wishes to make these files
> available
> (some - but not all are on Bitsavers/Elvira) by all means do so. The
> zip file
> includes manuals from earlier versions of RSTS/E that were not updated
> for V10.1.
Oh. I was thinking of a setup through http (or https if you want). As
the situation is, ftp isn't a very good choice.