Debating trying:

[DavidS]

I am familiar with NetBSD, and on other systems OpenBSD, though never really gave much notice to FreeBSD. I have been reading a lot about FreeBSD in recent times, as one of the Open Source OS options for the RPi 1B+.

Trying to get more away from Linux and GNU (personal preference), and reduce my reliance on RISC OS, I have a NetBSD SD card setup as it is a Unix I know. It would definitely be worth learning more about the other actual Unix systems available for the BCM2835 RPi, that would be FreeBSD (as OpenBSD claims to need an ARMv7 or newer CPU for the RPi).

Very interested on how FreeBSD compares with NetBSD in terms of being trim, easy to remove unwanted packages from the base image, ease of custom configuration at the low level, etc. Also I would assume that like NetBSD the CoreUtils are decended from those of BSD 4.4, same for the Clib and related, please mention if this is not correct. Being a BSD is it reasonable to assume that sh is the default shell (I do not care for bash)?

No questions about X, WM's, Desktop Environments, etc, as these are the same on any Unix or Unix like OS.

[ame]

Have you considered YASDOE?

[DavidS]

Have you considered YASDOE?

Yes of course. Though for now I am recovering from a medical situation (as noted on my sites), and while not complete YASDOE is getting a good amount of attention from others for the time being (hundreds of downloads, and at least a few modified uploads according to the FTP log). It will be a while before I am able to get back to that project, though I do have some ideas on how to move it forward (admittedly part of my interest in playing in BSD land, no more on that for now). Actually have the RISC OS hosted version of YASDOE running on a computer here, just to keep my mind aware of it as I restore my thinking.

Still attempting to figure out how to make GitHub work as another host for YASDOE (without having to fight there version control stuff).

Though for the time being a Unix with a good X11, and an available XLib and XCB will be good in getting my mind back on track. Would like to understand the XLib and XCB well enough again to play in a good way. I think a local call only implementation of the XLib API would make a good windowing system, and the same for XCB even better. The Client Server model I feel is one of the downfalls of X11 when used for a desktop computer, a local call only API would be much better for desktop computing (no need to be able to run applications on remote systems).

I repeat a good Unix System with X11 interfaced by XLib and XCB. Not a Unix like system. This will help keep my mind active and keep working in the correct directions. I am getting away from Linux and other non-unix unix like systems, and continuing to push myself forward.

[Daniel Gessel]

My brother uses FreeBSD on his servers; I've never known why he chose that over Linux. I could ask. Linux seems to win the popularity contest, but if something else had better graphics driver support I'd be interested. I don't think that's my bro's motivation on his (most likely headless) servers.

Oh, hey - sending you my best re: medical situations. My career got derailed and I've retired early. I'm really sorry to hear "the vagaries of being human" got to you too...

[ame]

Have you considered YASDOE?

Yes of course. Though for now I am recovering from a medical situation (as noted on my sites), and while not complete YASDOE is getting a good amount of attention from others for the time being (hundreds of downloads, and at least a few modified uploads according to the FTP log).

I have no idea about your sites, but I'm surprised you made YASDOE available, since you talked about it here but never announced where it could be downloaded from.

Still attempting to figure out how to make GitHub work as another host for YASDOE (without having to fight there version control stuff).

Yes, git would be so much better without all that "version control stuff" getting in the way...

[DavidS]

Still attempting to figure out how to make GitHub work as another host for YASDOE (without having to fight there version control stuff).

Yes, git would be so much better without all that "version control stuff" getting in the way...

LOL:

The version control would not be an issue if there was a way to explicitly control what is included in the backlog / difflog. Sometimes regressions are a big issue, and sometimes one may wish to make multiple commits between ones that should actually be available to regress to. Sometimes the commits need to be under easy control as a result. You know like the older propitiatory, open source, version control systems that everyone used in the 1980s, and early 1990s.

Nothing wrong with git for most people. I am just a bit more picky about how to do things than most people. Nothing against git, just against the lack of a way to fix commit errors.

[DavidS]

Positively surprised about the quick replies now. Maybe RPi forums are returning to more use.

Back On Topic:

