On 2023-07-17 15:30, Dave Froble wrote:
> On 7/17/2023 6:55 AM, Johnny Billquist wrote:
>> On 2023-07-16 00:42, Dave Froble wrote:
>>
>>> Ok, my test was on a VAX, but I doubt that has any bearing.  Don't
>>> have a
>>> clue. Unless you're trying to read the file while it's still open.  That
>>> doesn't work.
>>
>> Why wouldn't it work on an open file? As long as you are allowed
>> shared reading
>> it should be just fine.
>>
>>   Johnny
>>
>
> I'm not familiar with the TYPE utility.

Oh. You meand it more specifically in the context of that
program/command. Ok, fair enough. I wouldn't know about TYPE limitations
myself either. But as a general thing about files in ODS5, you can
certainly read them while they are open.

> I am a bit familiar with RMS, the DLM, and usage.
>
> My guess is that the utility doesn't use any "read regardless"
> capability.  So "allowed shared reading" may not be in use.  Just a guess.

Your guess is as good as mine on that specific question.

Under RSX, TYPE is under the hood using PIP. And PIP have a switch /SR
for shared reading. That switch don't seem to be exposed under DCL.
But with MCR, you can certainly type a file that is open.

Johnny

On 2023-07-17 15:29, Arne Vajhøj wrote:
> On 7/17/2023 6:45 AM, Johnny Billquist wrote:
>> On 2023-07-16 20:30, Arne Vajhøj wrote:
>>> On 7/16/2023 2:28 PM, Arne Vajhøj wrote:
>>>> The two cost are hardware and peoples time.
>>>>
>>>> With todays TB disks it is very unlikely that having two copies of some
>>>> executables will require buying bigger and more expensive disk(s).
>>>>
>>>> Having developer support the name test logic on multiple platforms
>>>> and having sys admins needing to worry about linked stuff
>>>> when they clean up is a very small effort but still an
>>>> effort greater than zero.
>>>
>>> And just to make sure we are talking about the same.
>>
>> [...]
>>
>> Yes. And my point is that this detail is there no matter what. So you
>> didn't "save" anything by having two binaries. Since it's actually
>> just one binary, and how it behaves is based on which name it was
>> invoked as.
>>
>> Yes, you *could* have different binaries, with the different
>> behaviors, and not have to deal with all this.
>>
>> But that was not what was going on here. The binary we are talking
>> about still have this logic you are hinting at. It's just that in
>> addition to that engineering work, which seems to be your concern, it
>> also uses up twice the space (or even more, depending on how many
>> copies of the program you happen to install).
>>
>> I feel like you didn't get the point that the decision on what the
>> program should do based on under what name it was invoked was not
>> absent with these multiple copies... It is still there, and still made
>> use of.
>
> Ah.
>
> You are saying that they ditched the linking but kept the code
> that made linking work.

*Yes*

That was the whole point. And it "works" for them even without the
hardlinks. It's just a question of the program inspecting what it was
invoked as.
Under Unix, every file is always a hardlink. It's just a question of if
you have just one, or multiple ones...

> As if in my example had done:
>
> $ cc ab
> $ link/exe=a ab
> $ link/exe=b ab
>
> That is silly in my opinion. They should have gotten rid of that code.

Agreed. And that is where they were being really silly, and I felt you
missed this.

And it could have been done even simpler:

$ cc ab
$ link/exe=a ab
$ copy a.exe b.exe

Which most probably is what was actually done... Instead of creating a
hard link for b.exe...

> Simple is good - complex is bad.

Always.

Johnny

