RISC OS and the IoT

I decided to split this from the Cloverleaf thread to avoid thread pollution.

Paolo wrote:

RISC OS also needs to find a market where it can be applied with the smallest amount of work. Every single Open Source OS has a market that fuel the main development: FreeBSD has the Networking market (Cisco and Juniper use/used it as the core for their Network Devices OS), Linux has the Servers/Cloud market (which fuel the whole Linux Foundation). IMHO RISC OS should engage the IoT market, obviously some people have different opinions (and I totally respect that), but unfortunately they haven’t yet proposed a valid alternative that can be achieved quickly.

One of the argument against the IoT idea seems to be fear in regards of the Desktop experience (IoT doesn’t need the desktop), if that’s really so then why FreeBSD and Linux have much more evolved desktops than RISC OS? The answer is simple, because the networking market, the server market and the IoT market do NOT prevent the Desktop improvements, actually quite the opposite. If you need to develop your solution for Linux, BSD or RISC OS sooner or later it will become easier to use such OS as main OS as well (this is not always so, but in many many cases it is). Why is that so? again simple: gaining familiarity, but to overcome the initial impact one needs to have a motivation strong enough.

Again just my 0.5c

I have noted you’ve brought up IoT as a possible target for expanding the RISC OS userbase/marketplace several times, but there seems to be many issues with this?

1) IoT is not a new platform, it is a pretty mature ecosystem with many standards and libraries that do not have ports to RISC OS.
2) I am not aware of a single existing IoT RISC OS project?
3) RISC OS does not do WIFI
4) RISC OS can not run on micro-controllers

Can I ask what you feel RISC OS can bring to the IoT market? Can you give some examples of where using RISC OS would be advantageous?

The most important thing for IOT is security and being able to automatically update to address security issues. I don’t think we are anywhere close on either.

Hi Peter,
sure and actually thanks for setting up a thread for this.

To your specific questions:

Can I ask what you feel RISC OS can bring to the IoT market?

One of the strengths of RISC OS is actually its API and the size of the overall OS. You could look at it as a Library packet of easy to use function calls, especially in asm (if we remove the WIMP it gets even smaller) and has a really good API for a lot of basic and advanced functions. The OS behaviour is also potentially very interesting, it almost behaves as a library instead of a traditional OS.

RISC OS allow a much easier way to be upgraded automatically than Linux, basically it’s just a binary in a FAT32 partition that really requires the update and then the !System in !Boot.Resources. We can modify it to be more “mission critical” and, for example, offer a backup kernel bootable in case of troubles.

It offers a lot of modules that can extend the OS functionalities and that are relatively easy to use and access (again also in ASM).

It already comes with modules that allow file fetching over HTTP/HTTPS. I also started a project to create a module that simplify such operation to the absolute easiest possible:

*HTTPToFile [URL-of-the-file] [dest-location-on-the-FileSystem]

But honestly there are multiple ways to pull down updates, it is possible even in BBC BASIC actually. And obviously we also have the omnipresent in IoT library LibCurl.

The NetworkStack is being rewritten with a full on one and ROD has done an impressive work on that regard, and the quality of the network stack matters in IoT.

Pretty much ALL boards where RISC OS has been ported so far are all suitable for IoT applications, with the various PI at the top of the list and if Stefan stops playing funky and focus his energies on the RK3399 port we’ll get another bunch of boards usable for the job.

On top of all this RISC OS allows easy access to the hardware which is a nice plus and when NOT used with the WIMP it’s actually easy to code for pretty much everyone.

Now to the RISC OS community:

Most of the people here are good with Hardware, soldering and I have seen some really good job done on writing drivers as well as SMALL applications, this clearly shows that the community strength is in small apps and low level coding, not into getting together and writing a Compositor and include all the maths involved.

Can you give some examples of where using RISC OS would be advantageous?

The introduction of iris and the already available touch-screen drivers really open up a small market on its own:

Creating Informational totems and also informational displays using Raspberry PIs 4. These are usually considered Embedded Apps. all they require is the browser to run in full screen mode and eventually implement a locking mechanism to avoid users to be able to disable the browser. RISC OS Desktop is so minimalist that actually only few keys combinations needs to be disabled, but given that a touch screen will have no keyboard it’s pretty much ready to go as it is.

