Re: Massbus - was: Re: VAX 11/750

[Lars Brinkhoff via cctalk]

Rich Alderson wrote:
> As for operating system support, the only DEC operating system which
> could put tapes and disks on the same Massbus was TOPS-20.  Tops-10
> explicitly tells you in the SYSGEN process that disks and tapes must
> reside on different channels; I believe that ITS follows that same
> principle.

KS10 ITS has MIT hacked microcode for IO instuctions hardwired to use
UBA 1 for disk and UBA 3 for tape.

KA10 and KL10 ITS have TM10 I/O bus tape controllers, optionally using a
DF10 channel.

Re: Funky electronics chain Fry?s is no more (Seattle Times)

[Stan Sieler via cctalk]

Gavin Scott wrote:
   > We all had a love/hate relationship with Fry's, but they were an
   > institution and will be missed.

Sometime after his story, Gavin moved to the Bay Area to work for my
company.
One day, I started to buy something at Fry's and they asked for my phone
number.
So, I gave the the office number.

The salesman entered it, and said "thank you, Mr. Scott".

I was still "Gavin Scott" to them 15 years later :)

Oh, the "seal of quality".  Not only did it scream "do not buy this item",
but it was a very useful thing ... although not for reasons Fry's
expected.  Many times, I'd be looking at some newer tech item (e.g., a
4-bay RAID enclosure), and see that over half of them had the "seal of
quality".  I quickly developed a rule: two more seals meant: stay away from
this product!

Stan

Re: Massbus - was: Re: VAX 11/750

[Rich Alderson via cctalk]

> Date: Thu, 25 Feb 2021 12:37:25 -0800
> From: Josh Dersch via cctalk 

> On Thu, Feb 25, 2021 at 12:27 PM Al Kossow via cctalk 
> wrote:

>> On 2/25/21 10:43 AM, Chris Zach via cctalk wrote:

>>> Oh this is fun stuff. Is there a specification write-up anywhere on the
>>> MASSBUS overall?

>> there is some documentation on bitsavers

>> the register descriptions were intentionally obfuscated to prevent cloning
>> that was figured out to make SIMH work

> Interesting... Is this obfuscation documented anywhere (beyond looking at
> SIMH code?)  I was working on an RH11/RPxx emulation for the Unibone that
> was partially working (and that I should really get back to...)

Hey, Josh!  You could ask our friends Keith Perez (Massbus Disk Emulator v1)
and Bruce Sherry (MDE v2) about it, or even ask me.

The primary obfuscation was a lie in the PDP-11 documentation which swapped the
names of two signals; this drove Keith nuts until I found the PDP-10 version,
which disagreed with the PDP-11 but agreed with what he saw on th elogic
analyzer.  I used to remember which two signals were involved; I'd probably be
able to recall if I could be arsed to go look at the manuals for a moment.

For those who don't know, we decided back in the early days of building Living
Computers: Museum + Labs that spinning rust with 40 year old bearings was going
to be problematical.  Add to that the fact that new media was no longer being
produced, and we had to do something.  My brilliant friend Keith sat down with
a logic analyzer and an RP06 attached to a KL-10, and proceeded to spend the
next two years (when not called on for other projects) creating a disk
emulator.  He used a Rabbit processor for the controller, and about half a
dozen PIC processors for scut work; we could provide up to 4 RP06 or RP07
drives at a time to the KL-10s with his prototype.

Later, Bruce came on board as the museum was ramping up, and redid the design
in a Xilinx chip with VHDL.  His was fast enough to support up to 8 RP06 or
RP07 drives (the max on a single channel); he also did a variant which could
emulate up to 8 Massbus attached tape drives, of the TU78 type.

As for operating system support, the only DEC operating system which could put
tapes and disks on the same Massbus was TOPS-20.  Tops-10 explicitly tells you
in the SYSGEN process that disks and tapes must reside on different channels; I
believe that ITS follows that same principle.  WAITS, although originally a
highly divergent offshoot of Tops-10, took the Massbus code from TOPS-20 v5
when it was ported to a KL-10 at SAIL, so could in theory have disk and tape on
the same channel.

At LCM+L, because the emulators acted as both controllers and peripherals, we
had to devote separate channels to disk and tape, even under TOPS-20, but it
was the hardware, not the OS, which required that.  We also had to use two MDEs
on the KL-10 boxes; since dual channel disks were not possible, the front end
11/40 needed its own MDE.