On 2023-07-17 13:36, Jan-Erik Söderholm wrote:
> Den 2023-07-17 kl. 12:52, skrev Johnny Billquist:
>> On 2023-07-16 20:09, Arne Vajhøj wrote:
>>> On 7/15/2023 10:47 AM, Johnny Billquist wrote:
>>>> And the secondary problem being that it's a little tricky to find
>>>> the last n lines in such a file organization. You'll have to do some
>>>> heuristics, and hope you got it right. But that usually is possible
>>>> to do with a high chance of success. So it could definitely be done.
>>>> (I have such a tool for RSX...)
>>>
>>> It depends on the record format.
>>
>> Right. But in this case, the record format was given.
>>
>>> VAR,VFC => read from start or make a good guess
>>> FIX, STM, STMLF, STMCR => no problem
>>> UDF => "last n lines" is not defined
>>
>> And in this case it was VFC. And as I said - you can usually make a
>> good guess.
>>
>>    Johnny
>>
>
> But, "read from start" is the same as TYPE without /TAIL. And that is
> what I do when I get that error from TYPE/TAIL. Just TYPE the log file
> and let it scroll to the end, the net result is the same as when using
> /tail, the last 24 (or so) lines are on the screen. And besides, more
> lines are available based on the size of my scroll-back buffer in the
> emulator, usually 20000 or 200000 lines.

Notice the "or" keyword in there... ;-)

The "make a good guess" is basically about jumping close to the end of
the file, and trying to identify the VFC lenght fields, and from that
extract the actual lines, and show the last n of them.
Which usually can be done with a fair amount of confidence, since for
text files, lines are seldom extremely long, nor do they contain random
control characters. Thus, if you just scan for control characters
(probably NUL) on an odd byte, this is most likely the second byte of a
record length, and you have your line starting there. And then
everything else follows trivially from that.

No need to read through the whole file. But it requires that you
actually read the full disk blocks of content, and not the pre-processed
data coming out of RMS.

Johnny

On 7/17/2023 10:32 AM, Johnny Billquist wrote:
> On 2023-07-17 15:29, Arne Vajhøj wrote:
>> You are saying that they ditched the linking but kept the code
>> that made linking work.
>
> *Yes*

>> That is silly in my opinion. They should have gotten rid of that code.
>
> Agreed. And that is where they were being really silly, and I felt you
> missed this.

I did!

Arne

On 7/17/2023 12:37 AM, gah4 wrote:
> On Sunday, July 16, 2023 at 11:30:26 AM UTC-7, Arne Vajhøj wrote:
>> #include <stdio.h>
>> #include <string.h>
>>
>> int main(int argc, char *argv[])
>> {
>> if(strstr(argv[0], "]a.exe;") != NULL)
>> {
>> printf("I am A\n");
>> }
>> if(strstr(argv[0], "]b.exe;") != NULL)
>> {
>> printf("I am B\n");
>> }
>> return 0;
>> }
>
> I suspect you need a slightly better way to recognize the program name.
>
> I am not so sure what VMS passes for argv[0] in all cases.

Neither am I.

It just worked for my case.

I will certainly not work on other OS.

But that is the point. It is a complication.

Arne

On 7/17/2023 9:29 AM, Arne Vajhøj wrote:

> Simple is good - complex is bad.

I'm a firm believer in KISS ...

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

$ help type /tail

TYPE

/TAIL

/TAIL[=n]

Displays the last several lines of a log file. The value, n,
defaults to p-2 where p is the current terminal page length. You
can use TYPE/TAIL only if all of the following criteria are true:

o File organization is sequential.

o The longest record is less than 512 bytes.

o The record format is either VAR, VFC, STM, STRCM or STMLF
(for more information, see the description of FAB$B_RFM in the
OpenVMS Record Management Services Reference Manual).

o The file being typed is on a device that supports random
access. The TYPE/TAIL command does not work on magnetic tape
drives.

Even with this criteria, some file conditions cannot be
anticipated and may not allow display of the last several lines
of a log file, resulting in the following error message:

%TYPE-W-READERR, error reading DEVICE:[DIRECTORY]FILE.EXT;1
-SYSTEM-E-UNSUPPORTED, unsupported operation or function

--
-- Rob

On 2023-07-15, Chris Townley <news@cct-net.co.uk> wrote:
> On 15/07/2023 02:33, gah4 wrote:
>> On Friday, July 14, 2023 at 4:36:41?PM UTC-7, Chris Townley wrote:
>>
>> (snip, I wrote)
>>
>>>> Reminds me of, years ago, porting gnu-utils to OS/2 and finding that
>>>> tail -f works. I don't know if tail -f is supposed to work on VMS, though.
>>
>> tail -f reads the end of a file, then waits and checks to see if it got bigger.
>> That is, if the EOF went away.
>>
>> Not all file system, I suspect, can do that.
>>
>
> Sorry, I should have said TYPE/TAIL/CONTINUOUS which works with some
> caveats on the file
>