A lot of what embodies Unix is good. An OS that started as a local use only (on the DEC PDP-7), and grew very rapidly to an OS of general use. Looking at what the core of Unix is, and using an actual Unix system that has been updated and maintained, helps to keep ones mind sharp.

Is there one that can give a good concise, and detailed, comparison between FreeBSD and NetBSD? What are the differences from a user perspective? What are the differences in the amount of extras to deal with out of box? Is it as easy to configure FreeBSD as NetBSD (in NetBSD you have full control, to the point of even always writing your own ~/.xinitrc or ~/.xsession files, very easy to configure in detail)? Is there a difference in default (BSD, or similar Licensed) compiler suites? Is there more or less of the extras to remove? And similar comparisons, I have been unable to find that level of detail on FreeBSD, and it would make a difference as to if it is worthwhile to try FreeBSD.

NOTE: I have seen many of the Unix Like (eg Linux) OS's that have user utilities that attempt to get in the way of personal configureation. Often these utilities claim to try to make configuration easier, though actually make it more difficult, even for new users. Look in the ~/.profile, ~/.xsession, and similar files in common Linux distros, then make a reasonable change (say not starting as many programs in X), then reboot (you may be good at first), then reboot again after using normal applications, then look at the file you modified again. See the problem?

[Wb7odyFred]

Hello David,
Congrats on YASDOE. Looks interesting to test out https://github.com/David-SWUSA-RISCOS/Y ... /README.md

YASDOE, An OS for Simplicity.

Tue Apr 19, 2022 1:57 am
YASDOE is an Operating System written by a single author over 10 years time, and very soon to be shared with the world. The goals are from day one to create an Operating System that is easy to use and easy to program for, and is radical in design in the good direction.
viewtopic.php?t=333257

Robonuggie https://www.youtube.com/channel/UCxwcmR ... NS37dCgmHA Youtube channel, has several Raspberry Pi videos for Rpi3B+ and Rpi4B , Rpi400

https://www.youtube.com/watch?v=ZBYQjfGeP7g Raspberry Pi is Electrifying

https://www.youtube.com/watch?v=ObQTHyvcdQ0 XFCE & OpenBox install on FreeBSD 13.1

https://www.youtube.com/watch?v=7kfOlxVWV8E FreeBSD 13.1 and 14.0 used for a week on Raspberry Pi.

https://www.youtube.com/watch?v=Cx7_zvh-b6k A viable desktop alternative on Rpi, FreeBSD 13.1

Is there one that can give a good concise, and detailed, comparison between FreeBSD and NetBSD? What are the differences from a user perspective? What are the differences in the amount of extras to deal with out of box?
https://www.youtube.com/watch?v=OxB70pg5Tsg A FreeBSD user tries out, NetBSD 8.0

https://www.cyberciti.biz/faq/how-to-in ... 2-model-b/ Install FreeBSD on Raspberry Pi 2 model B

I hope these answer some of your questions, David.


Fred L. Finster WB7ODY

[ejolson]

Positively surprised about the quick replies now. Maybe RPi forums are returning to more use.

Back On Topic:

A lot of what embodies Unix is good. An OS that started as a local use only (on the DEC PDP-7), and grew very rapidly to an OS of general use. Looking at what the core of Unix is, and using an actual Unix system that has been updated and maintained, helps to keep ones mind sharp.

Is there one that can give a good concise, and detailed, comparison between FreeBSD and NetBSD? What are the differences from a user perspective? What are the differences in the amount of extras to deal with out of box? Is it as easy to configure FreeBSD as NetBSD (in NetBSD you have full control, to the point of even always writing your own ~/.xinitrc or ~/.xsession files, very easy to configure in detail)? Is there a difference in default (BSD, or similar Licensed) compiler suites? Is there more or less of the extras to remove? And similar comparisons, I have been unable to find that level of detail on FreeBSD, and it would make a difference as to if it is worthwhile to try FreeBSD.

NOTE: I have seen many of the Unix Like (eg Linux) OS's that have user utilities that attempt to get in the way of personal configureation. Often these utilities claim to try to make configuration easier, though actually make it more difficult, even for new users. Look in the ~/.profile, ~/.xsession, and similar files in common Linux distros, then make a reasonable change (say not starting as many programs in X), then reboot (you may be good at first), then reboot again after using normal applications, then look at the file you modified again. See the problem?

