How about...

I wonder how well RISC OS would run on this:
http://arstechnica.com/gadgets/2014/10/testing-a-35-firefox-os-phone-how-bad-could-it-be/

(FTAOD I’m not being completely serious here ;-)

Assuming we had the hardware drivers, and apart from the lack of a touch-friendly UI, I think it’s safe to say that RISC OS would run a hell of a lot better than any other OS. I know Firefox OS isn’t exactly stock Linux and so they have more scope for tweaking things (even if that article suggests the performance isn’t there yet), but I think I’m yet to see an ARM device where a GUI Linux distro runs well. They generally either choke waiting for slow file I/O, or have terrible SoC driver support (display fixed at one resolution, flickering mouse cursor, etc).

I was curious about the ARM OS for “Internet of things”
Do you think in some respects they are re-inventing the wheel?

Well, it’s certainly not a competitor to RISC OS or Linux; it’s only going to be used where regular Linux won’t fit in memory (Cortex-M0/M0+ devices) or where you have really (really, really) good reason not to use Linux.

It’s not even an RTOS (which is normally what you want in low end embedded devices; so I don’t see the point. It’s another one of those answers to a question no one asked imho. Nice marketing though :)

With processors like the AM335x 1GHz ARM Cortex-A8 (like on the Beaglebone black) it’s even more questionable. Those have 2 PRUs for doing realtime work; so the CPU runs non-realtime Linux whilst the PRUs take care of the realtime stuff. Now that’s a cool approach (and supported by Linux iirc).

I’m no guru on mbed OS, but doesn’t look interesting to me.

Assuming we had the hardware drivers,

That’s a pretty damn big “if”, unfortunately. We’re still doing video decoding in software on the ARM core!

and apart from the lack of a touch-friendly UI,

Well, shouldn’t be too hard to plumb in something, should the need arise. I’m not certain how to handle aspects of the UI (pop up menus vs clicks – long-tap perhaps?) but I don’t doubt that something could be devised. And better yet, if somebody thinks the arrangement given sucks, they can just “write a better module”.

We have precedence for GUI use in a non-standard way to present a slick UI – the Bush Internet box.

I think it’s safe to say that RISC OS would run a hell of a lot better than any other OS.

Depends upon what you want.
If you want something light and nippy, we are so far ahead of the crowd it is bordering on being silly.
If you want something secure, rather the opposite. That said, now that Linux is an acceptable target, flaws are cropping up almost as fast as Windows zero-days. Where there’s a will (and a pile of criminals going kerching)…

but I think I’m yet to see an ARM device where a GUI Linux distro runs well.

I will mention my PVR (again!). It is based upon a DM320TMS320 chip. As is a cheap Chinese device. The technical hardware differences between the two are slanted in favour of the Neuros OSD (has Ethernet, has SD/CF/USB, has s-video input, has…). I suspect the OSD also has more RAM.
The OSD runs a version of Debian with a Qt4 based UI. It overflowed the 16MiB FlashROM so needed some resources to be put on the CF card. It boots in, maybe, 2-3 minutes. Pressing the REC button loads the recording application. Time between button press and recording starting is in the order of 40 or so seconds. If, during recording, you press the ‘?’ button to pop up the on-screen status, you will need to wait approx. 20 seconds (sometimes longer) before anything appears. Subsequent ‘?’ presses are more responsive and status can pop up in a second or two.

The Chinese version runs a custom OS that I wouldn’t be surprised if it wasn’t cobbled together from TI’s evaluation kit for the chip. The OS runs to approx 6MiB (working on how big the “update” would expand to if unzipped). Power-up to usable UI is in the order of ten seconds. I have not timed it accurately, I plug in the power, I press the power button on the top to bring it out of standby (more LEDs light up), it is already ready. The display is ugly-as-sin bitmap fonts and line drawings that you could do on a BBC Master. However, pressing REC takes effect in seconds. This is good, as the Chinese PVR stops and restarts recording in hour-long chunks and when it can do it quickly you don’t miss much. I think if the OSD tried that, the cycle time would be in the order of two minutes. On-screen status on the Chinese device is immediate.

