On Sat, 2024-05-04 at 02:11 +0000, Lawrence D'Oliveiro wrote:
> > Oracle gets money that would otherwise likely go to Red Hat ...
>
> Interesting that they won’t offer their own ZFS next-generation
> filesystem product with it, preferring to bundle btrfs instead. Vote
> of confidence in your own product over rivals, much?

My experience with btrfs was awful. It's fortunate I only tested it and
took backups, and it kept losing data. Turned to ZFS and it has been
rock solid. Ten years.
--
Tactical Nuclear Kittens

On 5/3/2024 9:04 PM, Dan Cross wrote:
> In article <v1366u$lf87$1@dont-email.me>,
> Dave Froble <davef@tsoft-inc.com> wrote:
>> :-)
>>
>> The following is some snippets from what was basically a research program, and I
>> consider commenting such should be rather terse. For production programs I'd
>> want a lot more.

Do consider the above ...

> I hope you won't mind some feedback?

No problem. But some background. I came from an environment where strict
programming practices were in effect. Certain things, such as the header of a
program file, had a strict format to follow, and much of the text came from an
IDE code generator. That allowed any support person to know where to look for
information, and what to look for.

> Overall, there's a concept of, "too much of a good thing."
>
>> First, declare the purpose. Shouldn't this always be done?
>
> Yes, but see below.
>
>> !********************************************************************
>> !
>
> What does the line of asterisks buy you?

Strict formatting in every program. Important information was always highlighted.

>
>> ! Program: TCP_PEEK.BAS
>
> Why do you need this? Is it not in a file that is already
> named, "TCP_PEEK.BAS"? What do you get by repeating it in the
> file itself?

Doesn't hurt.

>> ! Function: Test Using TCP/IP Sockets as a Listener
>> ! Version: 1.00
>> ! Created: 01-Dec-2011
>> ! Author(s): DFE
>
> Why the elaborate formatting of this front matter? What does
> some of it even mean? How did you decide that this was version
> 1.00, for example? (Something like semver is much more useful
> than an arbitrary major.minor here.) Is the creation date
> useful versus, say, the last modification date?

For some, the first iteration of a program is version 1. I guess other
standards could be used.

Both dates can be useful.

> Moreover, where do you record the history of the module?
> Knowing how code has evolved over time can be very useful.

I didn't show that. As I wrote, some snippets from a program, not the entire
program.

> Frankly, all of this is metadata, which is better captured in a
> revision control system than in comments at the top of a file,
> which can easily get out of date over time.
>
>> !
>> ! Purpose/description:
>
> Well, which is it?

Now, that's a bit too "picky" ...