Informational Screens do not even require user interaction so even easier.

RISC OS does not requires a login, nor has a complicated boot sequence (read systemd), so, for companies who develop server side content, when Iris will be solid it’ll be a very interesting opportunity to reduce maintenance costs for their screens-apps. It would be even better if extensions like Geminus could be integrated and allow 1 PI to handle 2 screens.

Also I would mention that few people have been playing with the GPIO and created some interesting PoCs (OwlArt and few others) as well as useful libraries, but more can be done.

Another strength of RISC OS is into reducing maintenance costs due to its simplicity.

For the micro-controllers:

ROOL has started to add support for such CPUs in the OBJAsm and that is strategic, because in the future, through the addition of support libraries, OBJAsm could potentially become a cheaper tool to invest on to develop code for Mx series and Thumb. Yes having an IDE would be even better, but let’s start from the Assemblers and the libraries which really are the core, since many still use editors and Microsoft VSCode for the source editing. I am also looking to find a way to transform ObjASM into a “local Service” usable via remote coding from Microsoft VSCode (my time is extremely limited and so all these ideas are being worked out in bits during the weekends). We can discuss the details of this and BTW it’s just a PoC which is mostly for the ROOL guys (when I’ll have something barely working) given that ObjAsm is not a free software.

However it’s not all good and well (as you mentioned):

1) RISC OS really needs WiFi support and Bluetooth support, these two are a must have, BUT both of them are being worked out, so it’s not something like a Desktop Compositor that is not even in the road map!

2) RISC OS might benefit from a Process Scheduler moved into its own module and usable also without the WIMP.

3) RISC OS really needs to support SMP (multi-core support). Jeffrey is working on it, so again it’s something on ROOL roadmap, not up in the air.

4) Security is an issue, Druck is correct, but what Druck forgot to mention is that Security is an even bigger problem on the Desktop (and other markets). While on IoT you have no user or very limited user interactions, and so with a solid and secure network stack, limited interactivity, reduced surface attack to the very minimum and added a “watchdog” module for the filesystem (to intercept and protect the FS from unauthorised write operations) you can actually do quite a lot with RISC OS.

For the watchdog mentioned above RISC OS offer Vectors subscription, which makes it possible to write one without changing the OS.

5) Testing, testing and testing… RISC OS really needs Test Automation, we can’t keep coding like bedroom coders (we were) in the 80s. With testing I am talking about Unit testing, Acceptance testing, Integration Testing, Regression Testing and Behavioural Testing.

Few people have tried to introduce the discussion, but honestly (and with all the respect) in most cases it kinda sounded like some semi-professional attempt or people trying to describe approaches in their own wording etc. We need to start adhering to the formal Standards and methodologies, we need to improve the tools or create them in order to adhere to the standards and not trying our own way in “bits and bites”.

Unfortunately modern Software Engineering is a complicated business, however a lot of companies in the IoT world still do things in a very much bedroom coding style (and that shows actually in quite few products), but oh well it could be seen as a way to buy time…

Now to your specific points:

1) IoT is not a new platform, it is a pretty mature ecosystem with many standards and libraries that do not have ports to RISC OS.

Yes, but companies are actively looking into ways to reduce customer maintenance costs. No operating system is suitable for ALL IoT applications:

• Some requires pure firmware
• While others do require an underlining OS
• Others require RealTime OS

IoT is a really wide market and it’s growing even more and now introducing AI/ML and edge computing.

Not trying to approach it is our fault, not RISC OS’s fault, Acorn themselves back in the days realised the potentials of RISC OS as an embedded OS, while the community insisted on the Desktop for ages getting the OS no way near to what a modern Desktop is these days and if we think improving support for IoT on RISC OS is too much work then the Modern Desktop is absolutely unreachable.

It is true that RISC OS may not be used in all subsets of IoT (for instance not on the micro-controllers and, at least for now, not in the real time applications).

On the libraries: few libraries do exists actually, libCurl is ported, there are libraries to use the GPIO and surely we can do more even on our spare time because a lot of libraries are actually quite small.

2) I am not aware of a single existing IoT RISC OS project?