My impression is that NetBSD is more conservative than FreeBSD in terms of rate of development, addition of new features, gnuisms and so forth. I can't compare the respective kernels on the Pi. My feeling is neither BSD kernel will be as stable as the official Linux kernel. On the other hand, the userland on BSD in either flavour is likely more stable.

My favourite Unix-like OS on the Pi Zero is actually Void Linux. This distribution is not based on Debian or Redhat, does not include systemd or dbus in base and runs well on a Zero.

viewtopic.php?t=323727

I think Void combines the Linux kernel maintained by the Raspberry Pi team with a simpler userland I understand.

[Gavinmc42]

Got some age related issues too now.
Gives me more time to actually make stuff

I approach Pi usage from a single application at once direction.
https://github.com/BabbageBrassWorks/scenicus

Just for kicks I downloaded an Unreal5 demo video and converted the mp4 to Wav and H264.
Lots of talent out there and Unreal 5 is very impressive, at least to me, the kid not so impressed
The h264 is 221MB, wav is 99MB only 10mins before it loops.
https://www.youtube.com/watch?v=8nCmF3CWSu4

Tested a 1hr Skyrim ambiance vid, h264 893MB, wav 1.5GB.
Decoding is in VC4 hardware, hardly draws any power.

An old PiB+ plugged into a small HDMI TV has been providing me with a nice relaxing scenic, audio experience all day.
Summer here and the Pi B soc is not even warm, I on the other hand am melting my brain.
Trying to figure out how to do overlays for track selection on Pi4 as OpenVG does not work on VC6 Pi's
This heatwave here in my part of Oz is nuts, in my old part of Oz it is snowing.

I don't think I have enough brain cells left working to learn Unix/BSD.
Does the accelerated Videocore stuff work on them?

If I can get track selection overlays working it is step closer to running different applications.
Micro kernel.img that selects different single purpose applications?
Some sort of shell script that runs graphic apps?
Self hosting is a dream that gets closer.

Do I get a new PC to make Unreal5 vids and play with Stable Diffusion?
Not sure if my brain and wallet is up for that.
While I cannot make Unreal5 vids on my Pi400, I can make apps that play them on a Zero or old B.

There is the possibility of even making games with cut scenes like Myst but better on baremetal Pi's

Remote control track selection?
Hmm, forget IR remote or buttons and just have webpage interface?
That will work for the B+ Pi's
Starting to cool down, brain is working a bit better
Got plenty of old B's and B+, more than I have TV's.

Will work on Pi4 too, done plenty of webservers with them, no need to figure out OpenVG alternatives

[DavidS]

My impression is that NetBSD is more conservative than FreeBSD in terms of rate of development, addition of new features, gnuisms and so forth. I can't compare the respective kernels on the Pi. My feeling is neither BSD kernel will be as stable as the official Linux kernel. On the other hand, the userland on BSD in either flavour is likely more stable.

I have read similar. I am still trying both to see which is a better fit for my usage, they are both Unix (not 'Unix Like', not 'POSIX Like' not 'POSIX', they are Unix, descended from AT&T).

So far I like both of them, though still difficult getting a good setup as it takes some digging to find some components in non-gnu form (kind of the point of using a Unix is to reduce the dependency on a copy cat ecosystem). Some utilities will always be GNU, as that is who created them, this is OK, as they were never in the normal Unix world anyway.

I do like how most of the native tools (including PCC) take a lot less system resources than there GNU counterparts. That is me though.

My favourite Unix-like OS on the Pi Zero is actually Void Linux. This distribution is not based on Debian or Redhat, does not include systemd or dbus in base and runs well on a Zero.

viewtopic.php?t=323727

I think Void combines the Linux kernel maintained by the Raspberry Pi team with a simpler userland I understand.

The point is as much to go with an alternative to Linux, or from the other view that which Linux created an alternative to. Linux is no longer as lean as it used to be, this happens and is alright for those that like it. I have used Linux implementations that use less than 12MB of RAM with a full desktop environment, though that was with an updated version of the 4.2 kernel (still maintained and updated today), and almost zero CPU time when idle.