>> !
>> ! This program will set up TCP/IP sockets to allow
>> ! itself to listen for connection requests. When
>> ! a connection request is received, this program
>> ! will accept the connection, and then attempt to
>> ! PEEK the message, ie; read it but leave it available
>> ! to be re-read.
>
> This is good, but honestly, kind of all you need at the top of
> the file.
>
>> When using custom defined structures, it might be nice to know what they will be
>> used for.
>>
>> !**************************************************
>> ! Declare Variables of User Defined Structures
>> !**************************************************
>>
>> DECLARE IOSB_STRUCT IOSB, ! I/O status blk &
>> ITEMLIST_2 SERVER.ITEMLST, ! Server item list &
>> ITEMLIST_2 SOCKOPT.ITEMLST, ! Socket options list &
>> ITEMLIST_2 REUSEADR.ITEMLST, ! Reuse adr list &
>> ITEMLIST_3 CLIENT.ITEMLST, ! Client item list &
>> SOCKET_OPTIONS LISTEN.OPTN, ! Socket options &
>> SOCK_ADDR CLIENT.ADR, ! Client IP adr/port &
>> SOCK_ADDR SERVER.ADR, ! Server IP adr/port &
>> BUFF CLIENT.NAME, ! Client name buffer &
>> BUFF SERVER.NAME, ! Server name buffer &
>> IP_ADR IP, ! Ip address &
>> BUFF MSG ! Message buffer
>
> I don't think that these comments are useful at all, with the
> possible exception of the one on IOSB. These comments just
> parrot the code. If I saw, "SOCKOPT.ITEMLIST" how is it not
> obvious that that is a, "Socket options list"? Note also that
> the comment omits the fact that it's an item list, which is a
> specific thing, rather than just a generic list. Half of the
> item lists are annotated as item lists in the comments, but
> the other half are not.
>
>> I consider the following rather terse. Either the programmer knows how to use
>> system services, or perhaps remedial training is called for.
>>
>> !**************************************************
>> ! Assign channels to 'TCPIP$DEVICE:'
>> !**************************************************
>>
>> Dev$ = "TCPIP$DEVICE:"
>>
>> Stat% = SYS$ASSIGN( Dev$ , ListenCh% , , )
>> If ( Stat% And SS$_NORMAL ) = 0%
>> Then E$ = FnVMSerr$( Stat% )
>> Print #KB%, "Unable to assign listener channel - "; E$
>> GoTo 4900
>> End If
>>
>> Print #KB%, "Internal VMS channel for listener socket:"; ListenCh%
>>
>> Stat% = SYS$ASSIGN( Dev$ , ClientCh% , , )
>> If ( Stat% And SS$_NORMAL ) = 0%
>> Then E$ = FnVMSerr$( Stat% )
>> Print #KB%, "Unable to assign client channel - "; E$
>> GoTo 4900
>> End If
>
> It's also rather repetitive. It'd be better to wrap assignment
> in some kind of helper function, IMHO. Without knowing more
> about VMS BASIC, however, it's difficult to tell whether one
> could do much better.
>
>> However, when details might be helpful, there is usually never too much.
>>
>> !**************************************************
>> ! Create Listener socket
>> ! Bind server's IP address and port # to listener
>> ! socket, set socket as a passive socket
>
> I'm not sure this comment is accurate: it appears that most of
> what this code is doing until the $QIOW is setting up data for
> the $QIOW. Something like this may be more useful:
>
> ! Initialize IOSB data for listener socket creation,
> ! then create the socket and bind it to the server's
> ! IP address with the given port number.
>
>> ! Note: we used to do this in 2 calls, but can be combined
>
> Grammar: "but they were combined." Again, we see how missing
> the history can lead to questions: why were they combined, and
> when? Is that better somehow, other than the general principle
> of doing less work?
>
>> !**************************************************
>>
>> LISTEN.OPTN::PROTOCOL% = TCPIP$C_TCP ! Listener socket optn
>> LISTEN.OPTN::TYP$ = Chr$(TCPIP$C_STREAM)
>> LISTEN.OPTN::AF$ = Chr$(TCPIP$C_AF_INET)
>>
>> SOCKOPT.ITEMLST::LEN% = 8% ! Socket options buffer
>> SOCKOPT.ITEMLST::TYP% = TCPIP$C_SOCKOPT
>> SOCKOPT.ITEMLST::ADR% = Loc(REUSEADR.ITEMLST::Len%)
>>
>> REUSEADR.ITEMLST::LEN% = 4% ! Reuse adr (port #)
>> REUSEADR.ITEMLST::TYP% = TCPIP$C_REUSEADDR
>> REUSEADR.ITEMLST::ADR% = Loc(ReuseAdrVal%)
>>
>> ReuseAdrVal% = 1% ! Set to 'True'
>>
>> SERVER.ITEMLST::LEN% = 16% ! Server item list
>> SERVER.ITEMLST::TYP% = TCPIP$C_SOCK_NAME
>> SERVER.ITEMLST::ADR% = Loc(SERVER.ADR::Fam%)
>>
>> SERVER.ADR::Fam% = TCPIP$C_AF_INET ! Server Ip adr/port
>> SERVER.ADR::PORT% = SWAP%(ServerPort%)
>> SERVER.ADR::IP.ADR% = TCPIP$C_INADDR_ANY
>> SERVER.ADR::ZERO1% = 0%
>> SERVER.ADR::ZERO2% = 0%
>>
>> BACKLOG% = 1%
>>
>> Stat% = SYS$QIOW( , ! Event flag &
>> ListenCh% By Value, ! VMS channel &
>> IO$_SETCHAR By Value, ! Operation &
>> IOSB::Stat%, ! I/O status block &
>> , ! AST routine &
>> , ! AST parameter &
>> LISTEN.OPTN::Protocol%, ! P1 &
>> , ! P2 &
>> SERVER.ITEMLST::Len%, ! P3 - local socket nam
>> e &
>> BACKLOG% By Value, ! P4 - connection backl
>> og &
>> SOCKOPT.ITEMLST::Len%, ! P5 - socket options &
>> ) ! P6
>>
>> If ( Stat% And SS$_NORMAL ) = 0%
>> Then E$ = FnVMSerr$( Stat% )
>> Print #KB%, "Unable to queue create and bind listener socket - "
>> ; E$
>> GoTo 4900
>> End If
>>
>> If ( IOSB::Stat% And SS$_NORMAL ) = 0%
>> Then Stat% = IOSB::Stat%
>> E$ = FnVMSerr$( Stat% )
>> Print #KB%, "Unable to create and bind listener socket - "; E$
>> GoTo 4900
>> End If
>>
>> My opinion is, the above is essential, without it, there would be much studying
>> of code, wondering what is being referenced, and such. I always use one line
>> for each argument in a QIO and such, which makes it very clear what is
>> happening. Without that, even the best will still have some "fun" reading the
>> code to figure out what is happening.
>
> I agree that well-commented code is useful.
>
> - Dan C.
>

On 5/3/2024 10:23 PM, Dan Cross wrote:

>> So Clean Code does not suggest that comments should be
>> avoided. It just say that if well written code can make
>> a comment unnecessary then it is better.
>
> That's literally the definition of what "should be avoided"
> means in this context. Clean Code is a poorly written book full
> of bad advice; it's really best avoided.

I've always believed that:

Those who can, do ...
Those who can't, teach ...
Those who can't teach, write ...

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

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>On Fri, 3 May 2024 11:41:47 -0400, Arne Vajhøj wrote:
>
>> Useful comments are comments that explain why the code
>> does what it does.
>
>Absolutely agree. The key word is “why” the code does what it does, not
>“what” it does (which is trivially obvious from the code itself).

groovy:: ; do that groovy thing
.call_entry max_args=33,home_args=true,preserve=<r3,r5>
movl (ap),r3 ; boogity boogity boogity
moval 4(ap),r5 ; yeah, you got it baby
ret ; go back and do it again
.psect idata,wrt,noexe,quad
.align quad
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On Sun, 28 Apr 2024 17:03:19 +1200, David Goodwin wrote:

> In article <v0kbcs$q4lf$4@dont-email.me>, ldo@nz.invalid says...
>>
>> You were the one who claimed it was “still supported”, not me. It is up
>> to you to prove that point, if you can.
>
> Microsoft says its still supported. I don't see any reason to claim or
> believe otherwise without proof.

Nope, all you’ve done is continue to insist that Microsoft’s PR weasel
words still mean something, contrary to past experience.

> There are APIs to make something else work - the same APIs the Win32
> Environment Subsystem uses. The main roadblock is almost certainly the
> fact the GUI that ships with the system is good enough and modifying it
> is far easier than starting from scratch.

That is absolutely laughable to claim it is “good enough”, given the long-
standing complaints about the inflexibility of the Windows GUI.

>> Mount points as an alternative to drive letters--only work with NTFS. I
>> think also system booting only works with NTFS.
>
> This is primarily because NTFS is the only filesystem that ships with
> windows that has the required features.

Like I said, in Linux these are not “features” specific to the filesystem,
they are implemented in the VFS layer. So they are able to work across
different filesystems--even ones from the Windows world, where Windows
itself is unable to support those features.

> Mounted folders are implemented using reparse points - the same feature
> used for hard links, symbolic links, junctions and other such things. I
> think these are stored as extended attributes or similar which are not
> supported by FAT.

Why do you need on-disk attributes to store information about mount
points?

>> Those are all for network security, not local security. I?m talking
>> about things like SELinux and AppArmor. And containers.
>
> As far as I can see most of what SELinux adds has been in Windows NT
> since version 3.1.

You realize SELinux was created by the NSA? It offers military-strength
role-based mandatory access control.

Maybe Windows has something equivalent to one of the simpler LSMs, like
maybe AppArmor. Not SELinux.

>> How wonderful. So they (partially) reinvented GUI login display
>> managers that *nix systems have had since the 1990s. Have they figured
>> out how to add that little menu that offers you a choice of GUI
>> environment to run, as well?
>
> They could put that menu there.

Nobody could, apart from Microsoft. The GUI is not easily replaceable,
remember.

>>> It also goes beyond what binfmt does.
>>
>> Does it indeed? Weren?t you making apologies about its limitations, due
>> to its being 30 years old, elsewhere?
>
> No, I was not. And I think I've described NTs architecture more than
> enough at this point for you to know that binfmt is not the same concept
> as NTs Environment Subsystems.

Ah, first you were claiming these “go beyond” binfmt, now you are trying
to backpedal by saying they are somehow not comparable at all?

Want to change your story yet again?

>>> I ported C-Kermit for Windows in about a day IIRC.
>>
>> Not sure why that?s relevant.
>
> You were implying the transition from 32bit to 64bit is not easy. From
> my experience this is not the case. I suspect you are just making
> assumptions here.

No, I was looking for some relevance to the 32-bit-to-64-bit transition,
and your story had nothing about that.

>> All those ports are gone. All the non-x86 ones, except the ARM one,
>> which continues to struggle.
>
> Yes, because all of those platforms are gone.

No, ARM and POWER and MIPS are all still very much here and continuing to
be made and sold. And like I said, even with the massive popularity of
ARM, Microsoft still can’t get Windows running properly on it.

> The fact that [Windows NT] has been ported to so many architectures
> clearly demonstrates that it is fairly portable.

The fact that every single one of those ports ran in into trouble clearly
demonstrates that that “portability” was more of a PR claim than
practical.

>>> Drive letters are a feature of the Win32 environment subsystem - the
>>> Win32 namespace. This is implemented on top of the NT namespace which
>>> is provided by the Object Manager.
>>
>> Which is somehow specifically tied into NTFS. Try this: create and
>> mount a FAT volume, mount it somewhere other than a drive letter,
>> create a directory within it, and mount some other non-NTFS volume on
>> that directory.
>
> It would seem it isn't necessarily tied to NTFS but rather requires
> certain filesystem features FAT doesn't have.

Like I said, on Linux this has nothing to do with filesystem-specific
features. It is all handled within the VFS layer.

>> “Compatibility”. Go on, say it: WSL1 could not offer good enough
>> compatibility with Linux.
>
> Not good enough for what?

Not good enough to do the things Linux users/developers expect from their
systems as a matter of course.

Not good enough to pass for Linux.

In article <fd016548559cb3c8fca2ab4f538153127cfe42c9.camel@munted.eu>,
alex.buell@munted.eu (Single Stage to Orbit) wrote:

> My experience with btrfs was awful. It's fortunate I only tested it
> and took backups, and it kept losing data. Turned to ZFS and it has
been
> rock solid. Ten years.

I had significant trouble with the version in RHEL7/CentOS7, where it was
the default root filesystem. It's still the default on SUSE Enterprise.
My local Linux expert tells me that it's been fixed now, although another
friend who spent some years working for SUSE disagrees.

I had Android devices connected to a CentOS 7.9 machine, which did
Android builds, and staged data to be pushed onto the devices. When the
data set to be pushed was large (more than a few GB), btrfs would often
decide that it had run out of space, with more than 70% of a 1TB volume
still free according to df. An fsck would fix the problem, but it would
reoccur a few days or weeks later.

My conclusion was that since I was moving to a new Rocky 8.9 machine
before CentOS 7.9 ran out of support, I'd have my staging area as ext4,
please, and that has been entirely satisfactory. I was quite happy that
it was removed from RHEL/Rocky/Alma 8.x; even if it is fixed now, it has
a bad reputation.

John

In article <v145fm$vrsv$3@dont-email.me>, ldo@nz.invalid (Lawrence
D'Oliveiro) wrote:
> On Fri, 3 May 2024 18:42 +0100 (BST), John Dallman wrote:
> > Oracle gets money that would otherwise likely go to Red Hat ...
> Interesting that they won't offer their own ZFS next-generation
> filesystem product with it, preferring to bundle btrfs instead.
> Vote of confidence in your own product over rivals, much?

I suspect that, to Oracle, the difference between the proprietary ZFS in
Solaris and the OpenZFS available for Linux is crucial. They are still
trying to sell Solaris and hardware for it, although I doubt they are
getting many new customers.

John

On Sun, 2024-05-05 at 18:04 +0100, John Dallman wrote:
> > My experience with btrfs was awful. It's fortunate I only tested it
> > and took backups, and it kept losing data. Turned to ZFS and it has
> been rock solid. Ten years.
>
> I had significant trouble with the version in RHEL7/CentOS7, where it
> was the default root filesystem. It's still the default on SUSE
> Enterprise. My local Linux expert tells me that it's been fixed now,
> although anotherfriend who spent some years working for SUSE
> disagrees.
>
> I had Android devices connected to a CentOS 7.9 machine, which did
> Android builds, and staged data to be pushed onto the devices. When
> the data set to be pushed was large (more than a few GB), btrfs would
> often decide that it had run out of space, with more than 70% of a
> 1TB volume still free according to df. An fsck would fix the problem,
> but it would reoccur a few days or weeks later.
>
> My conclusion was that since I was moving to a new Rocky 8.9 machine
> before CentOS 7.9 ran out of support, I'd have my staging area as
> ext4, please, and that has been entirely satisfactory. I was quite
> happy that it was removed from RHEL/Rocky/Alma 8.x; even if it is
> fixed now, it has a bad reputation.

btrfs may be better now, but I too find ext4 serves my purposes well
enough for day to day use, and keep ZFS for backup/archival purposes.
Life's too short.
--
Tactical Nuclear Kittens

On Sun, 5 May 2024 18:04 +0100 (BST), John Dallman wrote:

> I had significant trouble with the [btrfs] version in RHEL7/CentOS7,
> where it was the default root filesystem.

I wonder if Oracle customers have trouble with it too?

In article <v1487o$10cnq$1@dont-email.me>,
Dave Froble <davef@tsoft-inc.com> wrote:
>On 5/3/2024 9:04 PM, Dan Cross wrote:
>> In article <v1366u$lf87$1@dont-email.me>,
>> Dave Froble <davef@tsoft-inc.com> wrote:
>>> :-)
>>>
>>> The following is some snippets from what was basically a research program, and I
>>> consider commenting such should be rather terse. For production programs I'd
>>> want a lot more.
>
>Do consider the above ...

Sure. But I don't consider most of these "terse", though I do
wish that they had less boilerplate and more useful content.
That is, terse is fine if it's accompanied by high information
density. Verbose is strictly worse with lower information
density.

>> I hope you won't mind some feedback?
>
>No problem. But some background. I came from an environment where strict
>programming practices were in effect. Certain things, such as the header of a
>program file, had a strict format to follow, and much of the text came from an
>IDE code generator. That allowed any support person to know where to look for
>information, and what to look for.
>
> [snip]
>>> !********************************************************************
>>> !
>>
>> What does the line of asterisks buy you?
>
>Strict formatting in every program. Important information was always highlighted.

That's fair; I confess I have complex feelings around code style
guides that mandate things like that. On the one hand, I don't
think that this kind of visual artistry really adds all that
much, and can often be distracting; on the other, I worked in a
very large codebase with a rigid style guide that I disliked,
but which was a major factor in allowing that to scale to tens
of thousands of engineers working on ~2 BLOC (yes, "B") of code
simultaneously, all of which was mutually intelligible.

>>> ! Program: TCP_PEEK.BAS
>>
>> Why do you need this? Is it not in a file that is already
>> named, "TCP_PEEK.BAS"? What do you get by repeating it in the
>> file itself?
>
>Doesn't hurt.

....until you rename the file! Or copy and paste a part into a
different file, or similar maintenance activities. Then it adds
churn, unnecessary diff size, and cognitive overhead.

>>> ! Function: Test Using TCP/IP Sockets as a Listener
>>> ! Version: 1.00
>>> ! Created: 01-Dec-2011
>>> ! Author(s): DFE
>>
>> Why the elaborate formatting of this front matter? What does
>> some of it even mean? How did you decide that this was version
>> 1.00, for example? (Something like semver is much more useful
>> than an arbitrary major.minor here.) Is the creation date
>> useful versus, say, the last modification date?
>
>For some, the first iteration of a program is version 1. I guess other
>standards could be used.

It's a bit of an aside, but I do recommend checking out semver;
it's genuinely useful. The gist of it from https://semver.org/:

|Given a version number MAJOR.MINOR.PATCH, increment the:
| |MAJOR version when you make incompatible API changes
|MINOR version when you add functionality in a backward compatible manner
|PATCH version when you make backward compatible bug fixes

>Both dates can be useful.

I'd argue that that's really better tracked in a revision
control system.

>> Moreover, where do you record the history of the module?
>> Knowing how code has evolved over time can be very useful.
>
>I didn't show that. As I wrote, some snippets from a program, not the entire
>program.
>
>> Frankly, all of this is metadata, which is better captured in a
>> revision control system than in comments at the top of a file,
>> which can easily get out of date over time.
>>
>>> !
>>> ! Purpose/description:
>>
>> Well, which is it?
>
>Now, that's a bit too "picky" ...

Maybe. But if one's going to offer up an example that shows the
kids how it oughta be done, don't be surprised if you get a
little bit of pushback. ;-)