Does that work these days when the file is still open for write by
another user ?

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2023-07-17, Dave Froble <davef@tsoft-inc.com> wrote:
> On 7/17/2023 9:29 AM, Arne Vajhøj wrote:
>
>> Simple is good - complex is bad.
>
> I'm a firm believer in KISS ...
>

Then you should strongly prefer Unix over VMS... :-)

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 7/18/2023 8:21 AM, Simon Clubley wrote:
> On 2023-07-17, Dave Froble <davef@tsoft-inc.com> wrote:
>> On 7/17/2023 9:29 AM, Arne Vajhøj wrote:
>>
>>> Simple is good - complex is bad.
>>
>> I'm a firm believer in KISS ...
>>
>
> Then you should strongly prefer Unix over VMS... :-)
>
> Simon.
>

You've totally lost your mind!

--
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 2023-07-18 14:21, Simon Clubley wrote:
> On 2023-07-17, Dave Froble <davef@tsoft-inc.com> wrote:
>> On 7/17/2023 9:29 AM, Arne Vajhøj wrote:
>>
>>> Simple is good - complex is bad.
>>
>> I'm a firm believer in KISS ...
>>
>
> Then you should strongly prefer Unix over VMS... :-)

Depends on which corner you look at.

Asynchronous I/O in Unix is a mess.

Johnny

On 2023-07-18 14:17, Simon Clubley wrote:
> On 2023-07-15, Chris Townley <news@cct-net.co.uk> wrote:
>> On 15/07/2023 02:33, gah4 wrote:
>>> On Friday, July 14, 2023 at 4:36:41?PM UTC-7, Chris Townley wrote:
>>>
>>> (snip, I wrote)
>>>
>>>>> Reminds me of, years ago, porting gnu-utils to OS/2 and finding that
>>>>> tail -f works. I don't know if tail -f is supposed to work on VMS, though.
>>>
>>> tail -f reads the end of a file, then waits and checks to see if it got bigger.
>>> That is, if the EOF went away.
>>>
>>> Not all file system, I suspect, can do that.
>>>
>>
>> Sorry, I should have said TYPE/TAIL/CONTINUOUS which works with some
>> caveats on the file
>>
>
> Does that work these days when the file is still open for write by
> another user ?

Not sure why you think that would be an unsurmountable problem...

Johnny

On Tue, 2023-07-18 at 16:05 +0200, Johnny Billquist wrote:
> Asynchronous I/O in Unix is a mess.

THey've had three goes at getting it right. There was AIO years back,
something else that I forget the name of, and then there's io-uring,
the latest thing to land. From what I've gathered it can do a lot
without incurring context switches penalty.
--
Tactical Nuclear Kittens

On 7/18/2023 8:21 AM, Simon Clubley wrote:
> On 2023-07-17, Dave Froble <davef@tsoft-inc.com> wrote:
>> On 7/17/2023 9:29 AM, Arne Vajhøj wrote:
>>
>>> Simple is good - complex is bad.
>>
>> I'm a firm believer in KISS ...
>
> Then you should strongly prefer Unix over VMS... :-)

I am not so sure about that.

VMS is probably one of the smallest and leanest commercial
OS'es today.

It may be more a result of lack of investment for 20 years
than a deliberate strategy. And we we miss a lot of things.
But still small code base and small API.

I am pretty sure that if VMS kernel had most Macro-32 and
Bliss code rewritten to C, then VMS kernel would be
smaller than just systemd. :-)

Arne

On 2023-07-18, Dave Froble <davef@tsoft-inc.com> wrote:
> On 7/18/2023 8:21 AM, Simon Clubley wrote:
>> On 2023-07-17, Dave Froble <davef@tsoft-inc.com> wrote:
>>> On 7/17/2023 9:29 AM, Arne Vajhøj wrote:
>>>
>>>> Simple is good - complex is bad.
>>>
>>> I'm a firm believer in KISS ...
>>>
>>
>> Then you should strongly prefer Unix over VMS... :-)
>>
>
> You've totally lost your mind!
>