Got some age related issues too now.
Gives me more time to actually make stuff

I approach Pi usage from a single application at once direction.
https://github.com/BabbageBrassWorks/scenicus

Just for kicks I downloaded an Unreal5 demo video and converted the mp4 to Wav and H264.
Lots of talent out there and Unreal 5 is very impressive, at least to me, the kid not so impressed
The h264 is 221MB, wav is 99MB only 10mins before it loops.
https://www.youtube.com/watch?v=8nCmF3CWSu4

Tested a 1hr Skyrim ambiance vid, h264 893MB, wav 1.5GB.
Decoding is in VC4 hardware, hardly draws any power.

An old PiB+ plugged into a small HDMI TV has been providing me with a nice relaxing scenic, audio experience all day.
Summer here and the Pi B soc is not even warm, I on the other hand am melting my brain.
Trying to figure out how to do overlays for track selection on Pi4 as OpenVG does not work on VC6 Pi's
This heatwave here in my part of Oz is nuts, in my old part of Oz it is snowing.

I don't think I have enough brain cells left working to learn Unix/BSD.
Does the accelerated Videocore stuff work on them?

As with Linux, so long as the Application has support for it. There are many applications ported from Linux that do, very few native ones though.

If I can get track selection overlays working it is step closer to running different applications.
Micro kernel.img that selects different single purpose applications?
Some sort of shell script that runs graphic apps?
Self hosting is a dream that gets closer.

For a Micro Kernel nix like system your best option is probably Minix 3.

If it need not be nix, then the Exec of AROS is an even better Microkernel. The AROS userspace is pretty nice too.

Do I get a new PC to make Unreal5 vids and play with Stable Diffusion?
Not sure if my brain and wallet is up for that.
While I cannot make Unreal5 vids on my Pi400, I can make apps that play them on a Zero or old B.

Have you looked at how much power a PC consumes? At least in my case it is not worth it.

There is the possibility of even making games with cut scenes like Myst but better on baremetal Pi's

Remote control track selection?
Hmm, forget IR remote or buttons and just have webpage interface?
That will work for the B+ Pi's
Starting to cool down, brain is working a bit better
Got plenty of old B's and B+, more than I have TV's.

Will work on Pi4 too, done plenty of webservers with them, no need to figure out OpenVG alternatives

Web Servers is a different game altogether. Using any of the JS, or other user side stuff is one area I am attempting to get fewer to do. In 99% of cases the same can be done better with normal HTML 4.2 without scripting, in the few exceptions go for it.

[Gavinmc42]

For a Micro Kernel nix like system your best option is probably Minix 3.

Got a 68000 Kit computer in the junk somewhere that ran Minix.

Have you looked at how much power a PC consumes? At least in my case it is not worth it.

Yep, especially those fancy graphics cards.
Retired now so money for those toys just got tight.
Busy learning CNC to make some $$$.

Turns out even a B+ has no problem playing Unreal vids when converted to Wav/H264.
They make nice ambient music/vid players.

In 99% of cases the same can be done better with normal HTML 4.2 without scripting, in the few exceptions go for it.

I agree, lots can be done with 4.2, 5.0/JS is bloatware.

Been learning ADA now I found out it runs on Pico too.
Still having trouble understanding "cross compiling" ADA from Pi400 to Pico.
I get closer if I use 32bit Raspberry OS.

ADA for making an OS?
A Tiny ADA compiler called HAC compiled and ran on the Pi400, 32 and 64
A little toy bit of software to play with.
Make it self hosting on a Pico?

[DavidS]

The relative simplicity of BSD (as modern nix systems go) brings to mind one thing that bugs me.

On a modern DESKTOP nix system that has no need for remote access (as it is a DESKTOP system), why do we still use an X Server? A Windowing system that provides the XLib API (and XCB API), though does not use a packet based display server, would seem a more logical and better option from my view. Implementing a local only, direct call Windowing System using the XLib API (with an XCB interface) seems more reasonable for a Desktop OS, my view.

That and why does everyone use X11, when many other windowing systems are available for nix systems?

[jojopi]