I stand by the rest of my comments, quoted below. Honestly,
this code wouldn't pass review anywhere I've worked recently.

- Dan C.

Old message follows:
> !
> ! This program will set up TCP/IP sockets to allow
> ! itself to listen for connection requests. When
> ! a connection request is received, this program
> ! will accept the connection, and then attempt to
> ! PEEK the message, ie; read it but leave it available
> ! to be re-read.

This is good, but honestly, kind of all you need at the top of
the file.

> When using custom defined structures, it might be nice to know what they will be
> used for.
>
> !**************************************************
> ! Declare Variables of User Defined Structures
> !**************************************************
>
> DECLARE IOSB_STRUCT IOSB, ! I/O status blk &
> ITEMLIST_2 SERVER.ITEMLST, ! Server item list &
> ITEMLIST_2 SOCKOPT.ITEMLST, ! Socket options list &
> ITEMLIST_2 REUSEADR.ITEMLST, ! Reuse adr list &
> ITEMLIST_3 CLIENT.ITEMLST, ! Client item list &
> SOCKET_OPTIONS LISTEN.OPTN, ! Socket options &
> SOCK_ADDR CLIENT.ADR, ! Client IP adr/port &
> SOCK_ADDR SERVER.ADR, ! Server IP adr/port &
> BUFF CLIENT.NAME, ! Client name buffer &
> BUFF SERVER.NAME, ! Server name buffer &
> IP_ADR IP, ! Ip address &
> BUFF MSG ! Message buffer

