On 11/15/2023 5:30 PM, Johnny Billquist wrote:
> On 2023-11-15 22:34, Ahem A Rivet's Shot wrote:
>> On Wed, 15 Nov 2023 21:57:45 +0100
>> Johnny Billquist <bqt@softjar.se> wrote:
>>
>>> But systemd always comes to my mind...
>>
>>     I try not to let it <shudder> - anyway that's a Linux thing not seen
>> on any other unix (it's one reason I tend to avoid Linux). Apparently
>> it's
>> not even remotely portable.
>
> Yeah. It's a monster. And tries to do all kind if stuff. Talk about
> breaking the Unix paradigm...
>
> Yes, I try to avoid Linux myself as well.

I use Linux. As a desktop just like I use Windows.
For real computing I use real OSes. :-)

bill

On 15/11/2023 22:58, Scott Dorsey wrote:
> In article <uj1tno$1lkjn$1@dont-email.me>,
> Pancho <Pancho.Jones@proton.me> wrote:
>> On 14/11/2023 23:58, Martin Gregorie wrote:
>>> On Tue, 14 Nov 2023 15:24:59 -0500, Arne Vajhøj wrote:
>>>
>>> X> $ purge foobar.txt
>>>>
>>> Yes, I remember those periodic purges.
>>>
>>> I did like the customisable editor too and, IIRD, the ability to attach
>>> customisations to file types. If there was an open source version of that
>>> editor I might even be using it still.
>>>
>>
>> If you mean EVE based on Vax/TPU it was ported to Unix, circa ~1995,
>> SunOS, or possibly Solaris. So it is possible there is a version
>> floating about.
>
> It wasn't so much ported as rewritten from the bottom up when the
> folks at Boston Business Computing released nu/TPU which was a
> TPU-compatible package. It works really well, too.
> --scott

Is nu/TPU still available anywhere. Sector 7 web site doesn't give any
details, except that another produced it and the company that I found a
link to elsewhere seemed to be no more

--
Chris

On Wed, 15 Nov 2023 18:51:53 -0500
bill <bill.gunshannon@gmail.com> wrote:

> I use Linux. As a desktop just like I use Windows.

I use FreeBSD and MacOS for desktops.

> For real computing I use real OSes. :-)

For real computing I use FreeBSD.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
Host: Beautiful Theory meet Inconvenient Fact
Obit: Beautiful Theory died today of factual inconsistency

On 11/15/23 9:43 AM, Ahem A Rivet's Shot wrote:
> On Wed, 15 Nov 2023 08:06:00 -0500
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>
>> On 11/15/2023 2:44 AM, Ahem A Rivet's Shot wrote:
>
>>> I don't know about McDonald's but these days a lot of really big
>>> systems run as a large (and variable) number of micro-services in
>>> containers under Kubernetes. Scalability is the watchword today.
>>> Sometimes they run on Z/OS machines (usually running Linux) otherwise
>>> they run on a mix of blade servers (CPU and RAM tightly packed) and SAN
>>> storage (lots of NVMe SSDs) connected with 40Gb or 100Gb ethernet.
>>> Infrastructure as a service they call it.
>>
>> Most run such workloads in AWS/Azure/GCP/OCI.
>
> Of course, these environments are built for that purpose and allow
> the systems developers to assume the Kubernetes infrastructure without
> having to maintain it. But it is possible to run such workloads in a
> private data centre - "TrueNAS Scale" is one fairly easy way.

Sorry, but McDonalds Corporate, BOA, US Mil, etc ... they
are NOT gonna work on Docker or Kubernetes on a bunch of
tablets. IBM didn't pay big for RHEL to run it on laptops,
but on its mainframes ......

Decentralized usually = SLOW ... and INSECURE ... despite
claims.

On Thu, 16 Nov 2023 00:47:55 -0500
"56d.1152" <56d.1152@ztq9.net> wrote:

> On 11/15/23 9:43 AM, Ahem A Rivet's Shot wrote:
> > On Wed, 15 Nov 2023 08:06:00 -0500
> > Of course, these environments are built for that purpose and
> > allow the systems developers to assume the Kubernetes infrastructure
> > without having to maintain it. But it is possible to run such workloads
> > in a private data centre - "TrueNAS Scale" is one fairly easy way.
>
> Sorry, but McDonalds Corporate, BOA, US Mil, etc ... they
> are NOT gonna work on Docker or Kubernetes on a bunch of
> tablets.