Look in the ~/.profile, ~/.xsession, and similar files in common Linux distros, then make a reasonable change (say not starting as many programs in X), then reboot (you may be good at first), then reboot again after using normal applications, then look at the file you modified again. See the problem?

No, I cannot reproduce a problem. Nothing is changing my custom .profile or .xsession, which indeed would be very annoying.

The mention of those two files is also interesting because they are essentially scripts, so they could contain arbitrary code. That makes them particularly poorly suited to mechanical alteration. Other programs would not even be able to determine reliably what the files currently do (halting problem).

Is it possible that your storage device is failing, so that changes to the file system only persist as long as they remain cached in RAM? Otherwise I would be interested to know exactly what is happening to your files, and what package might be causing it.

[ejolson]

The relative simplicity of BSD (as modern nix systems go) brings to mind one thing that bugs me.

On a modern DESKTOP nix system that has no need for remote access (as it is a DESKTOP system), why do we still use an X Server? A Windowing system that provides the XLib API (and XCB API), though does not use a packet based display server, would seem a more logical and better option from my view. Implementing a local only, direct call Windowing System using the XLib API (with an XCB interface) seems more reasonable for a Desktop OS, my view.

That and why does everyone use X11, when many other windowing systems are available for nix systems?

From a historic point of view Unix was not designed to be a single-user OS. From a modern point of view modern desktops are networked.

While the convergence between single-user systems that can securely interact with a global Internet and the security of multiuser systems is incomplete, the idea of a networked windowing system is likely more practical than running the GUI of every application through a web browser. On the other hand, the current fashion is tools such as Electron that avoid the idiosyncrasies of individual windowing systems.

Moreover, just like a networked window system is naturally multi-threaded, those web technologies also allow multiple cores to be kept busy when running a simple single-threaded application.

[ame]

The relative simplicity of BSD (as modern nix systems go) brings to mind one thing that bugs me.

On a modern DESKTOP nix system that has no need for remote access (as it is a DESKTOP system), why do we still use an X Server? A Windowing system that provides the XLib API (and XCB API), though does not use a packet based display server, would seem a more logical and better option from my view. Implementing a local only, direct call Windowing System using the XLib API (with an XCB interface) seems more reasonable for a Desktop OS, my view.

That and why does everyone use X11, when many other windowing systems are available for nix systems?

What windowing systems would they be?

[ejolson]

The relative simplicity of BSD (as modern nix systems go) brings to mind one thing that bugs me.

On a modern DESKTOP nix system that has no need for remote access (as it is a DESKTOP system), why do we still use an X Server? A Windowing system that provides the XLib API (and XCB API), though does not use a packet based display server, would seem a more logical and better option from my view. Implementing a local only, direct call Windowing System using the XLib API (with an XCB interface) seems more reasonable for a Desktop OS, my view.

That and why does everyone use X11, when many other windowing systems are available for nix systems?

What windowing systems would they be?

My understanding is that Electron is a popular alternative to writing an X11 application. Thus, the answer seems to be that fewer and fewer people are using X11 on Unix with similar trends seen for the proprietary GUIs bundled on Apple MacOS and Microsoft Windows.

[Daniel Gessel]

That and why does everyone use X11, when many other windowing systems are available for nix systems?

What windowing systems would they be?

My understanding is that Electron is a popular alternative to writing an X11 application. Thus, the answer seems to be that fewer and fewer people are using X11 on Unix with similar trends seen for the proprietary GUIs bundled on Apple MacOS and Microsoft Windows.

Alas, it sounds as if poor Wayland is dead? I live near there, I'll put flowers on its grave...

[DavidS]

This post is effectively replaced by the next post. The forum software somehow made a copy when I made an edit to make a correction, so the entire post does not need to be here twice, once is enough

[DavidS]

Look in the ~/.profile, ~/.xsession, and similar files in common Linux distros, then make a reasonable change (say not starting as many programs in X), then reboot (you may be good at first), then reboot again after using normal applications, then look at the file you modified again. See the problem?

No, I cannot reproduce a problem. Nothing is changing my custom .profile or .xsession, which indeed would be very annoying.

The mention of those two files is also interesting because they are essentially scripts, so they could contain arbitrary code. That makes them particularly poorly suited to mechanical alteration. Other programs would not even be able to determine reliably what the files currently do (halting problem).