I don't think that these comments are useful at all, with the
possible exception of the one on IOSB. These comments just
parrot the code. If I saw, "SOCKOPT.ITEMLIST" how is it not
obvious that that is a, "Socket options list"? Note also that
the comment omits the fact that it's an item list, which is a
specific thing, rather than just a generic list. Half of the
item lists are annotated as item lists in the comments, but
the other half are not.

> I consider the following rather terse. Either the programmer knows how to use
> system services, or perhaps remedial training is called for.
>
> !**************************************************
> ! Assign channels to 'TCPIP$DEVICE:'
> !**************************************************
>
> Dev$ = "TCPIP$DEVICE:"
>
> Stat% = SYS$ASSIGN( Dev$ , ListenCh% , , )
> If ( Stat% And SS$_NORMAL ) = 0%
> Then E$ = FnVMSerr$( Stat% )
> Print #KB%, "Unable to assign listener channel - "; E$
> GoTo 4900
> End If
>
> Print #KB%, "Internal VMS channel for listener socket:"; ListenCh%
>
> Stat% = SYS$ASSIGN( Dev$ , ClientCh% , , )
> If ( Stat% And SS$_NORMAL ) = 0%
> Then E$ = FnVMSerr$( Stat% )
> Print #KB%, "Unable to assign client channel - "; E$
> GoTo 4900
> End If

It's also rather repetitive. It'd be better to wrap assignment
in some kind of helper function, IMHO. Without knowing more
about VMS BASIC, however, it's difficult to tell whether one
could do much better.

> However, when details might be helpful, there is usually never too much.
>
> !**************************************************
> ! Create Listener socket
> ! Bind server's IP address and port # to listener
> ! socket, set socket as a passive socket

I'm not sure this comment is accurate: it appears that most of
what this code is doing until the $QIOW is setting up data for
the $QIOW. Something like this may be more useful:

! Initialize IOSB data for listener socket creation,
! then create the socket and bind it to the server's
! IP address with the given port number.

> ! Note: we used to do this in 2 calls, but can be combined

