'Linux'.. WOW, I'm almost toltally SOLD now!!!

[DiTBho]

Later I bought a Matrox G400 new and tried to get decent drivers for it back in the turn of the century. Windows NT4 was so-so in terms of performance, but for both Linux (Slackware) and Solaris 7 x86 it was impossible. Some strides were made when Solaris started shipping with x86 instead of CDE (IIRC this was Solaris 8 or 10), but by then I was fed up and replaced the Matrox card. I never looked back.

Yup, if we talk about performance ... well, my hack hasn't yet solved it because some 2D accelerating features are not working so I copied the simplest ever, those provided by fbdev, the simplest framebuffer for xorg, which works (even on a 3DFX voodoo2) but it's not hw accelerated.

I'm not taking full advantage of the power of the the MGA-G4xx chips even because there are several problems with the DMA on the PowerPC side and the original driver is so a mess that I am frankly lost.

I am neither a good nor a pro dev, and two years to reach this minimum point means that if these stuff were for a paid project I would have already been fired 

I am simply obsessed with that project and the idea of using a couple of Matrox MDA 4xx chips that when I was a student I couldn't afford because the G450 was seriously too expensive for me.

I mean, for sure I wouldn't suggest to use this technology neither modern Matrox products for daily job stuff on Linux because ... well "Matrox" for video cards is like "Adaptec" for SCSI adapters, they were great in the 90s and 2000s, but nowadays these two companies are no more the same thing they were in the past.

[bd139]

G450 was a nice card. Had matrox stuff for years myself. Did my first "silent" PC build with a G400 in a Compaq DeskPro AP230 with a Pentium 3 1GHz.

[rstofer]

But how is this  a linux problem?more like  lazy hardware manufacturers who cant be arsed to provide drivers,If you bought  new hardware  for  a windows machine that didn't run would you be shouting at microsoft?

Linux exists on less than 2% of desktops.  Why would a device manufacturer bother to write drivers - and possibly have to update them every time the kernel changed.

[Monkeh]

But how is this  a linux problem?more like  lazy hardware manufacturers who cant be arsed to provide drivers,If you bought  new hardware  for  a windows machine that didn't run would you be shouting at microsoft?

Linux exists on less than 2% of desktops.  Why would a device manufacturer bother to write drivers - and possibly have to update them every time the kernel changed.

And yet.. they do.

[rstofer]

But how is this  a linux problem?more like  lazy hardware manufacturers who cant be arsed to provide drivers,If you bought  new hardware  for  a windows machine that didn't run would you be shouting at microsoft?

Linux exists on less than 2% of desktops.  Why would a device manufacturer bother to write drivers - and possibly have to update them every time the kernel changed.

And yet.. they do.

Yes, they do!  More applications oriented but still, these apps require device drivers of some kind.

Digilent Waveforms is an important application to me and it runs fine on my Raspberry Pi so I can use the Analog Discovery 2 to look at signals on the same Pi while running code from the console.  Very cool!

The Arduino IDE runs on Linux and this seems important.  Perhaps not so much hardware support required but still, it runs.

I have never tried it but I understand that Xilinx Vivado runs on some variants of Linux.  About 5 of them according to:

https://www.xilinx.com/support/documentation/sw_manuals/xilinx2020_2/ug973-vivado-release-notes-install-license.pdf

There some amount of hardware support required to be capable of programming devices.

Many of the hardware manufacturers figure they can overlook the < 2% and not have to deal with the costs.  I know I would!  There just isn't a big enough market to make it worth the effort.  I'm not sure why the others do it.  It's got to be a hassle.

[DiTBho]

There just isn't a big enough market to make it worth the effort. 

Yup, I do think the same.

edit:
and since there isn't enough market, I would also add what I was told last time I had to fix a very inner couple of bugs  and I was tempted to hire/pay some "true Linux kernel and user-land expert" to solve it: "no problem, buddy, it's 50 USD / hour with a minimum contract of 50-100 hours" 