No most corporate use of Kubernetes is on data centres full of
blades, NVMe based SANs, NetApps and Isilon clusters. This is the world
that pays my wages - I know how big it is and who uses it, including
outfits the size you're talking about, many of them are customers of my
current and previous employers.

> IBM didn't pay big for RHEL to run it on laptops,
> but on its mainframes ......

Yes they are popular with banks and the like because they *also*
run their old OS-360 stuff without recompiling it, but to anyone who
doesn't need that they are very expensive for little gain. Guess what many
of their customers run in the RHEL environments - yep kubernetes and docker.

> Decentralized usually = SLOW ... and INSECURE ... despite
> claims.

Tell that to Amazon, Google etc. look into the architecture of
Amazon Dynamo and marvel at the way it scales and handles machine failures
and network outages. Mainframes are great up to a point, right up until you
can't get one big enough and then you *need* a scalable solution.
kubernetes is an easy way to get one.

I was involved in doing it the hard way back in 1990 when the UK
Inland Revenue had a problem their ICL mainframe team declared impossible,
twenty high end 88k boxes and a distributed architecture made it possible.
No mainframe could match the IO bandwidth or CPU power of that solution,
using it effectively took careful design.

SAAS is huge in the large corporate world, it all runs on
virtual machines and docker containers orchestrated by kubernetes. It's
only insecure if you don't know how to secure it, the most security
sensitive run it all in their own datacentres on hypervisors that they
control. The rest trust the contractual obligations of the companies that
run the data centres (Microsoft, Google and Amazon mostly).

The big trend in large users these days is micro-services in docker
containers. Instead of an OS image running in the container there is only
the application and support libraries running on bare virtual metal.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
Host: Beautiful Theory meet Inconvenient Fact
Obit: Beautiful Theory died today of factual inconsistency

On Thu, 16 Nov 2023 01:22:45 +0000, Ahem A Rivet's Shot wrote:

> On Wed, 15 Nov 2023 18:51:53 -0500 bill <bill.gunshannon@gmail.com>
> wrote:
>
>> I use Linux. As a desktop just like I use Windows.
>
> I use FreeBSD and MacOS for desktops.
>
>> For real computing I use real OSes. :-)
>
> For real computing I use FreeBSD.

+1

On 15/11/2023 23:51, bill wrote:

>
> I use Linux.  As a desktop just like I use Windows.
> For real computing I use real OSes.  :-)
>

For any computing, I like to have good driver support.

For real computing, I use Docker.

On Thu, 16 Nov 2023 00:47:55 -0500
"56d.1152" <56d.1152@ztq9.net> wrote:

> Sorry, but McDonalds Corporate, BOA, US Mil, etc ... they
> are NOT gonna work on Docker or Kubernetes on a bunch of

McDonald's don't use mainframes they use AWS which mostly uses -
you guessed it - kubernetes.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
Host: Beautiful Theory meet Inconvenient Fact
Obit: Beautiful Theory died today of factual inconsistency