We eventually put Bruce's MDEs on the DECSYSTEM-20 (running Tops-10) and the
other KL-10 (running WAITS), the PDP-11/70 running Unix v7, the KI-10 based
DECsystem-10 running Tops-10 v6.03A, and the MIT-AI KS-10 which was purchased
from CZ way back in the early days.  (I rebuilt the RM03 power supplies and
replaced the HEPA filters on them while Keith was working on the first MDE.)
We also sent one to Michael Thompson to repay him for lending us some hardware
back in the early days.

Rich

P.S. We're about 10 days from the 1st anniversary of the closing of LCM+L to
 the public.  Lift a pint in memory of the most fun we ever had standing up.

Re: ISO IBM flex cables made by Chabin

[Al Kossow via cctalk]

On 2/22/21 8:14 PM, Jon Elson wrote:

I have some Chabin TLC cables that have been cut from the paddle boards.  I also have 4 of the SLT-style connectors sawed off of the some 
paddle boards.


I managed to get some complete cables from Bob Rosenbloom so I think I'm set.
It sure would be nice if they wouldn't have used connectors on .125 x .250" 
centers

Original Intel 8085 training briefcase with tapes

[Randy Dawson via cctalk]

Just on a chance, would anybody have the paper workbook that goes with this kit?
It is a 8085 SDK board in a briefcase, power supply and tape player that was 
probably part of a class they presented.

Mine works fine, including the Sony Walkman in the case, I am listening to the 
10 or more training tapes.

The whole kit is pristine, but no paper - the workbook from the kit.

Anybody help me on this, or want it?

I revisit things now and then, and this is one of them.  It may need a new home.

Randy

Re: Pinging Jay West

[Jon Elson via cctalk]

On 02/25/2021 05:04 PM, jim stephens via cctalk wrote:


Sent out a request via multiple channels to you WRT a 
local STL system.  can you give me a call or ping back.


sent to your emails, discord and other channels.
thanks
Jim


Anything I can do for you?

Jon

Re: Massbus - was: Re: VAX 11/750

[Rob Doyle via cctalk]

On 2/25/2021 1:37 PM, Josh Dersch via cctalk wrote:

On Thu, Feb 25, 2021 at 12:27 PM Al Kossow via cctalk 
wrote:


On 2/25/21 10:43 AM, Chris Zach via cctalk wrote:

Oh this is fun stuff. Is there a specification write-up anywhere on the

MASSBUS overall?

there is some documentation on bitsavers

the register descriptions were intentionally obfuscated to prevent cloning
that was figured out to make SIMH work



Interesting... Is this obfuscation documented anywhere (beyond looking at
SIMH code?)  I was working on an RH11/RPxx emulation for the Unibone that
was partially working (and that I should really get back to...)

- Josh


I did a lot of reverse engineering of the RP06 and RM05 schematics.

The implementation in my KS10 FPGA passes all the DSRPA and DSRMB 
diagnostics that matter.  I didn't simulate all of the sector header 
hardware or ECC hardware since the disk already does that.


The register descriptions are at:

https://github.com/KS10FPGA/KS10FPGA/wiki/RPxx-Disk-Simulator
https://github.com/KS10FPGA/KS10FPGA/wiki/RH11-Massbus-Disk-Controller
https://github.com/KS10FPGA/KS10FPGA/issues/8

Rob Doyle.

Pinging Jay West

[jim stephens via cctalk]

Sent out a request via multiple channels to you WRT a local STL system.  
can you give me a call or ping back.


sent to your emails, discord and other channels.
thanks
Jim

Re: Massbus - was: Re: VAX 11/750

[Paul Koning via cctalk]

> On Feb 25, 2021, at 4:15 PM, Al Kossow via cctalk  
> wrote:
> 
> On 2/25/21 12:37 PM, Josh Dersch wrote:
> 
>> Interesting... Is this obfuscation documented anywhere (beyond looking at 
>> SIMH code?)
> Not that I know of. Thinking about it some more I think that it was the 
> massbus device addresses
> behind the controllers that weren't documented

That rings a bell, for the PDP-11 case.  I think there is a mapping from 
RH11/RH70 CSR offsets to Massbus control bus register addresses; it isn't the 
natural 1:1 mapping of the low order Unibus address bits being used directly as 
Massbus register addresses.

From the software point of view that won't matter, but if you're trying to 
build a Massbus device you'd have to know it.  I'm pretty sure I've seen that 
mapping somewhere (in the past 10 years), at least in part, but I no longer 
remember where.