Why ? It's a lot easier to write applications with modern requirements
under Unix, especially Linux, than it is under VMS.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2023-07-18, Johnny Billquist <bqt@softjar.se> wrote:
> On 2023-07-18 14:17, Simon Clubley wrote:
>> On 2023-07-15, Chris Townley <news@cct-net.co.uk> wrote:
>>> On 15/07/2023 02:33, gah4 wrote:
>>>> On Friday, July 14, 2023 at 4:36:41?PM UTC-7, Chris Townley wrote:
>>>>
>>>> (snip, I wrote)
>>>>
>>>>>> Reminds me of, years ago, porting gnu-utils to OS/2 and finding that
>>>>>> tail -f works. I don't know if tail -f is supposed to work on VMS, though.
>>>>
>>>> tail -f reads the end of a file, then waits and checks to see if it got bigger.
>>>> That is, if the EOF went away.
>>>>
>>>> Not all file system, I suspect, can do that.
>>>>
>>>
>>> Sorry, I should have said TYPE/TAIL/CONTINUOUS which works with some
>>> caveats on the file
>>>
>>
>> Does that work these days when the file is still open for write by
>> another user ?
>
> Not sure why you think that would be an unsurmountable problem...
>

At what point did I say that ?

I'm interested if you can use TYPE/TAIL/CONTINUOUS on files open for
write these days.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2023-07-18, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 7/18/2023 8:21 AM, Simon Clubley wrote:
>> On 2023-07-17, Dave Froble <davef@tsoft-inc.com> wrote:
>>> On 7/17/2023 9:29 AM, Arne Vajhøj wrote:
>>>
>>>> Simple is good - complex is bad.
>>>
>>> I'm a firm believer in KISS ...
>>
>> Then you should strongly prefer Unix over VMS... :-)
>
> I am not so sure about that.
>
> VMS is probably one of the smallest and leanest commercial
> OS'es today.
>
> It may be more a result of lack of investment for 20 years
> than a deliberate strategy. And we we miss a lot of things.
> But still small code base and small API.
>

How does that API compare to the APIs available on Unix (especially
Linux) when you want to write an application (especially one with
modern requirements) ?

VMS had a world-leading API 20-30 years ago, but things (and expectations)
have moved on since then.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 7/18/2023 1:31 PM, Simon Clubley wrote:
> On 2023-07-18, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 7/18/2023 8:21 AM, Simon Clubley wrote:
>>> On 2023-07-17, Dave Froble <davef@tsoft-inc.com> wrote:
>>>> On 7/17/2023 9:29 AM, Arne Vajhøj wrote:
>>>>
>>>>> Simple is good - complex is bad.
>>>>
>>>> I'm a firm believer in KISS ...
>>>
>>> Then you should strongly prefer Unix over VMS... :-)
>>
>> I am not so sure about that.
>>
>> VMS is probably one of the smallest and leanest commercial
>> OS'es today.
>>
>> It may be more a result of lack of investment for 20 years
>> than a deliberate strategy. And we we miss a lot of things.
>> But still small code base and small API.
>
> How does that API compare to the APIs available on Unix (especially
> Linux) when you want to write an application (especially one with
> modern requirements) ?
>
> VMS had a world-leading API 20-30 years ago, but things (and expectations)
> have moved on since then.

????

The third letter in KISS stands for simple not for feature-rich.

Linux as of today is definitely feature rich but it is not
simple.

Arne

On 2023-07-18, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 7/18/2023 1:31 PM, Simon Clubley wrote:
>> On 2023-07-18, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> On 7/18/2023 8:21 AM, Simon Clubley wrote:
>>>> On 2023-07-17, Dave Froble <davef@tsoft-inc.com> wrote:
>>>>> On 7/17/2023 9:29 AM, Arne Vajhøj wrote:
>>>>>
>>>>>> Simple is good - complex is bad.
>>>>>
>>>>> I'm a firm believer in KISS ...
>>>>
>>>> Then you should strongly prefer Unix over VMS... :-)
>>>
>>> I am not so sure about that.
>>>
>>> VMS is probably one of the smallest and leanest commercial
>>> OS'es today.
>>>
>>> It may be more a result of lack of investment for 20 years
>>> than a deliberate strategy. And we we miss a lot of things.
>>> But still small code base and small API.
>>
>> How does that API compare to the APIs available on Unix (especially
>> Linux) when you want to write an application (especially one with
>> modern requirements) ?
>>
>> VMS had a world-leading API 20-30 years ago, but things (and expectations)
>> have moved on since then.
>
> ????
>
> The third letter in KISS stands for simple not for feature-rich.
>