Is it possible that your storage device is failing, so that changes to the file system only persist as long as they remain cached in RAM? Otherwise I would be interested to know exactly what is happening to your files, and what package might be causing it.

I believe you misunderstood: Yes they are shell scripts. Nothing changes them, except the user on purpose, though you have the advantage of having to create your own, which means you have full control over what runs when X starts up always. In many Linux distros these come already created, and many do not think to look at them (I have a Linux distro that does not even have these, using other custom configuration scripts instead, I do not use said distro obviously (name not mentioned in regards to those that like it)).

Also making a reasonable change can cause significant problems, hence my statement above. Sometimes the Linux distro will restore what the configuration tools think are the correct version (and discard your change)

The relative simplicity of BSD (as modern nix systems go) brings to mind one thing that bugs me.

On a modern DESKTOP nix system that has no need for remote access (as it is a DESKTOP system), why do we still use an X Server? A Windowing system that provides the XLib API (and XCB API), though does not use a packet based display server, would seem a more logical and better option from my view. Implementing a local only, direct call Windowing System using the XLib API (with an XCB interface) seems more reasonable for a Desktop OS, my view.

That and why does everyone use X11, when many other windowing systems are available for nix systems?

From a historic point of view Unix was not designed to be a single-user OS. From a modern point of view modern desktops are networked.

While the convergence between single-user systems that can securely interact with a global Internet and the security of multiuser systems is incomplete, the idea of a networked windowing system is likely more practical than running the GUI of every application through a web browser. On the other hand, the current fashion is tools such as Electron that avoid the idiosyncrasies of individual windowing systems.

Moreover, just like a networked window system is naturally multi-threaded, those web technologies also allow multiple cores to be kept busy when running a simple single-threaded application.

Unix was originally single user, though only for two releases. It is true that newer Unix is not single user, hence why its rise as a desktop OS does not make any sense. That said there is a lot to be liked about Unix, without the multiuser support.

Networking has nothing to do with being single user or multi user. With a single user system that is networked, you just have to be sure that any software that provides for access of files, or telnet connection, etc does not provide any way for the remote connection to be able to have any other access to the computer. With Multi User systems you have to take the time to configure everything to be safe, and not allow network login (only serial and local terminal should be allowed for a desktop system). The networking argument for Multi User never makes sense when you actually look at what is being said.

A Desktop Computer (like a RPi with Display, Keyboard and Mouse) should only ever be able to be used from the local terminal, that is the connected monitor, keyboard, and mouse. Any software that allows for network control access should never be on a Desktop Computer.

The relative simplicity of BSD (as modern nix systems go) brings to mind one thing that bugs me.

On a modern DESKTOP nix system that has no need for remote access (as it is a DESKTOP system), why do we still use an X Server? A Windowing system that provides the XLib API (and XCB API), though does not use a packet based display server, would seem a more logical and better option from my view. Implementing a local only, direct call Windowing System using the XLib API (with an XCB interface) seems more reasonable for a Desktop OS, my view.

That and why does everyone use X11, when many other windowing systems are available for nix systems?

What windowing systems would they be?

Most have died to X taking over, though some examples include WISIO, NEWS, NeXT, Quarts, ALUI, and a few I can not recall the names of. Some are older than others, though in general they have short life spans, as everyone already knows and uses X, and does not want to see if something might be better. Some are commercial products, some are open source (I do not like saying was / were when it comes to software, as it is not accurate for any software that CAN still be used (even old 8-bit stuff still IS not WAS)). Of course there are more radical examples that mask that it is on a Unix like at all, for example the hosted versions of AROS.

Other examples of Windowing Systems that run on Unix include:
- WISIO
- NEWS
- NeXT
- DR-GEM (there is a Unix version of GEM/X, sources lost to time).
- Many AES Clones (that run on the 680x0 single user Unix clone MiNT).

And many many more. None are dead, some have not been maintained in a long time (no such thing as dead software, unless 0 copies remain in the world).

OOPS: An edit of my post to make a correction made a copy of the post instead. Not sure why.

[ejolson]

What windowing systems would they be?