What about measuring temperature using sensors and using a Raspberry Pi zero for the job? We had RISC OS Pico it was suitable, now it’s no longer maintained, but surely we can build a new distro for this, if anyone is interested we can work together on something (We all know we can just disable the desktop, so what I am talking about is an official and maintained Distro ala “Flash it and go”).

What about the small apps to access and use the GPIO? If nothing is truly available I’ll try to add some code on the RISC OS Community on GitHub, I already started and I’ll add as much stuff as I have done for everyone to use (over the years I have created and ported quite a lot of bits so I am sure there will be something useful in there).

I have seen other suitable examples, but I have forgotten, sorry :(

3) RISC OS does not do WIFI

This is true and it’s a problem! But it’s a problem for every potential use of RISC OS (not just IoT). However, it’s on the ROOL’s roadmap and that is definitely better than nothing, but you are correct, it is a problem.

4) RISC OS can not run on micro-controllers

Correct, but I have mentioned ObjAsm could be used to develop code for micro-controllers and that would be cheaper than using more expensive licenses from ARM themselves, there are plenty of IoT companies looking to reduce their DTC (Development Total Costs) however e need to add libraries to ObjAsm to offer similar convenience as ARM Dev Studio etc…

In Summary
I believe that the IoT/Embedded/Control market (even if it still presents challenges) is the market RISC OS could engage with the smallest amount of improvements.
IoT market still has a lot of one-man companies or people trying to get fast prototyping and RISC OS may be useful to them.
IoT companies are actively seeking for ways to reduce their Maintenance Costs and their Development Costs and RISC OS may be applied successfully on reducing Maintenance Costs and possibly also Development Costs.

IoT applications are also viable for schools and pretty much the majority of the Raspberry PI market is mostly focused on such type of applications and not on using the PI as a Desktop system. This could potentially shift with the Raspberry Pi 5 given that they are getting closer and closer to the MVP for a cheap desktop, but they are not quite there yet, so for now PIs are mostly for IoT, Embedded, Control applications which at this point are all IoT given that they all use the network (Ethernet, WiFi or Bluetooth) in some form or way.

As always just my 0.5c

especially in asm

I think the number of IOT devices with code written in assembler is increasingly small. Perhaps, for devices like coffee makers using a Cortex-M core, bread makers using a SAM88, and washing machines using an 8051… because these devices have, like, 256 bytes of RAM and 4K of code space with memory mapped peripherals.

But assembler for something running on RISC OS? In 2021?

Creating Informational totems and also informational displays using Raspberry PIs 4.

Possibly, but if you see these devices in supermarkets, they usually have options to start playing informational videos. Our video support…?

but companies are actively looking into ways to reduce customer maintenance costs.

Which is why it’s so often (in more powerful devices such as PVRs or IPCams) some sort of stripped down Linux (probably years out of date) with their bit of code set to run at start.

Acorn themselves back in the days realised the potentials of RISC OS as an embedded OS, while the community insisted on the Desktop for ages

Oh, wow.

CITATION NEEDED!

Acorn created desktop machines, mostly running RISC OS but with a brief foray into Unix. To my knowledge the only “embedded” device was the Acorn Communicator (based around 6502 era hardware, it was a rebadged Master Compact), various pathetically slow Econet servers (a custom board with stripped MOS in a Master Compact box), and….?
Were the STBs in Acorn’s day or did those come after?
An embedded form of RISC OS (calling itself NCOS) was in the “Bush box”. It wasn’t even an up to date version of the OS, even then it lacked fundamental requirements for the job (like proper SSL and Flash) and it was…pretty much a failure (in part, I feel, because it was dumbed down too much).

Acorn’s main focus was on replacing the armada of Beebs in schools with shiny new ARM based machines. That’s why RISC OS, mainly, and the huge amounts of support for legacy 6502 era stuff (like CALL &FFF1 in BASIC). This only started to fade away with the RiscPC when it was rather clear that the battle had been lost.
So, yes, desktop OS.

for ages getting the OS no way near to what a modern Desktop is these days

When RISC OS was first released, its desktop was ahead of the game. We had a full mouse driven desktop with outline fonts before Windows 3.1 was even a thing.