I know that Arne, and that is _exactly_ my point.

> Linux as of today is definitely feature rich but it is not
> simple.
>

It's a hell of a lot simpler to implement an application on Linux
than it is to implement that application on VMS.

Linux gives you functionality that is expected these days, but is
missing from VMS. That's what I am primarily referring to above.

For one example, I refer you to Stephen's often posted diatribe about
the effort involved in writing a secure network application on VMS
versus doing the same thing on Linux.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2023-07-18 17:09, Single Stage to Orbit wrote:
> On Tue, 2023-07-18 at 16:05 +0200, Johnny Billquist wrote:
>> Asynchronous I/O in Unix is a mess.
>
> THey've had three goes at getting it right. There was AIO years back,
> something else that I forget the name of, and then there's io-uring,
> the latest thing to land. From what I've gathered it can do a lot
> without incurring context switches penalty.

Well, context switching is yet another story. Shouldn't really have
anything to do with doing asynchronous I/O...

But yeah... AIO. Oh what fun. And at the moment, there is a lot of focus
on epoll, but that only exists in Linux. Of course, this also leads to
the comment that you need to have multiple solutions in the code to deal
with the different variants of Unix... epoll is sortof nice, since it
gathers a lot of file descriptors inside another single file descriptor,
and you can then do blocking operations on that one fd, and from there
work out what to do when anything happens. And it can be made rather
efficient, especially when you are doing lots of I/O to lots of file
descriptors. But it's also a bit complicated to actually work with if
you want to get the most out of it, and easy to get into a situation
where it gets stuck instead.

Another area where Unix/Linux is pretty complicated is shared libraries.
It works, but don't try to explain how it actually works. It's
definitely on the complicated side... (along with the dynamic loaded
libraries...)

In general, there is no one OS where everything is nice and simple
(except RSX of course... ;-) )

Johnny

On 7/18/2023 1:55 PM, Simon Clubley wrote:
> On 2023-07-18, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 7/18/2023 1:31 PM, Simon Clubley wrote:
>>> On 2023-07-18, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>> On 7/18/2023 8:21 AM, Simon Clubley wrote:
>>>>> On 2023-07-17, Dave Froble <davef@tsoft-inc.com> wrote:
>>>>>> On 7/17/2023 9:29 AM, Arne Vajhøj wrote:
>>>>>>
>>>>>>> Simple is good - complex is bad.
>>>>>>
>>>>>> I'm a firm believer in KISS ...
>>>>>
>>>>> Then you should strongly prefer Unix over VMS... :-)
>>>>
>>>> I am not so sure about that.
>>>>
>>>> VMS is probably one of the smallest and leanest commercial
>>>> OS'es today.
>>>>
>>>> It may be more a result of lack of investment for 20 years
>>>> than a deliberate strategy. And we we miss a lot of things.
>>>> But still small code base and small API.
>>>
>>> How does that API compare to the APIs available on Unix (especially
>>> Linux) when you want to write an application (especially one with
>>> modern requirements) ?
>>>
>>> VMS had a world-leading API 20-30 years ago, but things (and expectations)
>>> have moved on since then.
>>
>> ????
>>
>> The third letter in KISS stands for simple not for feature-rich.
>
> I know that Arne, and that is _exactly_ my point.

Well - Linux is not simple.

>> Linux as of today is definitely feature rich but it is not
>> simple.
>
> It's a hell of a lot simpler to implement an application on Linux
> than it is to implement that application on VMS.
>
> Linux gives you functionality that is expected these days, but is
> missing from VMS. That's what I am primarily referring to above.

Linux is not simpler than VMS. Linux is more feature rich than VMS.

In theory that would mean than an application on Linux is
simpler than an application on VMS. Because given same functionality
then the OS doing more means the application has to do less.

