[Info-vax] VMS on Raspberry Pi 5
Richard Kettlewell
invalid at invalid.invalid
Fri Nov 17 04:36:02 EST 2023
Ahem A Rivet's Shot <steveo at eircom.net> writes:
> Richard Kettlewell <invalid at invalid.invalid> wrote:
>> Maybe. It was certainly convenient for certain components to be
>> portable, like X11 as you mention, but I think it’s a stretch to infer
>> that there was a widely shared goal that the lower-level system tools
>> should be portable too. Things like, say, package management and device
>> driver handling have been very different across platforms for a very
>> long time (the former in fact even within Linux).
>
> Package management is a relatively new feature of unix (it's about
> half the age of unix) - but NetBSD's pkgsrc is designed to be portable
> and can be used on pretty much any unix including Linux. The FreeBSD
> ports system (one of the first) is written in make and the system (but
> not the ports themselves) would be easy enough to get going on any
> other unix with a BSD compatible make available.
System V’s packages were, what, 1990 or so? So nearer a third of its
current age I would say. I’m not even sure they were the first.
Be that as it may the fact that some of them are in principle portable
doesn’t change the fact that nobody has ever much tried to use any
particular one outside its home platform. So I think they form a
reasonable counterexample to the idea of a common goal of portability of
system-level components.
> Device drivers are of course largely kernel dependent and generally
> not portable - notable exception for DRI/DRM which are surprisingly
> portable. That being said it is quite common to port device drivers
> between the BSDs despite the divergence in the kernels over the years,
> none of them would take Linux device drivers because GPL.
Well, yes, there’s practical reasons why it happened like that, but they
aren’t insurmountable: we have common extension APIs in many other
contexts, but apparently nobody was ever motivated to do it for drivers,
despite the obvious advantages.
>> In the more recent case of systemd, a lot of the functionality depends
>> on Linux-specific interfaces. Porting it would presumably be a
>
> Apart from systemd every other init system is shell script based and
> reasonably easy to port, systemd is a huge departure from convention.
SMF and launchd are both counterexamples AFAIK. A lot of the original
Unix design decisions were fairly novel at the time too but many of them
have proved to be good ones.
>> non-starter until this existed in some form in other operating systems,
>> and nobody maintaining other operating systems seems to be interested in
>> doing so.
>
> Nobody maintaining other operating systems wants them to become Linux
> based which is essentially what would be needed.
The lack of portability of systemd can hardly be an objection to it if
nobody in the platforms that it can’t be ported to is interested in
adopting it anyway.
>>> Linux as an operating system exists because all the tools
>>> provided by the GNU project and MIT X-Windows and ... were designed to
>>> be portable across every variant of unix extant at the time (a lot more
>>> than today).
>>
>> That doesn’t make it a goal _of Linux_, even if it was a goal of the GNU
>> and X11 projects.
>
> You missed the "and ...", Linux based OSs are the odd ones out in
> this regard which is sad given that Linux as an OS owes its entire
> existence to the fact that everyone else in the unix world cares about
> portability. Without the GNU project's portable utilities there would be no
> Linux distros, there wouldn't even be a compiler to build the kernel! If
> MIT had chosen to make X11 tightly bound to a single kernel there would be
> no Linux graphics.
There’s still nothing there that demonstrates Linux ever had a goal of
portable system-level tools. I get that you think it should do, but
wanting isn’t getting.
--
https://www.greenend.org.uk/rjk/
More information about the Info-vax
mailing list