Sadly, they’ve had a quarter century of development while we’ve been reminiscing about Yazoo vs Eurythmics…

then the Modern Desktop is absolutely unreachable.

User file isolation? Process isolation? Ability to serve different desktops to different monitors? Ability to serve different desktops across a network to different users? Even something as old as XP could do that (it was quite a surprise to me to learn the differences between VNC and RDP).

What about measuring temperature using sensors and using a Raspberry Pi zero for the job?

For what purpose?

And… I could write a few lines of code and have my temperature sensor on the LAN using an ESP32. Hell, even that’s overpowered… An ESP8266 could do the job. And in both of those cases, I don’t even need to think about the OS. I just write the code for what I want done, and the build process links in the RTOS and flashes it to the device.

Consider my NetRadio (details on my blog). I used an ESP32 because RISC OS wasn’t up to the job.
Why? It was a combination of DigitalCD randomly stiffing the machine (likely since fixed, it’s been years) when playing streaming radio and the fact that RISC OS carries a lot of legacy crap. Even on a machine with hardware IIC, it insists on disabling interrupts for the duration of IIC transfers. Which aren’t terribly fast. Which causes audio glitches due to the buffer not being able to be filled in time.
All in all, it was clear that streaming radio on RISC OS was a non-starter.

Enter the ESP32, and, well, add in a few libraries and throw together some code and it actually works pretty well given that there’s zero buffering (it grabs 32 byte chunks at a time and tosses them directly at the audio chip). Since I’m using a hardware MP3 decoder, I don’t even need to worry about the processor doing that. It’s simple and effective.

That’s my €0,02.

RISC OS allow a much easier way to be upgraded automatically than Linux,

It really doesn’t!

@ Rick

But assembler for something running on RISC OS? In 2021?

Not a fan of using ASM, but it’s still being used. As a general explanation my point wasn’t on pushing developments in a specific direction, companies are free to decide what they want to use.

Possibly, but if you see these devices in supermarkets, they usually have options to start playing informational videos. Our video support…?

If you meant hardware acceleration support for video playing I am with you and yes it’s needed for everything we want to do with RISC OS, not just designing Totem devices. If you meant just Video Playing support, actually we do have video playing apps and libraries and when the videos are not too “heavy” (aka not large videos with high quality audio etc.) they work, they may not supports ALL formats on earth, but if there is a paid need for I am pretty sure the the supported formats can grow a little easier.

Which is why it’s so often (in more powerful devices such as PVRs or IPCams) some sort of stripped down Linux (probably years out of date) with their bit of code set to run at start.

Which is also never updated, buggy and still quite hard to support (we have some shocking numbers at work, in other words people using smart device are either extremely brave or totally crazy lol, but shhh we are trying to find a market for RISC OS)

CITATION NEEDED!

I stand corrected, Galileo was the OS for embedded and mobile apps, the companies who tried to use RISC OS for embedded and small Apps are Castle, Peace and few others. But given the lack of development in such a direction it didn’t go well, which is the real issue with everything: Maintenance, where maintenance means continuous improvements to stay up to date (however such activity between IoT and Desktop well it’s definitely more feasible in IoT)

Acorn created desktop machines, mostly running RISC OS but with a brief foray into Unix.

I’m afraid NO, Acorn created GEEK machines… Apple created Desktop machines, where the user did not need an Engineering degree to understand how to do things and where people could code without being either crazy or fully trained engineers. With that said I belong to the people who liked RISC OS back in the days lol

I think you’re giving the term Desktop a far too much generic meaning. The Desktop environment was created to help non technical users Rick, this is what Xerox (and later Apple) tried to push forward. Microsoft never really understood the meaning of Desktop and still nowadays they frustrate users like no one else (unfortunately).

Acorn created amazing geek machines, for geeks, for people who wanted to tinker etc… Yes at some point they also tried to push them as a regular desktops and it never really took off because RISC OS never really had all the required features for a fully user friendly desktop environment.

When RISC OS was first released, its desktop was ahead of the game.

Not really, it was ahead of PCs, that was it, not ahead of everyone else… AmigaOS was Preemptive multi-tasking from day one and supported hardware acceleration (that HW acceleration that we still do not support). Xerox and Apple did support Fonts, but hey does font support really define a desktop?? NeXT had a fantastic API and Desktop (yes NeXT count because it was founded in 1985…). So no, RISC OS was only ahead of PCs, that is the right definition, I am sorry.