I remind you, a comparison using the exact same chip; if anything the OSD will be higher spec (faster clockspeed).

Linux offers a lot (much better UI, more comprehensive facilities) but you pay. In responsiveness, the Linux device is a LOT slower.

I use the OSD because it offers AAC audio recording, and a choice of bitrates. Plus it doesn’t mess severely with R4LW (the Chinese box does, implies a different clock speed, and given the OSD is the fastest DM320 available, the Chinese must therefore be slower).

or have terrible SoC driver support (display fixed at one resolution, flickering mouse cursor, etc).

I give up on Angstrom on the Beagle xM, it kept complaining about not being able to configure itself with no additional information. Using a fresh install changed nothing. Shame, it would have worked well on s-video output which is more than can be said for other OSs.

Do you think in some respects they are re-inventing the wheel?

I think the point is to design a “reference” platform so code using the IoT OS will “just work”. The stuff specific to each SoC can be hidden away. Remember – the ARM chips have no coherent auto-probe support and all of the bootloaders are different, which is why we must download a version of RISC OS for each specific type of device. Unlike, say, an x86 PC where the machine boots up with the processor operating in a compatible way with a BIOS for gleaning basic info plus probable ports (and PCI) to determine what devices are present.

Personally, I think having the on-chip startup code fill in a data array indicating device capabilities would be a better approach (means you aren’t tied to a specific OS), but it’s a start at least. And for people who don’t really care what the OS is as long as the software works, it may be quite a positive step forwards.

where you have really (really, really) good reason not to use Linux.

I am keeping my eyes on this. Linux is quite bloated these days, it may just be possible for something small to come along and steal its crown.
I will give you an example. At work we have some PLCs with a UI. The UI looks suspiciously like the “QuickWin” that you used to get in the Windows 3.1 era. It responds to (resistive panel) touches and changes UI elements and transmits/receives serial data to/from the attached controller logic. Personally the idea that the emergency stop button is wired to a gadget that spits serial data to the PLC that stops all operation by spitting serial data back to the other gadgets freaks me out, but it works.
Anyway, this is an example of something where Linux would be hideously unsuitable. You will want comms, video framebuffer, some UI elements, touchpanel support, and – frankly – not much else. I think even a full install of RISC OS would be too much.

That said, now that Linux is an acceptable target, flaws are cropping up almost as fast as Windows zero-days.

Apple Mac – what’s the figure for the recent malware discovery? over 17,000 machines infected and running the little blighter.
No, no, Apple don’t have security holes because it’s a locked down OS restricting user access…

Hi, still awake. Actually I feel better now than I did at 5pm. Maybe the beer helps.

I think even a full install of RISC OS would be too much.

You’re probably right there (and about Linux being too big). That’s why I think an RTOS would be preferable. There are quite a few around and they make desktop OSs look like gorillas :)

Once you step up to the more ‘capable’ ARM devices then embedded Linux becomes the better choice (and it’s widely used in that space). There is a very narrow gap between bare-metal C-code microcontrollers and the bigger ARM devices; not much of a wedge for mbed to exploit and there a number of RTOS projects already filling it.

As for security, well that’s a case of viewpoint. Bigger OSs have more known attack vectors, but they get fixed fast. Security through obscurity is a nice theory, but it’s not proved very effective in the past. The tools required to analyse any device are getting cheaper and more capable – for many security hacks it’s a point-and-click discovery – doesn’t matter what the OS is. Also most OSs have commonality in their communication stacks (like NetBSD based drivers for example), so it doesn’t play out well in my mind.

It will be interesting to see what happens with mbed though; it seems to be generating quite a buzz at the moment.

Security through obscurity is a nice theory

That’s the funny thing, in the RO world people tend to talk frequently about the problem we have with security and how Linux/MAC OS etc are so much better but it seems, like Rick commented, that that is just hype/bluster from the OS devotees over there.(whichever “over there you select”)

Basic statement of fact no one should be smug.

Basic statement of fact no one should be smug.

Spot on… it doesn’t matter which way you turn there are no guarantees.