VMS on Raspberry Pi 5

Systemd will be fine now Poettering has finished pottering with it, got bored and is looking at something else to f*ck 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.

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

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".

IATWP.

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

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

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

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.

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.

This is where the scary part is, yes.

--scott

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.

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.

Yes you can but ...

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.

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.

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.

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).

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

Arne

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.)

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

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.

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-)

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.

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

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).

In the more recent case of systemd, a lot of the functionality depends on Linux-specific interfaces. Porting it would presumably be a 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.

That doesn’t make it a goal _of Linux_, even if it was a goal of the GNU and X11 projects.

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.

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.

Apart from systemd every other init system is shell script based and reasonably easy to port, systemd is a huge departure from convention.

Nobody maintaining other operating systems wants them to become Linux based which is essentially what would be needed.

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.

IMHO it should be a goal of Linux OS development to be a good member of the unix community without which there would be no Linux. But you're right it seems that it isn't something that RedHat, Debian, Ubuntu et al care about.