Sadly, they’ve had a quarter century of development while we’ve been reminiscing about Yazoo vs Eurythmics…

On this you are spot on right.

then the Modern Desktop is absolutely unreachable.

User file isolation? Process isolation? …

I am sorry Rick… are you agreeing or disagreeing here? Not sure I understand. My point was exactly the same as yours, far too many advancements in the Desktop market to date, it will take an impressive amount of work (pretty much re-write RISC OS) to reach modern desktop OS levels.

For what purpose?

Control thermostats? RPI Zero can be used to control light strips that are so fashionable these days.

And… I could write a few lines of code and have my temperature sensor on the LAN using an ESP32

Yes you could or you could use a device running RISC OS as well, but that’s a matter of choices. My point was there are millions of RPIs out there for example, they are being used for this type of projects, they are not being used for the majority as desktop computers, so what exactly is your point?

Consider my NetRadio (details on my blog). I used an ESP32 because RISC OS wasn’t up to the job.

Sure, and what about improving RISC OS to make it up for the job? Isn’t this the point of this discussion?

@ Druck

It really doesn’t!

huh? We had more Kali Linux dead VMs due their own upgrade process that I could count. That is because upgrading Linux is far more complex than upgrading RISC OS (given the complexity of the system and the amount of drivers).

I am sure you have your motivations, so I totally respect your point, but can you explain a bit please? I am thinking that you mean the lack of a tool that makes it easy more than the technical challenges behind the creation of such a tool or am I understanding you incorrectly?

Funnily enough what really made RISC OS stand out from the Micros Operating Systems was the primitive memory protection it had, while AmigaOS, Atari TOS and early MacOS did not have it and that made them potentially more fragile.

But that feature was not “visible” or “tangible”…

From time to time I do little hobby projects on a Cortex-M CPU, specifically the NXP LPC1114. I always use C. The development environment is free (IAR Embedded Workbench, running under Wine on Ubuntu). I wrote my own RISC OS app to transfer the binary to the target device.

I wouldn’t dream of attempting to programme it in assembly language. I don’t know why anyone would.

It really doesn’t!

+1.

Upgrading Ubuntu is one click on the Software Updater (in the Favourites bar), then give it permission. Occasionally a restart is required afterwards.

I have had trouble going from 18.04 to 20.04, but all the other updates (usually several per week) just work.

Upgrading Ubuntu is one click on the Software Updater

Ok, thanks Dave, so I understood it correctly, we are talking about the updating tool that obviously is kinda missing on RISC OS. JFYI RComp does have a tool to upgrade the OS, but it’s missing the “last mile” aka downloading the updates automatically and applying them. Right now we need to download the update as a Zip and then run the auto updater.

But we can do better :)

I wouldn’t dream of attempting to programme it in assembly language. I don’t know why anyone would.

Again, I have never tried to push to code in Assembly loooool this community! XD I just mentioned that commodity for who would like to lol

/me patiently await for the next 20 comments on coding in Assembly like I meant to force it looool

It really doesn’t!

;) I have more faith in my ability to update, upgrade RISC OS.

while the community insisted on the Desktop for ages

Rick possibly wanted a citation for the above. But you’ve more than made up for it with detail I thought I’d long forgotten. Huh, to be human.

ART, Acorn made an internet fax machine and used their technology in all sorts of embedded scenarios. The IoT space is an opportunity for RISC OS. :)

@Paolo [RISC OS isn’t easier to automatically upgrade than Linux]

We had more Kali Linux dead VMs due their own upgrade process that I could count. That is because upgrading Linux is far more complex than upgrading RISC OS (given the complexity of the system and the amount of drivers).

On a Linux IOT system you set it up to automatically check and install upgrades, allowing any program, service or the kernel to be replaced. Where is the equivalent on RISC OS? All updates to the OS are entirely manual, for applications even the package manager requires a UI and much faffing, that just wont work for IOT devices.

The reason Linux is more complex; is that it can do these things, the reason RISC OS is more simple; is because it can’t.