But practice is more that an application on Linux has more features
than on VMS and it is more complex because of the code needed
to use all those Linux features.

At least I do not recall ever seeing all those simple Linux
applications.

Latest Debian distro is over 1.3 BLOC.

> For one example, I refer you to Stephen's often posted diatribe about
> the effort involved in writing a secure network application on VMS
> versus doing the same thing on Linux.

The basic application API's are the same. C/C++ applications use OpenSSL
(or LibreSSL or GnuTLS). Java application use the builtin JCE. PHP
applications get it via Apache and OpenSSL. Python has a builtin
(that is a wrapper around OpenSSL).

Linux got more tools on top of the basic.

But having more tools is not what I call simple.

Arne

On 7/18/23 19:30, Arne Vajhøj wrote:
> On 7/18/2023 1:55 PM, Simon Clubley wrote:
>> On 2023-07-18, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> On 7/18/2023 1:31 PM, Simon Clubley wrote:
>>>> On 2023-07-18, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>>> On 7/18/2023 8:21 AM, Simon Clubley wrote:
>>>>>> On 2023-07-17, Dave Froble <davef@tsoft-inc.com> wrote:
>>>>>>> On 7/17/2023 9:29 AM, Arne Vajhøj wrote:
>>>>>>>
>>>>>>>> Simple is good - complex is bad.
>>>>>>>
>>>>>>> I'm a firm believer in KISS ...
>>>>>>
>>>>>> Then you should strongly prefer Unix over VMS... :-)
>>>>>
>>>>> I am not so sure about that.
>>>>>
>>>>> VMS is probably one of the smallest and leanest commercial
>>>>> OS'es today.
>>>>>
>>>>> It may be more a result of lack of investment for 20 years
>>>>> than a deliberate strategy. And we we miss a lot of things.
>>>>> But still small code base and small API.
>>>>
>>>> How does that API compare to the APIs available on Unix (especially
>>>> Linux) when you want to write an application (especially one with
>>>> modern requirements) ?
>>>>
>>>> VMS had a world-leading API 20-30 years ago, but things (and
>>>> expectations)
>>>> have moved on since then.
>>>
>>> ????
>>>
>>> The third letter in KISS stands for simple not for feature-rich.
>>
>> I know that Arne, and that is _exactly_ my point.
>
> Well - Linux is not simple.
>
>>> Linux as of today is definitely feature rich but it is not
>>> simple.
>>
>> It's a hell of a lot simpler to implement an application on Linux
>> than it is to implement that application on VMS.
>>
>> Linux gives you functionality that is expected these days, but is
>> missing from VMS. That's what I am primarily referring to above.
>
> Linux is not simpler than VMS. Linux is more feature rich than VMS.
>
> In theory that would mean than an application on Linux is
> simpler than an application on VMS. Because given same functionality
> then the OS doing more means the application has to do less.
>
> But practice is more that an application on Linux has more features
> than on VMS and it is more complex because of the code needed
> to use all those Linux features.
>
> At least I do not recall ever seeing all those simple Linux
> applications.
>
> Latest Debian distro is over 1.3 BLOC.
>
>> For one example, I refer you to Stephen's often posted diatribe about
>> the effort involved in writing a secure network application on VMS
>> versus doing the same thing on Linux.
>
> The basic application API's are the same. C/C++ applications use OpenSSL
> (or LibreSSL or GnuTLS). Java application use the builtin JCE. PHP
> applications get it via Apache and OpenSSL. Python has a builtin
> (that is a wrapper around OpenSSL).
>
> Linux got more tools on top of the basic.
>
> But having more tools is not what I call simple.
>
> Arne
>

Develop under FreeBSD here, but have spent a few days recently
evaluating current Linux distros, one of which is Debian. If anything,
the mass adoption of systemd has a been a disaster in terms of
system complexity, which only increases the possible attack surface
width. If you hold the nose, Debian Bookworm is pretty good at user
level but so is Devuan, the systemd free Debian, which seems every
bit as good. Also looked at Suse, like meeting an old friend, but again,
systemd encumbered and nothing is where one expects it to be. Still
have 11.4 on a couple of old laptops, which is how unix should be.
Fedora produced rubbish on screen, while Xunbuntu works out of the
box, just like Debian and Suse.