Grammar: "but they were combined." Again, we see how missing
the history can lead to questions: why were they combined, and
when? Is that better somehow, other than the general principle
of doing less work?

In article <memo.20240505180415.16164B@jgd.cix.co.uk>,
John Dallman <jgd@cix.co.uk> wrote:
>In article <fd016548559cb3c8fca2ab4f538153127cfe42c9.camel@munted.eu>,
>alex.buell@munted.eu (Single Stage to Orbit) wrote:
>
>> My experience with btrfs was awful. It's fortunate I only tested it
>> and took backups, and it kept losing data. Turned to ZFS and it has
>been
>> rock solid. Ten years.
>
>I had significant trouble with the version in RHEL7/CentOS7, where it was
>the default root filesystem. It's still the default on SUSE Enterprise.
>My local Linux expert tells me that it's been fixed now, although another
>friend who spent some years working for SUSE disagrees.
>
>I had Android devices connected to a CentOS 7.9 machine, which did
>Android builds, and staged data to be pushed onto the devices. When the
>data set to be pushed was large (more than a few GB), btrfs would often
>decide that it had run out of space, with more than 70% of a 1TB volume
>still free according to df. An fsck would fix the problem, but it would
>reoccur a few days or weeks later.
>
>My conclusion was that since I was moving to a new Rocky 8.9 machine
>before CentOS 7.9 ran out of support, I'd have my staging area as ext4,
>please, and that has been entirely satisfactory. I was quite happy that
>it was removed from RHEL/Rocky/Alma 8.x; even if it is fixed now, it has
>a bad reputation.

People who actually know things about filesystems tend to avoid
BtrFS. OpenZFS on Linux is generally preferred. Note that the
hyperscalers often use ext4.

- Dan C.

In article <v16nsc$1gbho$2@dont-email.me>, ldo@nz.invalid says...
>
> On Sun, 28 Apr 2024 17:03:19 +1200, David Goodwin wrote:
>
> > In article <v0kbcs$q4lf$4@dont-email.me>, ldo@nz.invalid says...
> >>
> >> You were the one who claimed it was ?still supported?, not me. It is up
> >> to you to prove that point, if you can.
> >
> > Microsoft says its still supported. I don't see any reason to claim or
> > believe otherwise without proof.
>
> Nope, all you?ve done is continue to insist that Microsoft?s PR weasel
> words still mean something, contrary to past experience.

Can you point to some recent examples where Microsoft has ended support
earlier than they claimed they would? Or failed to patch critical
vulnerabilities for products that were still in support?

I can remember them *extending* the support period for old products on
occasion. And they have on occasion provided patches for particularly
serious issues in products that were out of support.

> > There are APIs to make something else work - the same APIs the Win32
> > Environment Subsystem uses. The main roadblock is almost certainly the
> > fact the GUI that ships with the system is good enough and modifying it
> > is far easier than starting from scratch.
>
> That is absolutely laughable to claim it is ?good enough?, given the long-
> standing complaints about the inflexibility of the Windows GUI.

I've no doubt some people don't like the Windows GUI. Some people don't
like the Mac GUI either. Clearly not enough people have big enough
issues to bother doing something about it though.

The only part you can't really "easily" replace (AFAIK) is the window
manager. I've never really desired a different window manager on Windows
so don't care it can't be replaced - on Linux I've almost always just
gone with whatever the default is too.

There are alternative shells but they've never been popular I guess
because most people think the default one is fine.

> >> Mount points as an alternative to drive letters--only work with NTFS. I
> >> think also system booting only works with NTFS.
> >
> > This is primarily because NTFS is the only filesystem that ships with
> > windows that has the required features.
>
> Like I said, in Linux these are not ?features? specific to the filesystem,
> they are implemented in the VFS layer. So they are able to work across
> different filesystems--even ones from the Windows world, where Windows
> itself is unable to support those features.
>
> > Mounted folders are implemented using reparse points - the same feature
> > used for hard links, symbolic links, junctions and other such things. I
> > think these are stored as extended attributes or similar which are not
> > supported by FAT.
>
> Why do you need on-disk attributes to store information about mount
> points?

Why does Unix need a text file to store information about mount points?
Because that's how it was designed. Windows NT and Unix are different
operating systems and so do some things differently. This is ok.

> >> Those are all for network security, not local security. I?m talking
> >> about things like SELinux and AppArmor. And containers.
> >
> > As far as I can see most of what SELinux adds has been in Windows NT
> > since version 3.1.
>
> You realize SELinux was created by the NSA? It offers military-strength
> role-based mandatory access control.
>
> Maybe Windows has something equivalent to one of the simpler LSMs, like
> maybe AppArmor. Not SELinux.
>
> >> How wonderful. So they (partially) reinvented GUI login display
> >> managers that *nix systems have had since the 1990s. Have they figured
> >> out how to add that little menu that offers you a choice of GUI
> >> environment to run, as well?
> >
> > They could put that menu there.
>
> Nobody could, apart from Microsoft. The GUI is not easily replaceable,
> remember.

The login screen is a DLL. You can replace it. Novell *did* replace it.
You can put whatever buttons you like on your replacement login screen.
Novell *did* put whatever buttons they liked on their login screen. This
is why it is a DLL and why Microsoft published the specifications for
the DLL - so that people could replace it if needed.

> >>> It also goes beyond what binfmt does.
> >>
> >> Does it indeed? Weren?t you making apologies about its limitations, due
> >> to its being 30 years old, elsewhere?
> >
> > No, I was not. And I think I've described NTs architecture more than
> > enough at this point for you to know that binfmt is not the same concept
> > as NTs Environment Subsystems.
>
> Ah, first you were claiming these ?go beyond? binfmt, now you are trying
> to backpedal by saying they are somehow not comparable at all?
>
> Want to change your story yet again?

Binfmt handles executable formats - it alone can't make Linux look like
Windows. It is not the same concept as Windows NTs Environment
Subsystems which are responsible for providing most of the userspace
environmnet.

If you take away binfmt, Linux still looks and works like Linux. If you
take away CSRSS, Windows NT is practically some other operating system.

I'm not really sure how much clearer I can make this. I think you are
being more than a little disingenous here.