paul

Re: Massbus - was: Re: VAX 11/750

[Al Kossow via cctalk]

On 2/25/21 12:37 PM, Josh Dersch wrote:


Interesting... Is this obfuscation documented anywhere (beyond looking at SIMH 
code?)

Not that I know of. Thinking about it some more I think that it was the massbus 
device addresses
behind the controllers that weren't documented

Re: archive of DEC Notes

[Gary Grebus via cctalk]

On 2/24/21 3:27 PM, Paul Koning wrote:
> 
> 
>> On Feb 24, 2021, at 9:08 AM, Antonio Carlini via cctalk 
>>  wrote:
>>
>> On 24/02/2021 03:26, Eric Smith via cctalk wrote:
>>> Does anyone have contact information for the proprietor of this site:
>>> http://www.activityclub.org/decnotes/
>>> The site has an index of messages archived from DEC's internal "Notes"
>>> (kind of their equivalent of UseNet).
>>>
>>> It appears from the "Download this site" page that at one time it was
>>> possible to download an archive of the actual content, but the hosting used
>>> for that only provides one week of free hosting, which has expired.
>>>
>>> I don't need the entire archive (though I'd like to get it), but I'd
>>> especially like to get messages from milkwy::23class_semiconductor and
>>> ricks::decschips.
>>
>> Well if they ever show up, I'd be interested :-).
>>
>>
>> That archive was largely incomplete: it had the message titles but very few 
>> of the actual messages. There were some rather harsh negative comments on an 
>> FB group when someone pointed to it. Obviously some people thought that when 
>> they were writing their original comments that they would be kept private to 
>> the 100,000+ Digital employees :-)
> 
> The more significant issue may be that DEC, and its successor companies, 
> might have objections to the public posting of company confidential material.
> 
> Too bad only a few things were archived.  I looked for myself and found 
> exactly one notesfile ("fddi") with saved content, which made for some fun 
> reading.  But other notesfiles that would actually be more interesting at 
> this stage, like ones about RSTS, aren't archived.
> 
> I wonder if anyone has the full archive dump.  If so I'd love to have that.
> 
>   paul
> 
> 

I found a few of my postings in there from AlphaServer and Digital UNIX
days.  It is fun being reminded of some of the folks I worked with all
those years ago.  My other reaction was "I'm sure glad nobody is asking
me to remember some of that trivia now".

Gary

Re: Massbus - was: Re: VAX 11/750

[Josh Dersch via cctalk]

On Thu, Feb 25, 2021 at 12:27 PM Al Kossow via cctalk 
wrote:

> On 2/25/21 10:43 AM, Chris Zach via cctalk wrote:
> > Oh this is fun stuff. Is there a specification write-up anywhere on the
> MASSBUS overall?
>
> there is some documentation on bitsavers
>
> the register descriptions were intentionally obfuscated to prevent cloning
> that was figured out to make SIMH work
>

Interesting... Is this obfuscation documented anywhere (beyond looking at
SIMH code?)  I was working on an RH11/RPxx emulation for the Unibone that
was partially working (and that I should really get back to...)

- Josh



>
> the CDC drive interface was also slightly modified for the same purpose
>

Re: Massbus - was: Re: VAX 11/750

[Al Kossow via cctalk]

On 2/25/21 10:43 AM, Chris Zach via cctalk wrote:

Oh this is fun stuff. Is there a specification write-up anywhere on the MASSBUS 
overall?


there is some documentation on bitsavers

the register descriptions were intentionally obfuscated to prevent cloning
that was figured out to make SIMH work

the CDC drive interface was also slightly modified for the same purpose

Re: Massbus - was: Re: VAX 11/750

[Chris Zach via cctalk]

In answer to my own question: No it does not based on a bit of review. 
Looks like unique cards to the 11/70.


C


On 2/25/2021 1:43 PM, Chris Zach via cctalk wrote:
Oh this is fun stuff. Is there a specification write-up anywhere on the 
MASSBUS overall?