On 15/11/2023 21:34, Ahem A Rivet's Shot wrote:
> On Wed, 15 Nov 2023 21:57:45 +0100
> Johnny Billquist <bqt@softjar.se> wrote:
>
>> On 2023-11-15 17:06, Ahem A Rivet's Shot wrote:
>
>>> Emacs springs to mind.
>>
>> Well - Emacs don't really come from the Unix world to start with...
>
> True - Teco editing macros originally.
>
>> But systemd always comes to my mind...
>
> I try not to let it <shudder> - anyway that's a Linux thing not seen
> on any other unix (it's one reason I tend to avoid Linux). Apparently it's
> not even remotely portable.
>
Systemd will be fine now Poettering has finished pottering with it, got
bored and is looking at something else to fuck up beyond all recognition.
Anther 50 man years of debugging and rewriting init scripts and quietly
discarding its worst stupidities and it will be no worse than X windows,
JavaScript, or PostScript.

--
For in reason, all government without the consent of the governed is the
very definition of slavery.

Jonathan Swift

On Thu, 16 Nov 2023 11:02:52 +0000
The Natural Philosopher <tnp@invalid.invalid> wrote:

> On 15/11/2023 21:34, Ahem A Rivet's Shot wrote:
> > On Wed, 15 Nov 2023 21:57:45 +0100

> > I try not to let it <shudder> - anyway that's a Linux thing not
> > seen on any other unix (it's one reason I tend to avoid Linux).
> > Apparently it's not even remotely portable.
> >
> Systemd will be fine now Poettering has finished pottering with it, got

It's never going to be portable to anything but Linux, that's
enough to write it off for me.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
Host: Beautiful Theory meet Inconvenient Fact
Obit: Beautiful Theory died today of factual inconsistency

On 11/16/2023 12:47 AM, 56d.1152 wrote:
> On 11/15/23 9:43 AM, Ahem A Rivet's Shot wrote:
>> On Wed, 15 Nov 2023 08:06:00 -0500
>> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>
>>> On 11/15/2023 2:44 AM, Ahem A Rivet's Shot wrote:
>>
>>>> I don't know about McDonald's but these days a lot of really big
>>>> systems run as a large (and variable) number of micro-services in
>>>> containers under Kubernetes. Scalability is the watchword today.
>>>> Sometimes they run on Z/OS machines (usually running Linux) otherwise
>>>> they run on a mix of blade servers (CPU and RAM tightly packed) and SAN
>>>> storage (lots of NVMe SSDs) connected with 40Gb or 100Gb ethernet.
>>>> Infrastructure as a service they call it.
>>>
>>> Most run such workloads in AWS/Azure/GCP/OCI.
>>
>> Of course, these environments are built for that purpose and allow
>> the systems developers to assume the Kubernetes infrastructure without
>> having to maintain it. But it is possible to run such workloads in a
>> private data centre - "TrueNAS Scale" is one fairly easy way.
>
>
> Sorry, but McDonalds Corporate, BOA, US Mil, etc ... they
> are NOT gonna work on Docker or Kubernetes on a bunch of
> tablets. IBM didn't pay big for RHEL to run it on laptops,
> but on its mainframes ......
>
> Decentralized usually = SLOW ... and INSECURE ... despite
> claims.

Yeah ...

Our former clients moved to "cloud solutions". They learned rather quickly that
they would not have their prior capabilities. Not sure just how much business
they can now handle, and, it's taking much more manpower. "But, it's what
everyone else does." Really?

Not that we gave them much of a choice. Either take over our software, which
was offered, or find another solution. They didn't want to be in the software
business. Not sure what anyone would call all the human labor is to support
their "cloud solution".

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On Wednesday, November 15, 2023 at 5:00:05 PM UTC-5, Ahem A Rivet's Shot wrote:
> > But systemd always comes to my mind...
> I try not to let it <shudder> - anyway that's a Linux thing not seen
> on any other unix (it's one reason I tend to avoid Linux). Apparently it's
> not even remotely portable.
> --
> Steve O'Hara-Smith
> Odds and Ends at http://www.sohara.org/
> Host: Beautiful Theory meet Inconvenient Fact
> Obit: Beautiful Theory died today of factual inconsistency

Systemd was more or less inspired by the MacOS launchd facility.

On 11/16/2023 8:00 AM, Dave Froble wrote:
> Our former clients moved to "cloud solutions".  They learned rather
> quickly that they would not have their prior capabilities.  Not sure
> just how much business they can now handle, and, it's taking much more
> manpower.  "But, it's what everyone else does."  Really?

I would think the capabilities depend on the software
and not on where it is hosted.

I assume they made two changes at the same time:
* dedicated physical system -> public cloud
* application X -> application Y

The loss of capabilities has to be because of the
second bullet.

If your application had been ported to VMS x86-64 and
the customers had deployed it in AWS/Azure/GCP/OCI then
it would have worked as well as always.

Arne

On 11/16/2023 6:38 AM, Ahem A Rivet's Shot wrote:
> On Thu, 16 Nov 2023 11:02:52 +0000
> The Natural Philosopher <tnp@invalid.invalid> wrote:
>> On 15/11/2023 21:34, Ahem A Rivet's Shot wrote:
>>> On Wed, 15 Nov 2023 21:57:45 +0100
>>> I try not to let it <shudder> - anyway that's a Linux thing not
>>> seen on any other unix (it's one reason I tend to avoid Linux).
>>> Apparently it's not even remotely portable.
>>>
>> Systemd will be fine now Poettering has finished pottering with it, got
>
> It's never going to be portable to anything but Linux, that's
> enough to write it off for me.

Is it surprising that a startup system for Linux
is coupled with Linux?

The code in VMS that execute SYS$SYSTEM:STARTUP.COM
and SYS$MANGER:SYSTARTUP_VMS.COM are probably not
portable to any other OS either.

(but likely only 1/100'th of the code in systemd)

Arne

On 11/16/2023 12:47 AM, 56d.1152 wrote:
> On 11/15/23 9:43 AM, Ahem A Rivet's Shot wrote:
>> On Wed, 15 Nov 2023 08:06:00 -0500
>> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> On 11/15/2023 2:44 AM, Ahem A Rivet's Shot wrote:
>>>>     I don't know about McDonald's but these days a lot of really big
>>>> systems run as a large (and variable) number of micro-services in
>>>> containers under Kubernetes. Scalability is the watchword today.
>>>> Sometimes they run on Z/OS machines (usually running Linux) otherwise
>>>> they run on a mix of blade servers (CPU and RAM tightly packed) and SAN
>>>> storage (lots of NVMe SSDs) connected with 40Gb or 100Gb ethernet.
>>>> Infrastructure as a service they call it.
>>>
>>> Most run such workloads in AWS/Azure/GCP/OCI.
>>     Of course, these environments are built for that purpose and allow
>> the systems developers to assume the Kubernetes infrastructure without
>> having to maintain it. But it is possible to run such workloads in a
>> private data centre - "TrueNAS Scale" is one fairly easy way.
>
>   Sorry, but McDonalds Corporate, BOA, US Mil, etc ... they
>   are NOT gonna work on Docker or Kubernetes on a bunch of
>   tablets. IBM didn't pay big for RHEL to run it on laptops,
>   but on its mainframes ......

RHEL big market is x86-64 servers. Mainframe is a small part
(too few mainframes, only some of them running Linux and
RHEL is just one out of many Linux distros used on mainframe).

Arne

Ahem A Rivet's Shot <steveo@eircom.net> wrote:
>
> Yes they are popular with banks and the like because they *also*
>run their old OS-360 stuff without recompiling it, but to anyone who
>doesn't need that they are very expensive for little gain. Guess what many
>of their customers run in the RHEL environments - yep kubernetes and docker.

The IBM systems are I/O machines. The CPU is just sitting there telling the
I/O controllers what to do and most of the real work is being done by other
hardware outside the CPU. So you can have incredibly high workloads and
huge transation rates with relatively slow CPUs.

This was a huge win as late as a decade ago, but these days it's not that
much of a win unless you have a write-mostly database that is inefficient
to distribute. Because CPU has become so damn cheap that we just throw
CPU at problems now.

>> Decentralized usually = SLOW ... and INSECURE ... despite
>> claims.
>
> Tell that to Amazon, Google etc. look into the architecture of
>Amazon Dynamo and marvel at the way it scales and handles machine failures
>and network outages. Mainframes are great up to a point, right up until you
>can't get one big enough and then you *need* a scalable solution.
>kubernetes is an easy way to get one.

This is true, but Amazon and Google -are- still slow and insecure in ways
that I don't think is apparently obvious. Instead of keeping one thing
secure, you have thousands upon thousands to keep secure.

> SAAS is huge in the large corporate world, it all runs on
>virtual machines and docker containers orchestrated by kubernetes. It's
>only insecure if you don't know how to secure it, the most security
>sensitive run it all in their own datacentres on hypervisors that they
>control. The rest trust the contractual obligations of the companies that
>run the data centres (Microsoft, Google and Amazon mostly).

This is where the scary part is, yes.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On Thu, 16 Nov 2023 08:26:33 -0500
Arne Vajhøj <arne@vajhoej.dk> wrote:

> On 11/16/2023 6:38 AM, Ahem A Rivet's Shot wrote:

> > It's never going to be portable to anything but Linux, that's
> > enough to write it off for me.
>
> Is it surprising that a startup system for Linux
> is coupled with Linux?

Yes given that Linux purports to be a unix which has always had
portability as a major feature. You can use SysV or BSD init (Linux used to
use SysV init) on Linux or any other unix quite easily. You cannot use
systemd on anything unix than Linux - and yes there are still many unix
systems that are not Linux.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
Host: Beautiful Theory meet Inconvenient Fact
Obit: Beautiful Theory died today of factual inconsistency

On Thu, 16 Nov 2023 08:00:11 -0500
Dave Froble <davef@tsoft-inc.com> wrote:

> Our former clients moved to "cloud solutions". They learned rather
> quickly that they would not have their prior capabilities. Not sure just
> how much business they can now handle, and, it's taking much more
> manpower. "But, it's what everyone else does." Really?

So they did it badly - not uncommon. Amazon could not function
without a distributed, scalable, fault tolerant system, there's no way you
could run Amazon mainframe style. Even their core database is distributed,
scalable and fault tolerant relying on guaranteed eventual consistency
rather than ACID which does not scale.

McDonald's did it well.

<https://www.ciodive.com/news/mcdonalds-cloud-ETL-talend-digital-transformation/523132/
>

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
Host: Beautiful Theory meet Inconvenient Fact
Obit: Beautiful Theory died today of factual inconsistency

On 11/16/2023 9:59 AM, Ahem A Rivet's Shot wrote:
> On Thu, 16 Nov 2023 08:00:11 -0500
> Dave Froble <davef@tsoft-inc.com> wrote:
>> Our former clients moved to "cloud solutions". They learned rather
>> quickly that they would not have their prior capabilities. Not sure just
>> how much business they can now handle, and, it's taking much more
>> manpower. "But, it's what everyone else does." Really?
>
> So they did it badly - not uncommon. Amazon could not function
> without a distributed, scalable, fault tolerant system, there's no way you
> could run Amazon mainframe style. Even their core database is distributed,
> scalable and fault tolerant relying on guaranteed eventual consistency
> rather than ACID which does not scale.

I believe Amazon is using many different databases.

Some that provide traditional consistency (MySQL and AuroraDB) and
some that provide eventual consistency (DynamoDB and SimpleDB).

> McDonald's did it well.
>
> <https://www.ciodive.com/news/mcdonalds-cloud-ETL-talend-digital-transformation/523132/

It seems that article is about DWH not operational data. Different.

Arne

On 16 Nov 2023 13:36:17 -0000
kludge@panix.com (Scott Dorsey) wrote:

> The IBM systems are I/O machines. The CPU is just sitting there telling
> the I/O controllers what to do and most of the real work is being done by
> other hardware outside the CPU. So you can have incredibly high
> workloads and huge transation rates with relatively slow CPUs.

Yes you can but ...

> This was a huge win as late as a decade ago, but these days it's not that
> much of a win unless you have a write-mostly database that is inefficient
> to distribute. Because CPU has become so damn cheap that we just throw
> CPU at problems now.

Back in 1990 I was involved in designing a system that could not
have been run on the mainframes of the day because they had insufficient IO
bandwidth but a distributed solution spread across twenty high end 88K
machines did.

> > Tell that to Amazon, Google etc. look into the architecture of
> >Amazon Dynamo and marvel at the way it scales and handles machine
> >failures and network outages. Mainframes are great up to a point, right
> >up until you can't get one big enough and then you *need* a scalable
> >solution. kubernetes is an easy way to get one.
>
> This is true, but Amazon and Google -are- still slow and insecure in ways
> that I don't think is apparently obvious. Instead of keeping one thing
> secure, you have thousands upon thousands to keep secure.

Yes but instead of trying to secure each one individually you write
rules which are used by the deployment engine (kubernetes usually).

A single instance implemented on virtual hardware is certainly
slower than the same thing implemented on bare metal - the win comes from
having a scalable design. The artful part is making the design scalable and
not putting bottlenecks in it. If the single instance is 1/10th the speed
of bare metal but you can run a thousand instances in parallel then you
have 100 times the speed of bare metal.

> > SAAS is huge in the large corporate world, it all runs on
> >virtual machines and docker containers orchestrated by kubernetes. It's
> >only insecure if you don't know how to secure it, the most security
> >sensitive run it all in their own datacentres on hypervisors that they
> >control. The rest trust the contractual obligations of the companies that
> >run the data centres (Microsoft, Google and Amazon mostly).
>
> This is where the scary part is, yes.

Yes it is - that's why my data lives at home. I don't need scalable
solutions thankfully. Those who do and care a lot run their own.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
Host: Beautiful Theory meet Inconvenient Fact
Obit: Beautiful Theory died today of factual inconsistency

Ahem A Rivet's Shot <steveo@eircom.net> writes:
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 11/16/2023 6:38 AM, Ahem A Rivet's Shot wrote:
>>> It's never going to be portable to anything but Linux, that's enough
>>> to write it off for me.
>>
>> Is it surprising that a startup system for Linux is coupled with
>> Linux?
>
> Yes given that Linux purports to be a unix which has always had
> portability as a major feature.

Portability to different CPUs, sure, but portability of system tools to
other kernels? Who ever said that was a goal of Linux as such?

(Some of them _are_ somewhat portable, and the GNU project in
particulary lists tool portability as a goal, albeit with some nuance,
but that’s not the same thing.)

--
https://www.greenend.org.uk/rjk/

Richard Kettlewell <invalid@invalid.invalid> writes:
> Ahem A Rivet's Shot <steveo@eircom.net> writes:
>> Johnny Billquist <bqt@softjar.se> wrote:
>>> Well. I don't fully agree with that, but I'm fine with just
>>> disagreeing without getting into any further discussions. I can
>>> certainly dig up other tools under Unix which left the "unix
>>> paradigm" behind a long time ago, if you want.
>>
>> Emacs springs to mind.
>
> Originated outside Unix, I think.
>
> dd seems like a good example. Present at least as far back as V5 Unix
> but its interface is belligerently different from any other Unix tool,
> and it’s at best an uneasy fit with the “do one thing well” approach of
> many of its siblings.

Oh, and the kernel is an example, of course. Process management, memory
management, hardware drivers, multiple quite different kinds of IO and
some other stuff, all in a single monolithic whole. Completely the
opposite of the “do one thing well” principle. The reasons for this
aren’t terrible but let’s not pretend that the Unix kernel is an
examplar of the Unix philosophy l-)

--
https://www.greenend.org.uk/rjk/

On Thu, 16 Nov 2023 10:51:04 -0500
Arne Vajhøj <arne@vajhoej.dk> wrote:

> On 11/16/2023 9:59 AM, Ahem A Rivet's Shot wrote:

> > So they did it badly - not uncommon. Amazon could not function
> > without a distributed, scalable, fault tolerant system, there's no way
> > you could run Amazon mainframe style. Even their core database is
> > distributed, scalable and fault tolerant relying on guaranteed eventual
> > consistency rather than ACID which does not scale.
>
> I believe Amazon is using many different databases.

AWS provides many databases. Dynamo was created to support Amazon's
original core business of being a huge international shopping site.

> > McDonald's did it well.
> >
> > <https://www.ciodive.com/news/mcdonalds-cloud-ETL-talend-digital-transformation/523132/
>
> It seems that article is about DWH not operational data. Different.

It's about analytics that record every sale in every McDonald's in
the world and drives their decision making. The point is that it scales
beyond anything that could be done on a mainframe.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
Host: Beautiful Theory meet Inconvenient Fact
Obit: Beautiful Theory died today of factual inconsistency

On Thu, 16 Nov 2023 16:28:27 +0000
Richard Kettlewell <invalid@invalid.invalid> wrote:

> Ahem A Rivet's Shot <steveo@eircom.net> writes:
> > Arne Vajhøj <arne@vajhoej.dk> wrote:
> >> On 11/16/2023 6:38 AM, Ahem A Rivet's Shot wrote:
> >>> It's never going to be portable to anything but Linux, that's enough
> >>> to write it off for me.
> >>
> >> Is it surprising that a startup system for Linux is coupled with
> >> Linux?
> >
> > Yes given that Linux purports to be a unix which has always had
> > portability as a major feature.
>
> Portability to different CPUs, sure, but portability of system tools to
> other kernels? Who ever said that was a goal of Linux as such?

It's always been a goal in the unix world - which Linux seems to be
leaving.

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).
Apart from systemd the only things I know of that only run on Linux and not
on any other unix are commercial closed source binaries - and even most of
them can be run on FreeBSD using the Linux compatibility layer.

The other major camp of open source unix shares code very freely -
NetBSD's pkgsrc was originally based on FreeBSD ports and is used in
DragonFLyBSD for example. AT&T's SysVR4 was able to incorporate code from
BSD and XENIX because the code was designed to be portable.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
Host: Beautiful Theory meet Inconvenient Fact
Obit: Beautiful Theory died today of factual inconsistency

On Thu, 16 Nov 2023 16:35:59 +0000
Richard Kettlewell <invalid@invalid.invalid> wrote:

> Oh, and the kernel is an example, of course. Process management, memory
> management, hardware drivers, multiple quite different kinds of IO and
> some other stuff, all in a single monolithic whole. Completely the
> opposite of the “do one thing well” principle. The reasons for this
> aren’t terrible but let’s not pretend that the Unix kernel is an
> examplar of the Unix philosophy l-)

Excellent point - there's the Mach kernel of course which gets
closer.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
Host: Beautiful Theory meet Inconvenient Fact
Obit: Beautiful Theory died today of factual inconsistency