> >>> I ported C-Kermit for Windows in about a day IIRC.
> >>
> >> Not sure why that?s relevant.
> >
> > You were implying the transition from 32bit to 64bit is not easy. From
> > my experience this is not the case. I suspect you are just making
> > assumptions here.
>
> No, I was looking for some relevance to the 32-bit-to-64-bit transition,
> and your story had nothing about that.
>
> >> All those ports are gone. All the non-x86 ones, except the ARM one,
> >> which continues to struggle.
> >
> > Yes, because all of those platforms are gone.
>
> No, ARM and POWER and MIPS are all still very much here and continuing to
> be made and sold. And like I said, even with the massive popularity of
> ARM, Microsoft still can?t get Windows running properly on it.

Been a long time since I've seen PowerPC or MIPS PCs on store shelves...

The PowerPC port ended when IBM stopped including ARC-compatible
firmware on new machines. The MIPS port ended when you could no longer
buy MIPS workstations with ARC firmware. Compatible hardware was
discontinued so the ports were discontinued.

Microsoft could have taken on supporting these platforms with whatever
random firmware they have like Linux does. But Microsoft is selling a
product here - if the number of sales to people who want to run Windows
rather than AIX on their brand new RS/6000 doesn't cover the costs its
not worth doing.

That doesn't mean it can't be done or that Windows NT isn't portable. It
just means it doesn't make business sense to do it.

Same goes for ARM - Windows runs on ARM devices built to run Windows.
For business reasons Microsoft doesn't spend money porting Windows to
any random ARM device thats designed and sold for some other purpose.

> > The fact that [Windows NT] has been ported to so many architectures
> > clearly demonstrates that it is fairly portable.
>
> The fact that every single one of those ports ran in into trouble clearly
> demonstrates that that ?portability? was more of a PR claim than
> practical.

None of them ran into technical problems. The ports exist and they work.
I have PowerPC and Alpha hardware here running Windows NT and it works
just fine. Only reason I don't have a MIPS is because they're extremely
rare. The operating system itself is indistinguishable from the regular
x86 version and all the included utilities work just the same. The
operating system is portable and its a bit absurd to try and claim
otherwise.

But the level of vendor support does make a difference. IBM put in only
minimal effort and abandoned it quickly. Few machines were sold and so
hardware and software vendors rarely built drivers and software for
PowerPC.

DEC put far more effort in and it shows. A lot more software and drivers
built for Alpha, plus their binary translation software (FX!32) works
very well for running regular x86 binaries. Its really a shame Compaq
killed the Win2k effort as Win2k RC2 works quite nicely on Alpha.

> >>> Drive letters are a feature of the Win32 environment subsystem - the
> >>> Win32 namespace. This is implemented on top of the NT namespace which
> >>> is provided by the Object Manager.
> >>
> >> Which is somehow specifically tied into NTFS. Try this: create and
> >> mount a FAT volume, mount it somewhere other than a drive letter,
> >> create a directory within it, and mount some other non-NTFS volume on
> >> that directory.
> >
> > It would seem it isn't necessarily tied to NTFS but rather requires
> > certain filesystem features FAT doesn't have.
>
> Like I said, on Linux this has nothing to do with filesystem-specific
> features. It is all handled within the VFS layer.

On 06/05/2024 06:24, Lawrence D'Oliveiro wrote:
> On Sun, 5 May 2024 18:04 +0100 (BST), John Dallman wrote:
>
>> I had significant trouble with the [btrfs] version in RHEL7/CentOS7,
>> where it was the default root filesystem.
>
> I wonder if Oracle customers have trouble with it too?
>
ZFS has been perfectly fine on the various Solaris systems I and $WORK
and $CUSTOMERS operate since the 6/6 update to Solaris 10. (Bloody
hell, that's nearly twenty bloody years! It should be bloody stable by
now, even after Oracle eviscer^reorganised things.)

I understand there were/are people who've had problems when they've
pushed it into edge territory - lots and lots and lots of vdevs in a
zpool, frex (Sun recommended a maximum of 9) - but people who Just Use
It(TM) seem to be fine.

I use XFS on my Linux boxes, but then I did work at SGI for a time. :-)

Cheers,
Gary B-)

On Mon, 6 May 2024 15:37:57 +1000, Gary R. Schmidt wrote:

> On 06/05/2024 06:24, Lawrence D'Oliveiro wrote:
>> On Sun, 5 May 2024 18:04 +0100 (BST), John Dallman wrote:
>>
>>> I had significant trouble with the [btrfs] version in RHEL7/CentOS7,
>>> where it was the default root filesystem.
>>
>> I wonder if Oracle customers have trouble with it too?
>>
> ZFS has been perfectly fine ...

But Oracle doesn’t offer that with its Linux. It offers btrfs instead.

In article <MPG.40a3022658647d279896e1@news.zx.net.nz>,
David Goodwin <david+usenet@zx.net.nz> wrote:
>In article <v16nsc$1gbho$2@dont-email.me>, ldo@nz.invalid says...
>>[snip]
>Why does Unix need a text file to store information about mount points?

Just a minor technical point, but it doesn't really _need_ to
per se. The kernel will traverse mount points just fine
regardless of whether the list of currently mounted filesystems
is in mtab or not. That file exists purely for the convenience
of userspace utilities.

Of course, that said, there's no system call to retrieve the set
of mounted filesystems. Maybe there should have been. Dunno.

>[snip]
>I'm still not entirely sure what the point of this discussion is. Is
>there some point you're trying to make here or are we just trying to
>find the differences between two operating systems?

This. The person you're responding to is not only disingenuous,
but I would argue a rather blatant crank. His MO seems to be to
make some specious observation and offer that as "proof" that a
conclusion he has chosen to draw is fact. He then argues it
over and over again, asserting the same things without building
any supporting basis for his claims. (The stuff on his web page
about mathematics is even worse.)

My suggestion is to just ignore him.

- Dan C.

In article <MPG.40a3022658647d279896e1@news.zx.net.nz>,
david+usenet@zx.net.nz (David Goodwin) wrote:

> In article <v16nsc$1gbho$2@dont-email.me>, ldo@nz.invalid says...

> > No, ARM and POWER and MIPS are all still very much here and
> > continuing to be made and sold. And like I said, even with the
> > massive popularity of ARM, Microsoft still can't get Windows
> > running properly on it.

Oh, it runs, reasonably well. Microsoft are a bit confused about what
they should be doing with it, but they are gradually working towards it
being an all-purpose platform. Qualcomm seem to have convinced them at
one point that the hardware should be all be Qualcomm proprietor
platforms, but they seem to be climbing out of that hole now.