For example I wonder if the RH70 could do a transfer >128kb at a time. 
Another is around the RH11: There were two models, the traditional RH11 
(which could only do so many words on a DMA transfer) and the RH11-C 
which could do more words per transaction by basically running the 
Unibus in "Hog mode". That allowed the 2020 to run RM03's at a full 3600 
RPM (and I assume can allow the 2020 to run things like RM80's).


Another item I always wondered about was the RH11's support of two 
unibuses. I think the idea was to do the data transfers on the second 
bus right to an 11/45's FASTBUS memory without worrying about DMA 
timeouts while running the control and status registers on the normal 
UNIBUS (which wouldn't block other devices). I wonder, does the MBA on 
an 11/70 use similar cards to an RH11?


C


On 2/25/2021 1:30 PM, Noel Chiappa via cctalk wrote:

 > From: Paul Koning

 > There's a good reason why the big disks on many DEC machines 
were Massbus
 > devices until MSCP arrived.  It's quite clear on Unibus 
PDP-11s, which
 > needed Massbus both for speed and for a cleaner answer to 
more-than-18

 > bit addressing.

I follow the first sentence, but I'm confused by the second, 
especially "a

cleaner answer to more-than-18 bit addressing". The UNIBUS MASSBUS
controller/adapter, the RH11, only has 18-bit addressing on the main 
memory
side. It does have more than 18-bit addressing on the device side, but 
so does
the RP11 (sort of). Are you thinking of the RH70? That does have 
access to
more than 2^18 bytes of main memory, but that's because it connects to 
the
-11/70 memory bus (as well as the UNIBUS, which is only used for 
control, not

data).

Similar questions about the speed point; passing data through an RH11 
doesn't
increase the speed of the UNIBUS? Yes, the RH70 is faster, but that's 
because

of its connection to the -11/70 memory bus.

    Noel

Re: Massbus - was: Re: VAX 11/750

[Chris Zach via cctalk]

That is at least one RH11-AB in there, minus the knucklebusters of course.

On 2/25/2021 1:49 PM, Bill Degnan wrote:



On Thu, Feb 25, 2021 at 1:43 PM Chris Zach via cctalk 
mailto:cctalk@classiccmp.org>> wrote:


Oh this is fun stuff. Is there a specification write-up anywhere on the
MASSBUS overall?

For example I wonder if the RH70 could do a transfer >128kb at a time.
Another is around the RH11: There were two models, the traditional RH11
(which could only do so many words on a DMA transfer) and the RH11-C
which could do more words per transaction by basically running the
Unibus in "Hog mode". That allowed the 2020 to run RM03's at a full
3600
RPM (and I assume can allow the 2020 to run things like RM80's).

Another item I always wondered about was the RH11's support of two
unibuses. I think the idea was to do the data transfers on the second
bus right to an 11/45's FASTBUS memory without worrying about DMA
timeouts while running the control and status registers on the normal
UNIBUS (which wouldn't block other devices). I wonder, does the MBA on
an 11/70 use similar cards to an RH11?

C



I have a UNIBUS array of backplanes from an Industrial 11/40 that has a 
lot of MASBUS controllers in it.  Or, I think that's what these are.  I 
removed the backplane chassis from the rack and replaced it with two 
RL02 drives.
https://www.vintagecomputer.net/digital/PDP11-40_industrial11/DEC_industrial11_exp_chassis.jpg 

Re: Massbus - was: Re: VAX 11/750

[Michael Thompson via cctalk]

The PDP-10 KL10 at the RCS/RI was used to control a real-time flight
simulator at Sikorski. It had one of the RH20 Massbus controllers connected
to a DTR01 cabinet holding a DR01 chassis. The DR01 was, I think, connected
to a DR11 chassis that had A/D and D/A converters boards inside. You could
use the same DTR01 subsystem to connect two PDP-10s together with Massbus,
or connect a PDP-10 to a PDP-11 with Massbus.

-- 
Michael Thompson

Re: Massbus - was: Re: VAX 11/750

[Paul Koning via cctalk]

> On Feb 25, 2021, at 1:43 PM, Chris Zach via cctalk  
> wrote:
> 
> Oh this is fun stuff. Is there a specification write-up anywhere on the 
> MASSBUS overall?
> 
> For example I wonder if the RH70 could do a transfer >128kb at a time.  ...

I don't know the answer to most of your questions, but this one is easy: "no".  
The reason is that the transfer is controlled by a 16 bit word count register.

paul

Re: Massbus - was: Re: VAX 11/750

[Bill Degnan via cctalk]

On Thu, Feb 25, 2021 at 1:43 PM Chris Zach via cctalk 
wrote:

> Oh this is fun stuff. Is there a specification write-up anywhere on the
> MASSBUS overall?
>
> For example I wonder if the RH70 could do a transfer >128kb at a time.
> Another is around the RH11: There were two models, the traditional RH11
> (which could only do so many words on a DMA transfer) and the RH11-C
> which could do more words per transaction by basically running the
> Unibus in "Hog mode". That allowed the 2020 to run RM03's at a full 3600
> RPM (and I assume can allow the 2020 to run things like RM80's).
>
> Another item I always wondered about was the RH11's support of two
> unibuses. I think the idea was to do the data transfers on the second
> bus right to an 11/45's FASTBUS memory without worrying about DMA
> timeouts while running the control and status registers on the normal
> UNIBUS (which wouldn't block other devices). I wonder, does the MBA on
> an 11/70 use similar cards to an RH11?
>
> C
>
>
>
I have a UNIBUS array of backplanes from an Industrial 11/40 that has a lot
of MASBUS controllers in it.  Or, I think that's what these are.  I removed
the backplane chassis from the rack and replaced it with two RL02 drives.
https://www.vintagecomputer.net/digital/PDP11-40_industrial11/DEC_industrial11_exp_chassis.jpg

Re: Massbus - was: Re: VAX 11/750

[Chris Zach via cctalk]

Oh this is fun stuff. Is there a specification write-up anywhere on the 
MASSBUS overall?


For example I wonder if the RH70 could do a transfer >128kb at a time. 
Another is around the RH11: There were two models, the traditional RH11 
(which could only do so many words on a DMA transfer) and the RH11-C 
which could do more words per transaction by basically running the 
Unibus in "Hog mode". That allowed the 2020 to run RM03's at a full 3600 
RPM (and I assume can allow the 2020 to run things like RM80's).


Another item I always wondered about was the RH11's support of two 
unibuses. I think the idea was to do the data transfers on the second 
bus right to an 11/45's FASTBUS memory without worrying about DMA 
timeouts while running the control and status registers on the normal 
UNIBUS (which wouldn't block other devices). I wonder, does the MBA on 
an 11/70 use similar cards to an RH11?


C


On 2/25/2021 1:30 PM, Noel Chiappa via cctalk wrote:

 > From: Paul Koning

 > There's a good reason why the big disks on many DEC machines were Massbus
 > devices until MSCP arrived.  It's quite clear on Unibus PDP-11s, which
 > needed Massbus both for speed and for a cleaner answer to more-than-18
 > bit addressing.

I follow the first sentence, but I'm confused by the second, especially "a
cleaner answer to more-than-18 bit addressing". The UNIBUS MASSBUS
controller/adapter, the RH11, only has 18-bit addressing on the main memory
side. It does have more than 18-bit addressing on the device side, but so does
the RP11 (sort of). Are you thinking of the RH70? That does have access to
more than 2^18 bytes of main memory, but that's because it connects to the
-11/70 memory bus (as well as the UNIBUS, which is only used for control, not
data).

Similar questions about the speed point; passing data through an RH11 doesn't
increase the speed of the UNIBUS? Yes, the RH70 is faster, but that's because
of its connection to the -11/70 memory bus.

Noel

Re: Massbus - was: Re: VAX 11/750

[Paul Koning via cctalk]

> On Feb 25, 2021, at 1:30 PM, Noel Chiappa via cctalk  
> wrote:
> 
>> From: Paul Koning
> 
>> There's a good reason why the big disks on many DEC machines were Massbus
>> devices until MSCP arrived.  It's quite clear on Unibus PDP-11s, which
>> needed Massbus both for speed and for a cleaner answer to more-than-18
>> bit addressing.
> 
> I follow the first sentence, but I'm confused by the second, especially "a
> cleaner answer to more-than-18 bit addressing". The UNIBUS MASSBUS
> controller/adapter, the RH11, only has 18-bit addressing on the main memory
> side. It does have more than 18-bit addressing on the device side, but so does
> the RP11 (sort of). Are you thinking of the RH70? That does have access to
> more than 2^18 bytes of main memory, but that's because it connects to the
> -11/70 memory bus (as well as the UNIBUS, which is only used for control, not
> data).
> 
> Similar questions about the speed point; passing data through an RH11 doesn't
> increase the speed of the UNIBUS? Yes, the RH70 is faster, but that's because
> of its connection to the -11/70 memory bus.

Yes, I meant the RH70.  The point is that, without Massbus, the only I/O bus 
you have in PDP-11 systems is the Unibus (pre-Qbus that is) with all its 
limitations.  The Massbus enabled the creation of the RH70 with its direct 
memory connection both for more bandwidth and more address bits.  So, for 
example, you can use an RM03 rather than being limited to an RM02 because of 
the bus performance.  And your disks and tapes don't have to fight all the 
other I/O devices for unibus map slots.

paul

Re: Massbus - was: Re: VAX 11/750

[Noel Chiappa via cctalk]

> From: Paul Koning

> There's a good reason why the big disks on many DEC machines were Massbus
> devices until MSCP arrived.  It's quite clear on Unibus PDP-11s, which
> needed Massbus both for speed and for a cleaner answer to more-than-18
> bit addressing.

I follow the first sentence, but I'm confused by the second, especially "a
cleaner answer to more-than-18 bit addressing". The UNIBUS MASSBUS
controller/adapter, the RH11, only has 18-bit addressing on the main memory
side. It does have more than 18-bit addressing on the device side, but so does
the RP11 (sort of). Are you thinking of the RH70? That does have access to
more than 2^18 bytes of main memory, but that's because it connects to the
-11/70 memory bus (as well as the UNIBUS, which is only used for control, not
data).

Similar questions about the speed point; passing data through an RH11 doesn't
increase the speed of the UNIBUS? Yes, the RH70 is faster, but that's because
of its connection to the -11/70 memory bus.

   Noel

Re: Massbus - was: Re: VAX 11/750

[Paul Koning via cctalk]

> On Feb 25, 2021, at 2:40 AM, Eric Smith via cctalk  
> wrote:
> 
> On Wed, Feb 24, 2021 at 7:06 AM Chris Zach via cctalk 
> wrote:
> 
>> Yes, the TM02 and TM03 formatters allowed MASSBUS to connect to Pertec
>> drives, but I don't think you could run a tape drive and a disk drive on
>> the same MASSBUS channel anyway. Wonder why, technically the MASSBUS
>> cable is just an extension of the Unibus, so it shouldn't matter much
>> what combination of cables you used. Maybe they just wrote different
>> drivers or something.
>> 
> 
> There's nothing in the hardware that prevents it from being done, but DEC
> OSes don't support it, and it's generally not a good idea. Tape activity
> would block disk activity, because it doesn't have anything like modern
> "tagged command queuing".

I know most DEC OS don't support this but I'm pretty sure that at least one of 
them does.  Not sure which.

A given Massbus can only do one transfer at a time, so yes, a tape transfer in 
progress would mean you can't start a disk transfer (though you can start the 
seek).  For that matter, if one disk is transfering another can't start either. 
 So if you want max throughput, you want to spread the disks over several 
massbus adapters, and keep the tape separate.

But if you need lots of disk space, you may have to put tape and disk on the 
same Massbus since any given system has a limit on Massbus adapters (4 for the 
PDP-11/70?) and unit numbers are 3 bits.  For PDP-11 systems, not likely to be 
an issue.  For mainframe (PDP-10), it might be.  I know mainframe systems at 
times had dozens of disk drives.  One I used (CDC not DEC) had 22 RP04 class 
drives.

paul

Re: FW: List your old computer

[erik--- via cctalk]

Hm, just adding that my venerable SUN SPARC UII runs WEB server, ssh, web
proxy, sub-version, and is my "cloud" via rsync and of course serves email. 
Over the last 7 years it got rebooted only twice, because the provider needed
to relocate it in the server farm and during one of these reboots we replaced
a failed disc in the array. I am pretty sure it would have ran without reboot
the full 7 years with one good disc left...

Re: FW: List your old computer

[Chuck Guzis via cctalk]

On 2/25/21 2:05 AM, Peter Coghlan wrote:
> Chuck Guzis wrote:

> I don't think so.  My Raspberry Pi running Linux becomes choked by memory 
> leaks
> when I leave it running more than a few months.  No amount of killing 
> processes
> or other fiddling with the operating system tools available allows it to
> recover and the only alternative I can find is to reboot it.  My VAX/ALPHA
> machines/clusters just keep on trucking until the next power failure.

I suppose it depends on what's being done.   I've got an OrangePi PC
running headless that's nothing more than an email relay and an Internet
radio server.   Until we had power cuts because of the summer wildfires,
it ran more than a year.   It's been running since power returned.
I've got a OPi Zero hooked to a stereo system (headless again) running
nothing more than mplayer.

Various modems/routers and other appliances have been running BusyBox as
an embedded OS.  They pretty much escape notice.

--Chuck