Which is also never updated, buggy and still quite hard to support

Yup, yup, and yup.

in other words people using smart device are either extremely brave or totally crazy

Helps to disable uPNP so that only the ports you authorise to the devices you specify are presented.
Also helps to put all these things on their own subnet, but your average home router isn’t that smart.

Apart from a camera, I don’t run any IoT device I didn’t make myself. And I’m playing with ESP32-CAM to see if I can make my own there too (my current camera seems pathologically unable to write local snapshots to a local SD card without having a cloud subscription, I’m sure you can guess where that idea can go put itself).

I’m afraid NO, Acorn created GEEK machines… Apple created Desktop machines, where the user did not need an Engineering degree to understand how to do things and where people could code without being either crazy or fully trained engineers.

I’m afraid even more NO. Acorn created desktop machines that tried very hard to leverage the history of the BBC Micro. Maybe not in your country (I’m guessing you’re Italian?), but in the UK the Beeb was in many many schools thanks to a BBC initiative. A hell of a lot of kids understood some sort of BASIC (usually either the Beeb or the Spectrum) and an Archimedes was like a really fast Beeb (along with the big price tag).

Apple probably had some decent machines that cost the earth, but the typical Mac of the time but the machine I saw the most of (a friend at boarding school had a father who wrote books on Mac, so he brought in his computer as I did with my A3000) was that dinky all-in-one thing with the monochrome screen. Google tells me it is a Macintosh SE/30 which had a pretty decent spec and an equally decent price tag – the 1MB floppy only model cost four times what my 1MB A3000 cost.

He didn’t program anything. His father had a ridiculously expensive C compiler, but it was all gibberish to him. Me? Back in those days you got type-in listings in BBC BASIC in monthly magazines. No astrophysics degree necessary. Except in the case of Jan Vibe who could make impressive graphical oddities in twenty lines of BASIC containing advanced magic.

and it never really took off because RISC OS never really had all the required features for a fully user friendly desktop environment.

It was in many ways superior to Windows which did take off. Because that was the end of the home computer era and the start of the computer-in-the-office era. It wasn’t too long before “does it run Word?” was what people were asking. They didn’t care what sort of 386 or 486 it had, they just wanted it capable of using the same shonky software everybody else was using. Even Mac had a version of Word (and Excel, etc).

RISC OS, being a little British oddity, did not. That was the problem. Not in whether or not the desktop was any good, or how many bits the processor had, but simply it didn’t use the software that was calling itself “industry standard” (defined as “the crowd is using it”).

hey does font support really define a desktop??

Depends, I guess, on whether or not you’d want to gouge your eyeballs out rather than subject yourself to Microsoft’s pre-ClearType efforts at font rendering.
I guess the sad thing is that the people who grew up without RISC OS (and seeing how it could look) simply didn’t know any better.

AmigaOS was Preemptive multi-tasking from day one and supported hardware acceleration.

Sure, but Workbench was a bloody awful desktop. I think Workbench only existed as a minimal GUI in order to try to pass itself off as “look, we’re more than just an awesome games machine”.

are you agreeing or disagreeing here?

Agreeing, because there’s so much of the fundamental architecture that doesn’t lend itself to the sorts of things people expect nowadays. And I don’t just mean in the desktop, the entire system.

Control thermostats? RPI Zero can be used to control light strips that are so fashionable these days.

I’d thought, in the past, about the possibility of using a Pi (Zero) as a washing machine controller. I might have discussed it on my blog at some point. Suffice to say it’s basically five devices (motor, heater, inlet valve, drainage pump, and door lock) and three sensors (water low, water high, temperature (analogue?)). Ought to be doable routing GPIO to MOSFET to switch relays, or hooking sensor to GPIO. Then a BASIC program can cycle through the motions, it’s basically a set of blocks (fill, gentle intermittent tumble, drain, spin, repeat a bunch of times) that run in sequence.
But I’m not sure I’d entirely trust RISC OS to be in charge of a 2kW heater. When things go wrong, the system has a habit of just freezing. There’s no background watchdog to even force a reboot (and at least bring the system back to a safe state with the motor, fill, and heater turned OFF).