[bd139]

Depends. Their internal developers might be doing the majority of development on Linux so pushing a version out might be cheap and easy. In one company I worked their entire product was wxPython which they had 4 people working on. All the dev was done on Macs. There was another (poor bastard) who’s job it was to build and package it for windows.

As for the expertise cost, it’s expensive indeed. Which is good for me  :-D

Edit: if I was going to start a new software project today that had desktop interaction I actually have no idea where I’d even start to be honest. Everything is a pit of despair at the moment. It’d have to be cross platform. Perhaps Electron (there needs to be a puke emoji in the forum)

[DiTBho]

As for the expertise cost, it’s expensive indeed. Which is good for me  :-D

LOL, so will you give me some "EEVblog-member-friendly discount", won't you?
Yes, yes, yes, right? Look at my (poker) smiling face -> 

(kidding )

A couple of excellent things those pro guys offered were their professional development tools. Don't only they know how to debug your embedded system(1) using Lauterbach, but they also have Trace32 debuggers and license to use it, and debugging with that stuff is thousand years more powerful than trying to wildly debug with kgdb(2) and gdb-stub(3).


(1) Lauterbach's tools are excellent to debug u-boot, which in my case added a couple of other bugs
(2) I used kgdb to debug the Linux kernel over a dedicated serial line
(3) I used a simple gdb-stub to debug u-boot ... it was a poor solution, but I had no other options since I don't even have a jtag cable for PowerPC 4xx.

[bd139]

Hahaha.

I avoid the hell out of kernel debugging these days. Last time I went there it was over serial ports and kgdb as you mention. It’s userland for me or something lower like FreeRTOS on STM32 (today’s project).

If you ever want some fun play with WinDBG. I occasionally have to debug windows server crashes. Those are really nice to deal with. We had one recently where HyperV decided to lose heartbeat and reboot itself. Eventually we found it was a BCM NIC driver. Fingers suitably primed, point at HPE and make them fix the turd 

[DiTBho]

I have never tried it but I understand that Xilinx Vivado runs on some variants of Linux.

In some ways it is the same with the Windriver's stuff for VxWorks. It's the fourth time I've seen this happen, and it seems like when you buy something from them it's a "corporate habit" that they send you a pendrive with a VirtualMachine image (for WmWare) where Linux is patched by them and ready to go straight away.

Initially I thought it was a kind of "courtesy", but when I tried to replicate what they were doing ... I found many patches applied here and there, so many that actually make the Pendrive a true variant of Linux.

[ corporate habit | courtesy ] -> corporate variant of Linux

[Wuerstchenhund]

No it doesn’t. It worked when they certified it. They regularly break. We have some Z series ones from HP which the RAID controller no longer works properly on. That’s RHEL as well.

