I used to be a hardcore Slackware head. I ran everything from the earliest releases on a
0.99 kernel back in the 90?s and used it for all of my Linux work exclusively until around
2015.
In the past few years I was forced to move across to something different ? PHP was the
thing that forced me to move across.
Slackware has the ?you run the entire distribution and the latest version? approach which
is fine, but as I was using Linux more and more for application server work, I starting
hitting problems with PHP. Slackware was moving up to newer releases of PHP all the time,
but I had some application code that only worked under earlier releases of PHP.
It?s not possible to run multiple releases of PHP side by side under Slackware without
hard custom installs, but Linux distributions such as Debian and Ubuntu handle it with
ease.
Back in the day I really enjoyed doing everything by hand, building everything from source
and custom configurations for clients, but now I?m using Linux more and more for customer
application and appliance work, and I don?t have the time to mess around and need to get
on with the job as efficiently as possible.
Slackware has a very basic packaging system, and no dependency management. You are also
reliant on other people writing package install scripts (Slackbuilds) or you do it
yourself. We?ve all encountered compatibility issues, or library conflicts, or other
issues that require remediation. With a good package management system (such as apt) you
can remove the incorrect libraries and replace them with new ones in minutes, but under
Slackware I would be manually cleaning things up and compiling new packages again. Fun as
a hobbyist, but a total time killer when you are performing tasks commercially.
I?ve had this occur with deployment work I have done ? for example - run up PHP 7.3 and
finish the job, to find out that you really need to be running PHP 7.2 for some required
dependency and I can fix the problem in minutes with a good package manager.
Fundamentally Slackware is not designed to be ?modular? whereas Debian/Ubuntu and others
have thousands of premade packages to drop in place. Not to mention many commercial
vendors who won?t release code and binaries only and the bulk of them will support Debian,
Ubuntu and Redhat as their primary or only release platform.
Sometimes this is a really good thing. Take projects like Unraid for example ? this is all
based on Slackware. When you are producing and supporting a storage appliance you want a
reliable and solid OS underneath.
--
Anyhow ? back to our current topic. All of my original simh and DECnet was all done under
Slackware and I still have heaps of notes on how I set it all up.
Thord ? if this is the platform you are running, let me know ? and also if you are running
this as bare metal or under a hypervisor (VMware ESXi, HyperV, Virtualbox etc). I can
build up a Slackware VM and config it up so I can provide you with very specific notes.
PDP11 and VAX use the same networking in respect to the SIMH side of things. I can?t
assist with anything RSTS/E related, but I would assume that someone on the list would be
able to assist us if something on your actual simulated machine required changing that you
were aware of how to do.
Let me know your configuration and whether I can assist.
Cheers, Wiz!!
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of
Supratim Sanyal
Sent: Saturday, 22 August 2020 10:11 PM
To: hecnet at update.uu.se
Subject: Re: [HECnet] Configuring py-decnet.
I believe he is running slackware 14.2 with 5.2.2 kernel and a pretty recent
Simh 6fdc4474
Lots of people seem to prefer Slackware as the host ... someday need to try it
---
Supratim Sanyal, W1XMT
39.19151 N, 77.23432 W
QCOCAL::SANYAL via HECnet<http://www.update.uu.se/~bqt/hecnet.html>
On Aug 22, 2020, at 7:38 AM, David Moylan <djm at wiz.net.au<mailto:djm at
wiz.net.au>> wrote:
PyDECnet certainly does GRE. That's why we all love Paul's work so much. It
contains support for GRE, Multinet and your bridge code all in the one product.
I was able to move from my old Cisco router across to PyDECnet and maintain all of my
existing GRE tunnels with no reconfiguration.
From what I interpret, Thord is running an emulated
RSTS/E system on simh and wants to run PyDECnet on the same host to establish a connection
upstream.
Thord - I have a similar setup, but I'm running VMS. Here's how I have it setup:
- my host running is Ubuntu 18.04.2
- physical Ethernet (it's called "ens160" because I run VMware)
- tap interfaces for each of my VMS simh machines
- a tap interface for PyDECnet
- I bring all of my tap interfaces and my physical ethernet together into a bridge
interface
- the bridge interface has my IP address bound to it.
PyDECnet is setup with the first circuit connected to the tap adapter I reserved for
PyDECnet above.
I then have circuit entries for each of the connections to the other area routers and end
nodes I am connected to on HECnet.
I assume that you should be able to achieve the same with RSTS/E on simh.
Let me know if you want more specific details (and let me know what your OS version etc
is). I can provide more granular configuration information on my setup which you should be
able to use as a template for your own setup.
Cheers, Wiz!!
-----Original Message-----
From: owner-hecnet at Update.UU.SE<mailto:owner-hecnet at Update.UU.SE>
[mailto:owner-
hecnet at Update.UU.SE<mailto:hecnet at Update.UU.SE>] On Behalf Of Johnny
Billquist
Sent: Saturday, 22 August 2020 9:27 PM
To: hecnet at Update.UU.SE<mailto:hecnet at Update.UU.SE>
Subject: Re: [HECnet] Configuring py-decnet.
Indeed I did. I must admit that the picture is unclear. If we're talking
GRE using pydecnet (does it do GRE?), then why the ethernet jump between
pydecnet and GRE? There do need to some something between the
ethernet
and GRE tunnel. My assumption was probably premature.
Johnny
On 2020-08-22 13:23, David Moylan wrote:
I think you assumed he has a Cisco router :-)