That’s not to say it cannot do it, but your machine having twenty days uptime serving web pages isn’t quite the same degree of “this must not fail” as a machine controlling hardware that could easily burn the house down.

Yes you could or you could use a device running RISC OS as well

Really? Because from where I stand, adding WiFi has just tripled the cost. And if the devices are geographically separate, well, all those Vonets devices and all the extra cost and power bricks. Or a mess of Ethernet cabling.
Versus a little gizmo for under €10.

That’s not to say that RISC OS cannot make inroads in embedded space, it has a GUI which is more than the ESP32, however work is needed.

Sure, and what about improving RISC OS to make it up for the job?

I’d imagine Jeffrey is working his way through the mess, as you really don’t want to be randomly bashing off interrupts at the drop of a hat in a multiprocessor setup.
(the interrupt behaviour is just a lazy way of not having to deal with concurrency)

Isn’t this the point of this discussion?

I think the first part of the discussion is to define exactly what we mean by terms such as “embedded”. My soldering iron contains an embedded 8051 core. Those big touch panel ordering gizmos in the burger joint of your choosing are the other extreme. Where would RISC OS fit in?

Upgrading Ubuntu is one click on the Software Updater (in the Favourites bar)

Ubuntu isn’t traditional IoT. A lot of those sorts of devices are running a stripped Debian with no UI. Think of a little tilt and turn camera. That’s controlled through a browser. And yes, they pretty much all have some way of updating (but you have more chance of seeing an actual unicorn than any updates) which usually amounts to the rather horrific practice of unpacking a zip file directly into the filesystem and then forcing a reboot. Even more horrific when you consider that quite a number of these devices will unpack any old crap. It’s no wonder they’re easily pwned.

loooool this community!

You mentioned programming in assembly several times. We’re trying to tell you that in 2021, nobody uses assembly unless there is literally no other choice. We’re even being polite about it. I can imagine some places would be…less so.

To give an example, somebody created a replacement ROM for a French Minitel terminal (based upon an 8051). It is a graphics demo that cleverly abuses the redefinable character set to make it seem like the (essentially dumb) terminal is doing impossible things. It is written in C. https://github.com/jfdelnero/minitel/tree/master/minitel2/the_minitel_demo

I know you weren’t trying to push assembler, but these days it’s really not a promotion point. Not unless you’re into retrocomputing and bare metal fun.

The reason Linux is more complex; is that it can do these things

And along come the Chinese that vomit out millions of devices where “these things” have been removed (use too much space on the flash) and replaced by half assed insecure crap. I’ve already mentioned unpacking files directly into the filesystem. I’m sure there are some generic flash updaters out there that are even worse.

Example? Try my PVR, the Neuros OSD. It had updates that comprised of three optional parts. The bootloader, the system config, and “everything else”. Now normally the bootloader (a hacked version of U-Boot that could perform a flash update) would be left alone and you’d just reflash the application part. Except, it seemed something was fiddled with in the bootloader which meant that almost every update had a new bootloader. So suddenly your safety net (crash or power failure while updating? just reboot and do it again) was gone because the bit that shouldn’t have been updated much often was.
I have a second OSD here. It doesn’t start up. The person who gave it to me suspects that there was a brownout during reflash and the bootloader is corrupt, if it even got as far as writing anything at all. There’s no sign of activity, nothing on serial. It’ll be a JTAG job to see what, if anything, is going on.
That’s a device running Linux. As are my cameras. One with a flaw so utterly bad that I won’t let it talk to the internet at all (I don’t use it these days).

It doesn’t matter how great Linux update is if somebody removes it and replaces it with shit that would shame a reasonably bright primary school kid.

The Desktop environment was created to help non-technical users Rick, this is what Xerox (and later Apple) tried to push forward.

Funny you should mention Xerox. I recall the tales of the nascent ARM chip era, with guys from Xerox visiting Acorn…

I’m afraid NO, Acorn created GEEK machines

I’m afraid even more NO.

It is amusing that first you disagree, just to follow up with a description of all the geeky stuff you did with RISC OS, while the MacOS owners did no such thing :-)

all the geeky stuff you did with RISC OS

Well, that’s because I’m a geek (and proud of it), but Acorn didn’t make their computers just for me…

(I’m guessing you’re Italian?)