> Been a long time since I've seen PowerPC or MIPS PCs on store
> shelves...
>
> The PowerPC port ended when IBM stopped including ARC-compatible
> firmware on new machines. The MIPS port ended when you could no
> longer buy MIPS workstations with ARC firmware. Compatible hardware
> was discontinued so the ports were discontinued.
>
> Microsoft could have taken on supporting these platforms with
> whatever random firmware they have like Linux does. But Microsoft
> is selling a product here - if the number of sales to people who
> want to run Windows rather than AIX on their brand new RS/6000
> doesn't cover the costs its not worth doing.
>
> That doesn't mean it can't be done or that Windows NT isn't
> portable. It just means it doesn't make business sense to do it.

My employer had an explanation for Windows NT platforms, back in the late
1990s:

x86 is the default. If you don't have good reason for wanting
a different platform, you want x86.

We supported it then, and still do to this day.

Alpha is the fastest. That's a good reason.

We supported it until about 2000, by which time it was no longer the
fastest and was being dropped by Compaq.

PowerPC is what you want if you're very keen on IBM and believe
their claims of integration with AIX and MacOS.

We never supported this. We looked at it, but there was no significant
customer demand and the hardware was very expensive.

MIPS was used to develop Windows NT but doesn't have a reason as
compelling as PowerPC.

We worked on a port. We hit the same problem as we had on MIPS/Ultrix and
Irix, which seems to go back to MIPS' original code generator from
RISC/os (not to be confused with RISC OS). We had to get it fixed
separately on all three platforms.

The compiler assumed that any C struct passed by value would have uniform
alignment requirements for all of its members. It simply pushed the
members onto the stack, ignoring any padding in the struct. It did not
pop the members into a buffer in the called function, it just used the
copy on the stack as the passed variable. If omitting padding had caused
any members to become misaligned, you got a SIGBUS as soon as you
accessed them.

About the time we'd got MS to fix the Windows version of this bug, it
became clear the Pentium Pro had destroyed any performance advantage MIPS
held over x86, and the customer abandoned MIPS and decided to build x86
workstations instead. They went bust a year or so later.

> Same goes for ARM - Windows runs on ARM devices built to run
> Windows. For business reasons Microsoft doesn't spend money porting
> Windows to any random ARM device thats designed and sold for some
> other purpose.

There is also a distinct shortage of ARM SoCs with high performance-per-
thread suitable for development machines. The good ones are made by Apple,
and Microsoft don't seem to want to support them.

> > The fact that every single one of those ports ran in into trouble
> > clearly demonstrates that that ?portability? was more of a PR
> > claim than practical.
>
> None of them ran into technical problems. The ports exist and they
> work. I have PowerPC and Alpha hardware here running Windows NT and
> it works just fine. Only reason I don't have a MIPS is because
> they're extremely rare. The operating system itself is
> indistinguishable from the regular x86 version and all the included
> utilities work just the same. The operating system is portable and
> its a bit absurd to try and claim otherwise.

Yup. I've used it on x86, x86-64, Alpha, Itanium and Aarch64. The
problems have been with hardware performance/availability and marketing,
not the OS.

Also, something Dave Cutler did while at Microsoft was very good for
everyone. When Intel had to admit that Itanium was not working out and
they needed to do a 64-bit x86, they initially wanted to use a different
instruction encoding from AMD, so that binaries could not be compatible
with both Intel and AMD. Dave Cutler's response was "You can do that if
you want, but you won't have Windows for it." Intel had to climb down.

> Would be interested to see Linux using fat32 as the root
> filesystem. Last I checked it wasn't possible due to missing
> features in that filesystem.

I've done something similar to that on Android, on devices that didn't
have enough built-in storage so I had to use large micro-SD cards for
test data. You really do not want to see what FAT32 does to the
performance of directory seeks in directories with lots of files.

John

On Mon, 6 May 2024 16:28:12 +1200, David Goodwin wrote:

> Why does Unix need a text file to store information about mount points?

Linux does not need a text file to store information about mount points.

> Been a long time since I've seen PowerPC or MIPS PCs on store shelves...

They are used in computers, just because the stores you frequent don’t
carry them, is merely a reflection on the kinds of stores you frequent.

> The PowerPC port ended when IBM stopped including ARC-compatible
> firmware on new machines.

It didn’t stop Linux from continuing to support POWER, though.

> The MIPS port ended when you could no longer
> buy MIPS workstations with ARC firmware.

So Windows needed some special handholding to run on non-x86
architectures, where Linux was able to operate without such training
wheels.

> Microsoft could have taken on supporting these platforms with whatever
> random firmware they have like Linux does. But Microsoft is selling a
> product here ...

Funny, isn’t it. The Linux kernel project has maybe 1000 regular
contributors. Microsoft has not one, but close to two orders of magnitude
greater developer talent on its payroll. Yet those Linux developers are
managing to support about *two dozen* major processor architectures, while
Microsoft struggles to get beyond one.

> None of them ran into technical problems.

I didn’t say they did. But they were just too expensive and difficult to
maintain. Windows simply wasn’t designed to make this sort of thing easy.

> Would be interested to see Linux using fat32 as the root filesystem.
> Last I checked it wasn't possible due to missing features in that
> filesystem.

Linux will boot off any filesystem that GRUB will read.
<https://askubuntu.com/questions/938076/install-boot-on-fat32-partition>

On 06/05/2024 15:51, Lawrence D'Oliveiro wrote:
> On Mon, 6 May 2024 15:37:57 +1000, Gary R. Schmidt wrote:
>
>> On 06/05/2024 06:24, Lawrence D'Oliveiro wrote:
>>> On Sun, 5 May 2024 18:04 +0100 (BST), John Dallman wrote:
>>>
>>>> I had significant trouble with the [btrfs] version in RHEL7/CentOS7,
>>>> where it was the default root filesystem.
>>>
>>> I wonder if Oracle customers have trouble with it too?
>>>
>> ZFS has been perfectly fine ...
>
> But Oracle doesn’t offer that with its Linux. It offers btrfs instead.

I don't know of anyone who runs btrfs on Oracle Linux, they all run XFS.
(Maybe because they're all ex-SGI, too. ;-) )

Cheers,
Gary B-)