All the RAID controllers in HP z Series workstations are fake RAIDs, and HP never supported them on Linux (where you're supposed to use dmraid). For good reason as on-board fake RAID is mostly designed around Windows anyways.

However, most HP z Series desktop workstations also support optional hardware RAID controllers (LSI on older machines, Adaptec on newer ones) and they are fully supported under Linux.

We have lots of z Series machines (mostly z6 Gen4 and z8 Gen4), some of RHEL 8 but most on SELD 15, and aside from the Linux specific stuff no real issues.

There’s no game. Linux QA is shit. It’s why we pay Amazon to run our stuff. They have their own Linux distribution which is qualified properly not run on their infrastructure.

I disagree, Linux QA isn't shit. The QA of many distros is (and that includes especially Debian and Ubuntu) and that shows.

On the other side we run a very large business pretty on Linux (RHEL and SEL, now mostly just SEL), backend to desktops (we only use Windows when there's no alternative, i.e. for certain applications). For development systems or systems where budget is an issue and support not important, we run openSUSE Leap (we also used to run CentOS but RH killed that off so we're now in the process of migrating away from RH completely).

Yes, there are issues (especially with the stuff that isn't the Linux kernel, such as the KDE desktop) but we managed to either get them fixed by SUSE (if its a bug) or (if it's something else) we fix it and feed the fix back to SUSE so it may well end up upstream.

It's still more efficient for us than having to deal with the shit show that Microsoft has become and the one that Microsoft licensing has been since forever. Just talking to suppliers and clients who are on Windows and all the issue they have with half-baked software and updates to Windows, Exchange and all the other stuff is nauseating. None of the problems that affected Microsoft products (such as the recent and apparently still ongoing shit show that is printing on Windows or the Exchange exploit) did affect us.

On top of that, anyone who ever had to deal with Microsoft's "support" knows that poking needles in your eyes is a preferable experience. SUSE support is the complete opposite, you talk to people who really understand their products and sometimes even to the person who wrote the actual code in question. It's like day and night.

AWS is great if your data can be sent there (ours can't), and for some application is a great thing, however at the end of the day you need to be aware that you're entrusting your data to a 3rd party and that has dangers and consequences.

[bd139]

Not sure what gen these ones are. They are Z8's and hardware RAID though. These were top end spec machines

[DiTBho]

fake RAIDs

I spent a lot of money and effort on them, testing, hacking them, and my points here are:

• there different kinds of fake RAIDs
• those where "fake" means "software", so the controller is simply a dual/quad sATA ports adapter and the mirroring/stripping is done by the Kernel
• those where "fake" means "firmware", they have advanced CPUs (i960 and similar) which are useless unless you upload a special firmware embedded with the kernel driver, which also has to manage these cards in PCI-bus-master, which is very complex so only cared by corporate for serious business. When there is not enough interest they could be used as "fake" RAID, and "fake" here mans that don't manage their special firmware, you simply turn off the CPUs and use them as a simple dual/quad sATA ports adapter, again forget RAID 5,10, etc, only RAID0 and RAID1 are possible, and all the mirroring/stripping is done by the Kernel

The funniest card found was a weird card with 128Mbyte PC133 ram stick and PPC405 cpu mounted to control two sATA interfaces. After some digging and wildy hacking, I reprogrammed the card (via kernel firmware upload mechanism) to offload some SHA256 work, so I actually turned a "sATA controller" into a "SHA" crypto-coprocessor.

I doesn't make any sense, but it was funny 

[Wuerstchenhund]

Not sure what gen these ones are. They are Z8's and hardware RAID though. These were top end spec machines

There's only the Z8 Gen4 (earlier models were three digit, i.e. z840, before that z820 and before that z800). And the only supported RAID controller for that model is the Adaptec SmartHBA 2100-4i4e:

https://www8.hp.com/h20195/v2/GetPDF.aspx/c05527763.pdf

As the name implies, the SmartHBA is a Host Bus Adapter with some RAID functionality:

https://www.microsemi.com/product-directory/smarthba-2100-12g-host-bus-adapters/4998-smarthba-2100-faqs

[Unlike prior generation entry level RAID adapters from Microsemi, the SmartHBA 2100 does not support an external DDR cache. Instead all memory required for all RAID levels is integrated onto the SmartIOC 2100 silicon on the adapter. This provides cost, power, and thermal benefits. The SmartHBA 2100 is an “HBA first”, with basic RAID support included.[...]

Still, the SmartHBA 2100 is fully supported under RHEL:

https://download.adaptec.com/pdfs/readme/adaptec_smarthba_smartraid_relnotes_02_2021.pdf



I think our early z6 and Z8 Gen4s came with the same adapter as they were equipped with quadruple 12Gbps SAS SSDs, and they have been working fine with subsequent RHEL and SELD updates (but then we regularly update BIOS, firmware and drivers on our machines which many enterprises don't do).  Now we only use NVMe local storage and for large amounts of data simply connect machines via dual 10Gbps or 40Gbps network to a large flash-based SAN) 

[Wuerstchenhund]

• there different kinds of fake RAIDs
• those where "fake" means "software", so the controller is simply a dual/quad sATA ports adapter and the mirroring/stripping is done by the Kernel
• those were "fake" means "firmware", they have advanced CPUs (i960 and similar) which are useless unless you upload a special firmware embedded with the kernel driver, which also has to manage these cards in PCI-bus-master, which is very complex so only cared by corporate for serious business. When there is not enough interest they could be used as "fake" RAID, and "fake" here mans that don't manage their special firmware, you simply turn off the CPUs and use them as a simple dual/quad sATA ports adapter, again forget RAID 5,10, etc, only RAID0 and RAID1 are possible, and all the mirroring/stripping is done by the Kernel

Leaving aside that shared PCI (and things like busmatering) hasn't really been a thing with PCs and servers for more than 15 years now (and i960 based controllers are even older!), your second description of what amounts to "fake RAID" is simply incorrect.

"Fake RAID" is a term which describes RAID functionality which is implemented in software *only*, sits in the boot firmware and is executed on the host's CPU. Which is the case for the vast majority of RAID functionality embedded on mainboards and desktop chipsets, as well as in some HBAs (like the LSI 2008 based ones).

The opposite of "Fake RAID" is "hardware RAID", which isn't really "hardware" but "hardware and software" RAID. Here the controller or RAID chipset comes with hardware support for certain RAID functions (like XOR), and increase the performance these adapters usually also come with some form of cache memory (usually battery or supercap backed). However, as with fake RAID, the RAID functionality is also part of the firmware, so it's never a pure hardware solution.

[madires]

BTW, those "hardware and software" RAIDs are called hardware-assisted software RAIDs, or - using your terminology - hardware-assisted fake RAIDs.

[DiTBho]

Leaving aside that shared PCI (and things like busmatering) hasn't really been a thing with PCs and servers for more than 15 years now (and i960 based controllers are even older!), your second description of what amounts to "fake RAID" is simply incorrect.

The i960? Sure it's old, mine was found in a 2008 product; it was just an example of something I have recently hacked and of which I know its inner working details.

"Fake RAID" is a term which describes RAID functionality which is implemented in software *only*, sits in the boot firmware and is executed on the host's CPU.

That's what I wrote in my post: RAID0 and RAID1 done by the Linux kernel 

The opposite of "Fake RAID" is "hardware RAID", which isn't really "hardware" but "hardware and software" RAID. Here the controller or RAID chipset comes with hardware support for certain RAID functions (like XOR), and increase the performance these adapters usually also come with some form of cache memory (usually battery or supercap backed). However, as with fake RAID, the RAID functionality is also part of the firmware, so it's never a pure hardware solution.

Here, I am afraid you haven't understood my post.

I didn't wrote anything different from what you explain, I simply said that these "hardware RAID" have more complex "boot firmware"; a part of it is a "BIOS extension" written in x86 code which does some setting before the kernel is loaded, and once the kernel is up it also requires the kernel to pass them the second stage firmware (this was i960-code in my case), so these "hardware RAID" are useless if you don't have the proper second stage firmware or if your kernel cannot support it, or if your system cannot manage PCI-bus master.

My point is: in all of these cases I could only turn a "hardware RAID" into a "software RAID", which doesn't sound good, but it is better than throwing away the card.

Code: [Select]

              battery
         512Kb static ram
                ||
PCI <--------> i960 <------> Sil3112 <---> sATA disk
                ||
             PC133 ram
PCI <----------------------> Sil3112 <---> sATA disk

I bypassed the i960 entirely in a way its only purpose is to call pass commands and data to Sil3112 chips with no additional computation (and no more PCI-bus mastering, because I am not able to support it).  So the kernel directly talks to the two Sil3112 sATA interface chips, and this way I cloned and lightly modified one of the kernel driver wrote for the Sil3112 chip.


In my case I bypassed the i960 entirely in a way its only purpose is to pass commands and data to Sil3112 chips with no additional computation on the i960 chip, everything is done by the kernel which directly talks to the two Sil3112 sATA interface chips.

This way I cloned and lightly modify one of the kernel driver wrote for the Sil chip and I avoided to trash the card since it's a fully working RAID0 and RAID1 system 

[DiTBho]

Code: [Select]

PCI <--------> PPC405 <------> M8?WTF?!? <---> sATA disk
                ||
             PC100 ram

PCI <--------> PPC405
                ||
             PC100 ram

This is the second "hardware RAID" card I hacked. It cost me 35 Euro including postage. This time I didn't know which is the sATA chip, so I played with the PPC405 CPU. The DMA doesn't yet work and I have no idea of the reason, but when you don't know how to sort it out, "polling I/O" is the way to go, which is definitively slow for something really useful but it has anyway given hours of fun 

[rsjsouza]

But how is this  a linux problem?more like  lazy hardware manufacturers who cant be arsed to provide drivers,If you bought  new hardware  for  a windows machine that didn't run would you be shouting at microsoft?

Linux exists on less than 2% of desktops.  Why would a device manufacturer bother to write drivers - and possibly have to update them every time the kernel changed.

And yet.. they do.

(...)
Many of the hardware manufacturers figure they can overlook the < 2% and not have to deal with the costs.  I know I would!  There just isn't a big enough market to make it worth the effort.  I'm not sure why the others do it.  It's got to be a hassle.

Been there, done that. Some manufacturers decide to forfeit the 2%, but others take the plunge but, after the fourth or fifth kernel modification that causes a production stop bug to happen, decide to either carefully consider or kill the support roadmap. That is why it is not uncommon to see the downloads page for drivers or even IDEs available only for older releases of the OSes, while the newer stuff is usually made for Windows.

Regardless, it has become much better in the latest years and, in my own experience, macOS has been way worse at the low level stuff.

and since there isn't enough market, I would also add what I was told last time I had to fix a very inner couple of bugs  and I was tempted to hire/pay some "true Linux kernel and user-land expert" to solve it: "no problem, buddy, it's 50 USD / hour with a minimum contract of 50-100 hours" 

Yep, Those Lauterbachs do not come cheap and the yearly maintenance fee is quite hefty...

A favourable supply/demand curve pays hefty bounty. My mother in law made a ton of money with Cobol in 1999.

[madires]

Even old (2004) Matrox dual head (G4xx series) are not 100% working, it's still partially documented, and needs wild hackering and black voodoo in order to work especially in non-x86 computers like in my case.

My last graphics card from Matrox was a G550. Back then their cards worked quite well with their proprietary X11 drivers (x86). The developers of the open source drivers had a hard time to get any details about Matrox' graphic chips. Therefore their drivers weren't really usable for recent cards. For the G450 one needs to load a binary blob from Matrox to get the second port up and running (blob available only for x86). The lesson to be learned about hardware and linux is to choose components fully supported by open source drivers. If a component's vendor treats everything as a state secret stay away. It's not worth the hassle! And tell the vendor of your decision not to buy their product and why.

[Wuerstchenhund]

Leaving aside that shared PCI (and things like busmatering) hasn't really been a thing with PCs and servers for more than 15 years now (and i960 based controllers are even older!), your second description of what amounts to "fake RAID" is simply incorrect.

The i960? Sure it's old, mine was found in a 2008 product; it was just an example of something I have recently hacked and of which I know its inner working details.

"Fake RAID" is a term which describes RAID functionality which is implemented in software *only*, sits in the boot firmware and is executed on the host's CPU.

That's what I wrote in my post: RAID0 and RAID1 done by the Linux kernel 

There is a difference between software RAID as provided by many operating systems and "Fake RAID". The latter is reserved for hardware devices which come with boot firmware but no hardware support for RAID functionality, and the RAID code runs entirely on the host CPU (initially through the firmware, later through the fake RAID drivers). Also, like hardware RAID, "Fake RAID" is completely transparent to the host OS (which only sees the virtual drives, not the physical ones). Which is why it's called "fake RAID"(i.e. faking a hardware RAID controller).

Software RAID like Linux dmraid isn't "fake RAID" because it doesn't "fake" the functionality of a hardware RAID, it's also not OS transparent as the OS can still see the physical storage devices.

Here, I am afraid you haven't understood my post.

That's entirely possible. It's Thursday after all and mentally I'm already in Easter Weekend mode 

I didn't wrote anything different from what you explain, I simply said that these "hardware RAID" have more complex "boot firmware"; a part of it is a "BIOS extension" written in x86 code which does some setting before the kernel is loaded, and once the kernel is up it also requires the kernel to pass them the second stage firmware (this was i960-code in my case), so these "hardware RAID" are useless if you don't have the proper second stage firmware or if your kernel cannot support it, or if your system cannot manage PCI-bus master.

That's correct, however I have yet to see a hardware RAID controller where the 2nd stage fw (the one for the controller IC) is not part of the boot firmware and loaded by the host OS separately, at least not in the last 20 years or so. So unless you fiddle with the controller firmware there shouldn't be a situation where you can lose the 2nd stage fw.

My point is: in all of these cases I could only turn a "hardware RAID" into a "software RAID", which doesn't sound good, but it is better than throwing away the card.

Depends what you mean with software RAID, if you're talking about what comes with Linux, Windows and other OSes then yes (and there are people that try to remove RAID functionality from fake RAID controllers so they can use them as simple HBAs and put ZFS on top) but that would still be software RAID but not "Fake RAID" 

Code: [Select]

              battery
         512Kb static ram
                ||
PCI <--------> i960 <------> Sil3112 <---> sATA disk
                ||
             PC133 ram
PCI <----------------------> Sil3112 <---> sATA disk

I see what you mean, however no-one really builds RAID controllers that way any more (and hasn't been for a very long time). Today it's a single RoC (RAID on Chip) controller from LSI/Broadcom or Adaptec/Microsemi, which contains pretty much everything including the SAS/SATA PHYs. The only thing that's external is the cache (BBWC or FBWC). The ROC has a single firmware image which contains boot block and 2nd stage fw for the chip itself, and once that's loaded then the controller performs its duties independent on what the host computer does (or if the OS has a driver for that controller).

I bypassed the i960 entirely in a way its only purpose is to call pass commands and data to Sil3112 chips with no additional computation (and no more PCI-bus mastering, because I am not able to support it).  So the kernel directly talks to the two Sil3112 sATA interface chips, and this way I cloned and lightly modified one of the kernel driver wrote for the Sil3112 chip.

That's great, but that's possible because this design is pretty antique (this is how Mylex used to design their RAID controllers back in the late '90s) and processor and SATA PHYs are physically separate components. As I said, that no longer exists in this form.

In my case I bypassed the i960 entirely in a way its only purpose is to pass commands and data to Sil3112 chips with no additional computation on the i960 chip, everything is done by the kernel which directly talks to the two Sil3112 sATA interface chips.

This way I cloned and lightly modify one of the kernel driver wrote for the Sil chip and I avoided to trash the card since it's a fully working RAID0 and RAID1 system 

As I said, this is similar with what some people do to common LSI HBAs with fake RAID BIOS, they remove the RAID code (or replace it with a pure HBA BIOS) so the connected drives are simply passed through to the OS, which they want so they can use software RAID.

But the resulting system is still just "software RAID", not "fake RAID" 

[PKTKS]

But how is this  a linux problem?more like  lazy hardware manufacturers who cant be arsed to provide drivers,If you bought  new hardware  for  a windows machine that didn't run would you be shouting at microsoft?

Linux exists on less than 2% of desktops.  Why would a device manufacturer bother to write drivers - and possibly have to update them every time the kernel changed.

This is an understatement..
"The (so called) desktop" is a metaphor carved by patent trollers.
AFAIK back in the 70s Xerox already has that.

The point is that:  *NIX RUNS ON 99.99% of "REAL COMPUTERS"
mostly Linux now .. just because..

All serious buz  require  serious reliable  machines running stable
so the drivers of the 99.99% on the world will need that.. for a long time.

The "desktop" gizmo seem to be now a *BUNTU hoax much like
an MS shell company at this point. 

Not surprisingly  the huge effort to IMPLOD Xorg steering
developers to systemd_py_wayland  thing

where MS can PATRONIZE linux running a tiny little "thingy"  from the
app-store  called buntu for windows on WSL.

EEE strategy of success: implode Xorg -> doom the desktop -> run *nix on WSL

Rumors that  several apps are on the way that WILL ONLY RUN INSIDE WSL

see ya?  they love *NIX.  Foundations and shell companies

Paul

[PKTKS]

The 2 cents  tidbits..

https://devblogs.microsoft.com/commandline/whats-new-in-the-windows-subsystem-for-linux-september-2020/#gui-apps

In a projected scenario...

With no FAB driver support ..  **ALL** "desktops will be forced
to run inside that  shitty MS azure account  where only their
shell companies (like buntu for WSL or RHEL for WSL..) will be
allowed to run..

Applets contained into that shit hole included.

Otherwise be happy w/one of these veered "distros" like RHEL or Debian.
as of today  far steered from *nix ground


Paul

[GlennSprigg]

INTERESTING READING !!  (OP here...). Though quite a bit is over my head at this early stage...   

Interestingly, their is a fair amount of discussion here about new/updated 'Drivers' lacking, from hardware/etc developers, and their reasons or
interest in producing them for smaller markets??  I would have 'thought' that they would/could supply some parameters/coding/information to the
Unix/Linux COMMUNITY, (who collectively supply such general Open-Source software, gratis!), so that maybe THEY can work on creating such drivers?? 

And in regards to my VirtualBox Guest 'Ubuntu-Mate 20.04', I found out about a few additional things!!  The VM Guest was not recognizing my BlueTooth
hardware, but that's due to the VirtualBox emulation environment!  However, 'V.B.' still allows it to work, via the Host, so that's OK. The same sort of thing
is going on with Wireless Broadband. I didn't have to set up communications via the Ubuntu Guest at all, as 'V.B.' just passes the comms via the Host,
straight through my existing (and already logged on) wireless connection, via this Win-10 Laptop Host! So that all works from the get-go with no setting up!

I ALSO found out after research, that you can improve a lot on the VirtualBox emulation, that's NOT done within VirtualBox.  In the folder where you installed
VirtualBox, there is a dormant file, called 'VBoxGuestAdditions.iso'.  This is to be used within the GUEST only!  When the Guest Ubuntu etc is running, and you
are working in it, go to the VirtualBox menu area, select Devices, and CD, and mount the above .iso into the guests virtual drive. It will auto-boot, for various
operating systems, and install into your virtual environment a whole lot of extra settings & refinements, to make it work even better & more smoothly!!   
(NOTE: This is NOT the same as installing the Oracle_VM_VirtualBox_Extension_Pack' from within VirtualBox itself).

The only program so far that will install, but not run for me, is 'Blender'. Does nothing when selecting it within the GUI. So I learnt to TRY running it in 'Terminal',
which would/(did!) show what the error is!  Turns out it needs at least OpenGL 3.3, which the virtual VMWARE screen/graphics controller only has ver 2.1...
(Although the NVIDIA Graphics GeForce GTX-670M card in the host laptop is using OpenGL 4.6, but this can't be seen in the guest!!).
I suspect that if/when I set up UBUNTU-MATE on a stand-alone system, then that won't be the case, and the latest Linux drivers ARE available from...
https://www.nvidia.com/en-us/drivers/results/134859/
GIMP works fine though!!

[DiTBho]

wayland

Wayland ... I think I have to make my X11-terminal project compliant with Wayland.
At the moment it's a nano-X compliant.

What is nano-X? It's a directive used in xorg to compile it with the minimal features.

It will be a challenge