Yup and I technically grew up with Acorn… but it was called Olivetti Prodest XD… Never mind a tale for another time!

Beeb was in many many schools thanks to a BBC initiative

You’d be surprised about how much I know abut the Beeb and also the fact that not every schools had them (due the price apparently). I still own quite a collection of Acorn stuff, always loved them… why? because they always been the geekiest computers on earth!

Want to talk about the Tube???? Well it actually was more of a legend when we were kinds because none had the money for one of those Co-Processors… but now I run a full 1.4Ghz ARM on my Electron! :D

The user port, the analog port and even a power socket to do what exactly???? ;) And this in a time where the average micro had only a bus expansion and, eventually, a printer port…

Anyway time pass by and the geekiest engineers on the planet who even came up together through a computer club created the most impressive machine of the time… the Archimedes which was roughly 4 times faster than the average 80286, it was capable of 256 colours in high res (well high res for the time) when the most advanced graphic micro was the Amiga 500 and was capable only of 32 colours…

anyway we are talking about IoT!

PCs started to sell thanks to Amstrad and few others that started to produce them in the far east and for very cheap money, that actually kicked out of the scene even IBM and Olivetti, AST, and few others that did not adapt fast. Microsoft just got lucky because the clones needed an OS that had Applications and MS-DOS was that OS. When PCs got that cheap and Intel was still producing the CPUs Intel got so much power and Microsoft together. so many more people writing apps for the PCs did the rest. The story of Windows taking over is just plain bollocks (excuse my directness). Microsoft themselves were about to abandon Windows when finally Cuttler and Co. got the memory management right on guess what? Windows 3.11! :) Before that coding on Windows was a total pain and I am talking by direct experience.

The SVGA and PCI did the last bit together with Intel introducing micro-code to overcome the limitations on the CISC design (btw AMD did that before and used their 29K RISC core concepts to process the microcode for their K5 and K6, this is where the legend that all CISC are now RISC comes from, while Intel opted for a VLIW approach). IIRC the very first company to produce a CISC with micro-code was IBM…

Anyway back to the discussion and no don’t inspire me to talk about CPUs pleaseeee :D

Sure, but Workbench was a bloody awful desktop. I think Workbench only existed as a minimal GUI in order to try to pass itself off as “look, we’re more than just an awesome games machine”.

Correct, but Amiga OS had also a proper modular architecture and that helped AmigaOS to survive to this day and it look much prettier now. It was a good design. the only issue with the Amiga was the way they had to compromise on the architecture of the hardware, but that was because half of Amiga Inc. wanted a computer and the other half a console… and that caused quite some painful bottleneck (again a tale for another time)

Really?

Yes, there are still IoT people using FreeDOS, hence RISC OS is fully respectable lol. The fact that you personally prefer a different approach doesn’t mean everyone does, FreeDOS is the proof :)

When you work in cyber security it’s like the guy who knows all the “naughty stories” of the town lol IoT is something I’ll write a book about when I am old and retired (especially retired!)… I am pretty sure that Monty Python would love the material XD

Not unless you’re into retrocomputing and bare metal fun.

Ermmmmm lol tries to remove all the assembly material on his blog loool but yes I am into retrocomputing and also FPGAs, with one of my favourite CPU ever the MC6809 :) BUT, again, did not mean to push for Assembly here.

And along come the Chinese that vomit out millions of devices where “these things” have been removed (use too much space on the flash) and replaced by half assed insecure crap.

Yup and please also add Cooperative Scheduler on some and even badly code drivers, those are the best… oh and the buggy WiFi and don’t forget the constant messaging back home on the server using HTTP so Philips and also all the ISPs along the way knows when you’ve bloody turned on that light! XD

It is amusing that first you disagree, just to follow up with a description of all the geeky stuff you did with RISC OS, while the MacOS owners did no such thing :-)

It may be more common now, but back then (and though into this century) I never met a MacOS user who knew how to do geek things.

Two reasons:

1. Apple made the Mac rather opaque, so the average user clicked the one mouse button (wondering why others had more and why they had RSI) and did the things Apple offered, end of.
2. Even the users with a geek chromosome found that digging under the gloss gave you a view of the next layer of opaque