On Tue, 2024-05-07 at 07:07 +0000, Lawrence D'Oliveiro wrote:
> > Why does Unix need a text file to store information about mount
> > points?
>
> Linux does not need a text file to store information about mount
> points.

It's a text file, actually. /etc/mtab.
--
Tactical Nuclear Kittens

On 5/6/2024 1:51 AM, Lawrence D'Oliveiro wrote:
> On Mon, 6 May 2024 15:37:57 +1000, Gary R. Schmidt wrote:
>> On 06/05/2024 06:24, Lawrence D'Oliveiro wrote:
>>> On Sun, 5 May 2024 18:04 +0100 (BST), John Dallman wrote:
>>>> I had significant trouble with the [btrfs] version in RHEL7/CentOS7,
>>>> where it was the default root filesystem.
>>>
>>> I wonder if Oracle customers have trouble with it too?
>>>
>> ZFS has been perfectly fine ...
>
> But Oracle doesn’t offer that with its Linux. It offers btrfs instead.

Oracle Linux is a RHEL clone, so it offers what Redhat wants to
put in RHEL.

:-)

Arne

On 5/4/24 07:57, Single Stage to Orbit wrote:
> On Sat, 2024-05-04 at 02:11 +0000, Lawrence D'Oliveiro wrote:
>>> Oracle gets money that would otherwise likely go to Red Hat ...
>>
>> Interesting that they won’t offer their own ZFS next-generation
>> filesystem product with it, preferring to bundle btrfs instead. Vote
>> of confidence in your own product over rivals, much?
>
> My experience with btrfs was awful. It's fortunate I only tested it and
> took backups, and it kept losing data. Turned to ZFS and it has been
> rock solid. Ten years.

Yes, ZFS here since the very early versions of Solaris 10. Absolutely
rock solid and has never lost any data here, nor had a situation
that was not recoverable. Why use anything else ?.

FreeBSD was the only alternative os to offer their own clean room
zfs many years ago, but they moved to OpenZFS. Again, rock solid
and would not choose any other fs, other than for quick hacks, or
testing.

Back on topic, who remembers the dec advfs for Tru64 ?. Never
actually used it, but what were it's advantages / usp ?...

On 5/7/2024 8:45 AM, chrisq wrote:
> Back on topic, who remembers the dec advfs  for Tru64 ?. Never
> actually used it, but what were it's advantages / usp ?...

SpiraLog may be even more on topic ...

:-)

Arne

On 5/4/24 03:08, Lawrence D'Oliveiro wrote:
> On Fri, 3 May 2024 13:05:18 +0100, chrisq wrote:
>
>> On 4/30/24 23:56, Lawrence D'Oliveiro wrote:
>>
>>> On Sun, 28 Apr 2024 12:22:03 +0100, chrisq wrote:
>>>
>>>> The way that so much of the unix infrastructure has been replaced,
>>>> coercing the system to suit the needs of systemd ...
>>>
>>> For example?
>>
>> Normally run FreeBSD for development, but needed to run a current
>> version of Linux, to test against an open source project, that it would
>> build and run without issue. Installed latest Xubuntu and Debian, both
>> of which operate under systemd, with no opout at install time.
>
> So why didn’t you try a distro that didn’t have systemd?
>
>> All looks good at desktop level, but the networking config didn't stick
>> without a reboot, and things like ifconfig, ntp, inetd and other stuff
>> was missing.
>
> ifconfig was superseded by the iproute2 suite years ago, nothing to do
> with systemd. But of course systemd builds on that work--why reinvent the
> wheel?
>
> And also inetd is one of the many pieces of legacy baggage superseded by
> systemd. systemd offers a much more modular way of managing individual
> services--either get used to it, or go use something else. The choice, as
> always, is up to you.
>
>> It's also not clear how to remove the systemd stuff ...
>
> It’s called “building your own distro”. Go learn from the experts before
> attempting this sort of activity yourself.
>

Fine, but generally, I want use an os for work, and expect to to
just work and be easily configurable out of the box, just like any
similar unix system.

Systemd looks like someone's wet dream intellectual self
abuse, to see how different and opaque it can be made, just for the
sake of it, while contributing nothing that wasn't already there in
some other form. Coding standards and system layout are crap as well,
and where is the doc that describes the data structures, code flow
and how it all works ?. Serious operating systems, VMS, Solaris and
FreeBSD, for example, publish extensive internals books, describing
the code and data structures in detail.

Ymmv, of course, but you still haven't answered the question, ie:
What is its usp and reason for existence, technically ?.

On 5/7/24 13:50, Arne Vajhøj wrote:
> On 5/7/2024 8:45 AM, chrisq wrote:
>> Back on topic, who remembers the dec advfs  for Tru64 ?. Never
>> actually used it, but what were it's advantages / usp ?...
>
> SpiraLog may be even more on topic ...
>
> :-)
>
> Arne
>
>

Had never even heard of it, needed to look it up :-). Will have a
look later, but good report in the Digital Tech Journal,
volume 8, section 2, 1996. Load of other interesting reports there
as well.

It'a quite amazing, looking back to just how much effort digital and
others put into basic research. Stuff some take for granted now,
all the great books have been written etc, but just how many
don't even notice and continue to make the same mistakes over and
over again ?...

Chris

On 5/7/2024 1:13 PM, chrisq wrote:
> On 5/7/24 13:50, Arne Vajhøj wrote:
>> On 5/7/2024 8:45 AM, chrisq wrote:
>>> Back on topic, who remembers the dec advfs  for Tru64 ?. Never
>>> actually used it, but what were it's advantages / usp ?...
>>
>> SpiraLog may be even more on topic ...
>>
>> :-)
>
> Had never even heard of it, needed to look it up :-). Will have a
> look later, but good report in the Digital Tech Journal,
> volume 8, section 2, 1996. Load of other interesting reports there
> as well.

I remembered it.

The demise of SpiraLog and the Snapshot Services thing in many
ways marked VMS changing from frontrunner to legacy.

> It'a quite amazing, looking back to just how much effort digital and
> others put into basic research. Stuff some take for granted now,
> all the great books have been written etc, but just how many
> don't even notice and continue to make the same mistakes over and
> over again ?...

DEC did a lot of research. Was it 4 major research centers they had?
WRL and 3 more?

So did IBM.

Today it is Google/Facebook/Amazon/Microsoft that does that
type of stuff.

One need to make a lot of money to be able to support
such long term research.

Arne