I need to build and test some code under Linux, as FreeBSD is not so
mainstream, though a thoroughly more straightforward and hassle free
experience than any current Linux. Always saw systemd as a power grab
by Redhat and their most recent antics over source licensing only
serve to reinforce that view. All about the money, as usual, sadly...

Chris

On 7/18/2023 1:13 PM, Arne Vajhøj wrote:
> On 7/18/2023 8:21 AM, Simon Clubley wrote:
>> On 2023-07-17, Dave Froble <davef@tsoft-inc.com> wrote:
>>> On 7/17/2023 9:29 AM, Arne Vajhøj wrote:
>>>
>>>> Simple is good - complex is bad.
>>>
>>> I'm a firm believer in KISS ...
>>
>> Then you should strongly prefer Unix over VMS... :-)
>
> I am not so sure about that.
>
> VMS is probably one of the smallest and leanest commercial
> OS'es today.
>
> It may be more a result of lack of investment for 20 years
> than a deliberate strategy. And we we miss a lot of things.
> But still small code base and small API.
>
> I am pretty sure that if VMS kernel had most Macro-32 and
> Bliss code rewritten to C, then VMS kernel would be
> smaller than just systemd. :-)
>
> Arne

I have to wonder why you think re-writing in C would be "smaller" (whatever that
is) than what's there today?

--
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 7/18/2023 1:55 PM, Simon Clubley wrote:
> On 2023-07-18, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 7/18/2023 1:31 PM, Simon Clubley wrote:
>>> On 2023-07-18, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>> On 7/18/2023 8:21 AM, Simon Clubley wrote:
>>>>> On 2023-07-17, Dave Froble <davef@tsoft-inc.com> wrote:
>>>>>> On 7/17/2023 9:29 AM, Arne Vajhøj wrote:
>>>>>>
>>>>>>> Simple is good - complex is bad.
>>>>>>
>>>>>> I'm a firm believer in KISS ...
>>>>>
>>>>> Then you should strongly prefer Unix over VMS... :-)
>>>>
>>>> I am not so sure about that.
>>>>
>>>> VMS is probably one of the smallest and leanest commercial
>>>> OS'es today.
>>>>
>>>> It may be more a result of lack of investment for 20 years
>>>> than a deliberate strategy. And we we miss a lot of things.
>>>> But still small code base and small API.
>>>
>>> How does that API compare to the APIs available on Unix (especially
>>> Linux) when you want to write an application (especially one with
>>> modern requirements) ?
>>>
>>> VMS had a world-leading API 20-30 years ago, but things (and expectations)
>>> have moved on since then.
>>
>> ????
>>
>> The third letter in KISS stands for simple not for feature-rich.
>>
>
> I know that Arne, and that is _exactly_ my point.
>
>> Linux as of today is definitely feature rich but it is not
>> simple.
>>
>
> It's a hell of a lot simpler to implement an application on Linux
> than it is to implement that application on VMS.
>
> Linux gives you functionality that is expected these days, but is
> missing from VMS. That's what I am primarily referring to above.
>
> For one example, I refer you to Stephen's often posted diatribe about
> the effort involved in writing a secure network application on VMS
> versus doing the same thing on Linux.
>
> Simon.
>

First, define reasonably well "secure network application".

--
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 7/18/2023 8:34 PM, Dave Froble wrote:
> On 7/18/2023 1:13 PM, Arne Vajhøj wrote:
>> I am pretty sure that if VMS kernel had most Macro-32 and
>> Bliss code rewritten to C, then VMS kernel would be
>> smaller than just systemd. :-)
>
> I have to wonder why you think re-writing in C would be "smaller"
> (whatever that is) than what's there today?

Same functionality implemented in different languages
result in a different number of lines of code.

Usually measured in LoC/FP.

C is fewer lines than Macro-32.

I am not sure that Bliss to C will really reduce LoC that much - it
was just bundled in with Macro-32.

VMS Basic is fewer lines than C. :-)

Usually it is rather irrelevant, but when comparing complexity
of two code bases written in different languages it can be
relevant.

Arne