My understanding is that Electron is a popular alternative to writing an X11 application. Thus, the answer seems to be that fewer and fewer people are using X11 on Unix with similar trends seen for the proprietary GUIs bundled on Apple MacOS and Microsoft Windows.

Alas, it sounds as if poor Wayland is dead? I live near there, I'll put flowers on its grave...

My impression is Wayland has the goal of replacing X11 with something that is simpler, faster and more secure. In my opinion, as with many efforts to rewrite existing software from the ground up, Weston sufferers by not understanding the design and scope of the software it's intended to replace.

It's also worth noting features generally outweigh security and better has to be wonderful to replace good enough.

At the same time, enough funding and work has been funneled into the project it can be used in practical cases: To

• Drive a touch screen in an automobile.
• Provide a layer to run X11 applications on SBCs.
• Allow Electron (and web browsers) an efficient way to render output on the screen.

I showed the above analysis to the dog developer for additional input, but the only reply was some growling about how FidoBasic is the killer application that will propel Weston to popularity.

[ame]

A Desktop Computer (like a RPi with Display, Keyboard and Mouse) should only ever be able to be used from the local terminal, that is the connected monitor, keyboard, and mouse. Any software that allows for network control access should never be on a Desktop Computer.

[DavidS]

As to my looking at the two BSD versions (and a few others on the side):

I have found some very good very low resource Window Managers, that I like, including a few that are just slightly extended versions of TinyWM (which I am looking at making an extension of that just adds reparenting, moving by left mouse on a title bar, better depth control, and better focus control).

I have also found information how to reconfigure BSD to be incapable of providing a network login, while still having BSD Sockets, and TCP/IP.

That said my main focus for BSD is to provide a better development environment for the future of my own project. May also use the BSD Kernel and a small number of BSD extensions to host my project, thus reducing the HW dependence (still ARM only, still RPi focused).

A Desktop Computer (like a RPi with Display, Keyboard and Mouse) should only ever be able to be used from the local terminal, that is the connected monitor, keyboard, and mouse. Any software that allows for network control access should never be on a Desktop Computer.

LOL, thank you for the laugh. I know that my statement was a bit obvious.

[ame]

A Desktop Computer (like a RPi with Display, Keyboard and Mouse) should only ever be able to be used from the local terminal, that is the connected monitor, keyboard, and mouse. Any software that allows for network control access should never be on a Desktop Computer.

LOL, thank you for the laugh. I know that my statement was a bit obvious.

Obviously wrong, you mean?

[DavidS]

I think the API as provided by XLib is actually pretty good overall. The issue is the packet protocol to interface between the client (through XLib usually) and the X Server (the display that outputs to the screen).

Why would we be using a packet based protocol to communicate between two components running on the same computer, when much better methods are available. Why not just use direct library calls (have the library that implements the XLib API be the Windowing System)? This makes much more sense for a Windowing System that is running on the same computer as the client application, and reduces the latency of communication, thus improving the experience and reducing wasted resources.

And so my above does not get lost in posting on:

As to my looking at the two BSD versions (and a few others on the side):

I have found some very good very low resource Window Managers, that I like, including a few that are just slightly extended versions of TinyWM (which I am looking at making an extension of that just adds reparenting, moving by left mouse on a title bar, better depth control, and better focus control).

I have also found information how to reconfigure BSD to be incapable of providing a network login, while still having BSD Sockets, and TCP/IP.

That said my main focus for BSD is to provide a better development environment for the future of my own project. May also use the BSD Kernel and a small number of BSD extensions to host my project, thus reducing the HW dependence (still ARM only, still RPi focused).

LOL, thank you for the laugh. I know that my statement was a bit obvious.

LOL, thank you for the laugh. I know that my statement was a bit obvious.

Obviously wrong, you mean?

LOL. Two laughs in three posts, good.

Your humor only works do to shared understanding, so for those that may have a language or understanding barrier I will help point it out. I just had someone that did not understand here in my room miss the humor, so it seems it needs explained, sorry.

The communication here is an inside, and language specific, joke. What is being pointed out is anyone that understands the systems can see beyond question of how obvious and correct the statements being made are, so the negative replies are a form of humor.