No more big 32-bit cores for RISC OS from 2022

he point is, as long as there is neither a common idea of where RISC OS should be heading or willingness to let go of how things used to be done

I don’t think it will ever become a reality. All projects, including Linux, are not a “hey guys, you don’t know me, but I have a very clever idea. Forget every things you know and use, and follow me.” Success = 0. The right way is:

  Hello everybody out there using minix -

  I'm doing a (free) operating system (just a hobby, won't be big and
  professional like gnu) for 386(486) AT clones.  This has been brewing
  since april, and is starting to get ready.  I'd like any feedback on
  things people like/dislike in minix, as my OS resembles it somewhat
  (same physical layout of the file-system (due to practical reasons)
  among other things).

  I've currently ported bash(1.08) and gcc(1.40), and things seem to work.
  This implies that I'll get something practical within a few months, and
  I'd like to know what features most people would want.  Any suggestions
  are welcome, but I won't promise I'll implement them :-)

When one want something, must of the time, the best way is for him to do it :)

Oh, and David, you’re missing the point I’m making.

And you mine. No desktop OS has future. Not a single one.
Except the one that will focus on workstation ecosystem (macOS).
And – for a time – the one that relies on the fact that some need Office (Windows).

Really, I work with a lot of people and companies. Since years, we all only use two applications: Office, Chrome (me: Firefox and LibreOffice).

That’s the very point I’m trying to make.

Ah. OK :)

new OS is designed and built from scratch with built in seamless emulation for the older applications

Unfortunately, I’m still sure it’ll be easier to use and existing OS “with built in seamless emulation for the older applications”. I really don’t see the point to have a modern OS with Wimp (use ROX) or a modern OS with modernized Wimp (use Haiku) or – sarcastic mode – a new RISC OS with only applications ported from Linux.

But I’m certainly wrong.

Even if I prefer to say that a 3.5 GHz 8 core processor will be really enough for me under RISC OS… as far as I can see.

…discussions that often seemed to be rooted in nostalgia and resistance to change…

Not to mention nostalgia that seems rooted in the wrong area. Cooperative multitasking is better because is just is! Anything besides assembler isn’t proper programming, and doesn’t belong in an OS! Yes, from a certain perspective it is horrendously insecure, but it should be like that because it’s flexible!

Edit: I’m exaggerating here for rhetorical effect, but I still think there’s some degree of “that’s the way it’s been done, and that’s the way things should be” thinking, that goes beyond the practical issues of implementing such changes.

No desktop OS has future. Not a single one.

In what sense? Are you predicting the death of desktop computers as a physical device? Or do you see them as becoming little more than terminals for web apps?

Not to mention nostalgia that seems rooted in the wrong area.

Interesting

Cooperative multitasking is better because is just is!

Did I imagine a whole collection of threads where people advocated pre-emptive where the only difficulty people saw was that every app expected co-operative and that something inventive was needed to get past that problem.

Anything besides assembler isn’t proper programming, and doesn’t belong in an OS!

Having at least half an understanding of that level is useful, but I think pretty much everyone here wants to use something higher.
Me? At college, I could do the Z80 assembler “homework” on split beermats down the pub (not that it pleased my lecturer), I get by in BASIC and I seem to have a mental block with C beyond very simple stuff, but I do advocate using C or similar for RO source. I don’t think I’m alone.
The only reference to assembler on a purist basis I’ve seen was a reference to someone who hasn’t done anything in the RO world in a long while (not this millennium I think)

Yes, from a certain perspective it is horrendously insecure, but it should be like that because it’s flexible!

That one’s a quandry. If you want people to learn about the innards of a system you can’t lock them out (teaching). If you want an OS that you can be sure won’t allow Jo Hacker to steal data/info/money… then you must lock it down. Somewhat incompatible, perhaps there should be two streams.
I don’t think anyone here is suggesting the system should be wide open if it is to be used for normal daily tasks.
Those aspects aside I don’t think I’ve seen people suggesting we must leave RO insecure – just the opposite.

Charlotte – what’s your basis for the comments?

I don’t think I’m alone.

I can confirm that you are not. I don’t think it’s just two of us, either. Well, except I never did Z80 assembler – PDP8 assembler then 6502.

Steve Pampling:

Charlotte – what’s your basis for the comments?

As per my edit, I was exaggerating for rhetorical effect. I fully appreciate that PMT, portability, and security are widely discussed, are on many people’s wish-lists, and that the biggest obstacle is lack of investment. However I also perceive a slight air of “puritanism”, for want of a better word. Although maybe it’s because I have a “who cares what’s under the bonnet so long as it drives?” attitude.

I don’t think I’m alone.

I leant a bit of BASIC in the Sixth Form in 1972 (using a time share terminal at the local CFE). I learnt BASIC and FORTRAN at University in 1973-1976 but I had to make do with a programmable calculator (HP25 then HP19) until I got my first computer in 1978 (a CompuKit UK101 – 6502), then a Nascom 2 in 1979 (Z80), a BBC computer in 1982 (6502 again) and an Acorn Archimedes in 1988. Machine code programming was essential to replace bits of the firmware that did not come up to my requirements – adding structured commands to UK101 and Nascom Microsoft BASIC like WHILE/WEND, REPEAT/UNTIL, adding file date stamping to CP/M and making discs interchangeable between BBC Z80 CP/M and Nascom CP/M. Also making the Z80 editor assembler package (Zeap) run under CP/M and produce a cross reference assembly listing.

I tried Pascal once and found it too irritating (variable types were ultra strict) and I never got on with C.

Its true lack of investment is the main issue, but we also need investment in application development, and to get people interested in that under the bonnet of RISC OS has to become closer to the experience on other platforms; i.e. some sort of IDE, PMT and not falling over at the drop of a hat. At the moment developing for RISC OS is so far removed from anything a mainstream developer will have experienced, it’s completely off putting.

At the moment developing for RISC OS is so far removed from anything a mainstream developer will have experienced, it’s completely off putting.

I talked to an Amiga developer some time ago who was writing a new game for a “base config” Amiga 500 with 512 KiB of RAM and a single floppy drive. He was one of those developers who does embedded software development for a living, and only played with the Amiga of his father as a child, so had no actual experience of developing on and for the Amiga.

So he took whatever he was used to (GCC, Visual Studio, Git) and developed and cross-compiled from his Linux-based setup. In C++. And the result is impressive (the game is called “Tiny little slug”, there are screenshots and videos everywhere on the net).

I think that a lot of the problems that plague RISC OS at least on the application side of things are a result of the fairly common idea that the development tools running natively on RISC OS are in any way “good enough”. But this is only true for clever people who are used to make something with basically nothing. Yes, you can do great stuff with BASIC, the DDE, Zap and StrongEd. And porting any old library yourself or reinventing the wheel instead. But it takes a much longer time than necessary.

In what sense? Are you predicting the death of desktop computers as a physical device? Or do you see them as becoming little more than terminals for web apps?

The second option. And in fact, for a bunch of people, they are terminals for web apps.

@Steffan, both Discknight and ARMalyser have mainly been developed and debugged on other platforms, as they are command line tools only dependant on OSLib (of which I have a cross platform port of a small number of functions). DiscKnight does have a toolbox based front end which luckily hasn’t needed to be touched since 2000, but I’d be really stuggling to create anything even as simple as that these days.

@ David F.

The right way is:

Agreed, that was my original point on “ides and ideals”, can we (as a community) think of a set of ideas and ideals for RISC OS, beside “will RISC OS NG runs !Eureka?” and things like that please?

New users may not even care about Eureka, that’s just us the old users and it’s fine and it’s great to see the effort of ROOL/RComp/CJE/RODev/others to keep the past alive. But new users and developers may need different things and to join a project people want to know WHY should they join it and HOW.

just my usual 0.5c

@Steffen I wrote a cycle accurate cross-assembler to allow Superior Software Speech! to work on an Archimedes (same low quality 8KHz 4 bit sound), but that was fun as you could get it to swear.

That was the only thing which was intelligible, so you can tell what the testing was aimed at.

I suspect doing the same for Zap would cause you to swear.

so you can tell what the testing was aimed at

Training parrots?

The idea of a desktop OS will be probably forgotten (or legacy) in 2030.

Wait, no! The year of Linux on the desktop still hasn’t happened yet! ;-)

On the contrary this is probably the best way migrate development from one toolchain to another,

The problem with that approach is that it foists all of the additional dependencies of a second toolchain onto a group of people who do not need it.

Seriously – I don’t have GCC here. I have the DDE, so I don’t have a need (I’m not interested in C++ and GCC can’t build the OS yet).

That’s not to say that I disagree with transitioning to GCC, it’s just that maintaining two different toolchains side by side might be something of a chore. And, anyay, nobody has yet mentioned if the current GCC still supports ALF. If not, it won’t easily interoperate with the DDE.

a “hey guys, you don’t know me, but I have a very clever idea. Forget every things you know and use, and follow me.”

To underline what David is talking about, we’ve had our fair share of trolls that come along, announce grandiose plans for the future of the platform, get abusive when called out, and usually end up mumbling about either autism or aspergers as some sort of get-out-of-jail-free card.

Case in point, we had one guy who felt that the best thing for the future of RISC OS was to adopt the DOM model.
DOM model. As in web browser. How the heck does one apply something like that to an operating system ? His reply on being called on that (by Yours Truly, of course) was to delete most of his posts.
<shrug>

My opinion now is that I don’t care what people think. Show me the code, then we have a foundation upon which to build. Because all the chatter in the world won’t change anything. Trust me, I know, look at my post count. ;-)

No desktop OS has future. Not a single one.

I am mostly in agreement with this, but I would widen it to say that in the future, the OS will be irrelevant. I’m going to say all of them, not just the desktop ones. They will become a platform upon which services run. Netflix, Facebook, some sort of browser, and whatever other social media crap is trendy right now…what’s the one where people take photos of themselves wearing “vintage clothes” from charity shops and endless pictures of what they’re eating?

We can see a beginning to this already if one looks at, say, the Docs app from Google. It functions, but it is actually a bit shit. I’m being polite, by the way. Because if you want to do pretty much anything more than write a basic document with a default template, you’re best using the web version in the browser, which actually looks and functions like a proper word processor (with menus and everything). I think, rightly or wrongly, this is the way things are going.

The only saving grace is that there might eventually be some sort of pushback as people start to realise that shoving all their personal stuff “in the cloud” isn’t a great idea, and when companies do a bait and switch like making people pay for what they used to offer for free. Or the previously competant Firefox being replaced with something rather rubbish that breaks ad-blockers which may or may not have something to do with a large pile of kerching! each year from Google to the Mozilla Foundation.

That’s not to say that RISC OS has a place in this discussion, but I would be surprised if Linux as a desktop OS disappeared.

I’m still sure it’ll be easier to use and existing OS “with built in seamless emulation for the older applications”.

That’s the realistic outlook, to be honest.

I really don’t see the point

Sometimes the only answer to that is “because”.

After all, why did Linus start writing Linux? To requote what you quoted above: (just a hobby, won’t be big and professional like gnu) – he pretty much did it “because”, and now it’s possibly the single most important platform on the planet. Won’t be big and professional like GNU? It’s everywhere. And it started, more or less, “because”.

Yes, from a certain perspective it is horrendously insecure, but it should be like that because it’s flexible!

Yes, I mentioned that an attraction is that RISC OS is easy to hack around with. And it’s about as secure as a paper towel wrapped around a nuclear warhead. As I said, getting those two points of view to coalesce will be…interesting. ;-)

a result of the fairly common idea that the development tools running natively on RISC OS are in any way “good enough”.

That idea struggles somewhat when it comes time to debug stuff. The official debugger is more prone to falling over than the OS, and everything else is pretty much spitting data at the screen / DADebug / a serial port / Reporter (or some unholy combination of the aforementioned).

And worst of all, there’s no way, without delving into hardcore machine code, to run the actual executable in DDT. When you build a debug version, the code can be significantly different to non-debug code, which might matter. Especially when trying to track down some zero page issues.
To be honest, the simplest way to deal with those is to set the Debugger to output an annotated dump, and then just run the app until it crashes, and see what the dump says. Sooooo very sophisticated. :-/

At the moment developing for RISC OS is so far removed from anything a mainstream developer will have experienced, it’s completely off putting.

I still maintain that the licence / toolchain / documentation / primitive build environment / etc is going to be less offputting than the realisation that in order to make a dent in any of this, it’ll potentially require understanding hundreds of kilobytes of assembler…

sort of pushback as people start to realise that shoving all their personal stuff “in the cloud” isn’t a great idea

My thunk precisely.

“Yes, I mentioned that an attraction is that RISC OS is easy to hack around with. And it’s about as secure as a paper towel wrapped around a nuclear warhead. As I said, getting those two points of view to coalesce will be…interesting. ;-)” Please leave RISC-OS like that. I like an OS which I can do what I want with. Where I can have fun with fiddle with hardware etc.
Yes we should try to port RISC-OS to 64 bit and what is wrong using assembler to do that ;-) ?.

@ Rick

Yes, I mentioned that an attraction is that RISC OS is easy to hack around with. And it’s about as secure as a paper towel wrapped around a nuclear warhead. As I said, getting those two points of view to coalesce will be…interesting. ;-)

Totally on board with this statement. RISC OS has no system auditing, no SELinux-like policies, no FS complex ACLs, no full memory protection etc… and this allows people to write even a multi-tasking scheduler in BBC BASIC! with no libraries dependence or write games that access the HW directly (old school) or even write new programming approaches not easy to implement on protected systems and that’s what RISC OS is fun for me as well.

However, with the mission to make RISC OS a daily Desktop for everyone, comes the first big “requirements collision”. Daily Desktop:

• As easy and intuitive to use as possible (because the average Jo will buy it and then hunt you forever with questions lol)
• As stable as possible (nobody like to lose their work because the OS frozen given the lack of control of apps)
• As secure as possible OS and Apps (without making the OS impossible to use, which per-se is going to be an interesting challenge too)
• With plentiful of libraries and API built (and possibly as stable as possible), because many modern developers wants everything built for them and just glue libs together and make an app
• With loads of available apps because general users just want to search now on the App Shop and download when they need either for free or paid very little (AppleStore to look at) and, if paid, pay it now and download it now too (not when the payment will be approved)
• With modern UIs and possibly an AI (Siri, Cortana) to ask stuff instead of even searching for it using the keyboard
• With AAA Games, not some retro-game available via ADFFS
• With professional apps that are, at least compatible in the file format, with the usual names (Corel, MS Office etc…)
• With VPN access client (before and now with Covid even more) people need to work from home using corporate VPNs
• With good documentation on-line (yes this is so also for Linux, it really started to spread widely only when documentation started to appear on the internet)

So if it’s daily Desktop then I guess we’ll have to lose the easy to hack OS, unless we want the Daily Unstable Desktop :D

There is more, but I think we all get the picture. Plus Rick mentioned something interesting, why don’t we have a competitive Linux Desktop? It has been in the making for years and years now, and it never gets to the final point, the reason is simple, there isn’t a profitable market interested in it and Linux, as any OSS object, expands and grow only on markets that needs it, not everywhere.

P.S. I am not against RISC OS as a desktop new star, but how the approach to reach such a goal should be tackled?

“Daily Unstable Desktop”? Pish. We’ve had people successfully running businesses on Archimedes and successor systems for decades.

Stuart, you’re an Acorn programming God. Is there any possibility that you would ever work help 64-bit RISC OS or convert some of the ARM modules to C/C++? I realise I’m probably clutching at straws but thought I’d ask anyway.

Ha ha, Alan. I am probably in a minority that thinks it would be easier to port most of the OS to AArch64 directly – with no adding new features – rather than redoing in C. Whether a RPCemu-A64 would be good enough to keep non-ported apps going, I don’t know.

and usually end up mumbling about either autism or Aspergers as some sort of get-out-of-jail-free card.

Aspergers? A get out of jail free card, in a techie forum?

So if it’s daily Desktop then I guess we’ll have to lose the easy to hack OS, unless we want the Daily Unstable Desktop

I did say earlier that we need two streams to meet the divergent requirements.

Initially:
ROplay – boots insecure and can only read the non-encrypted partition
ROserious – boots secure and can read the encrypted partition (and the other too?)

Encryption/Decryption is handled by a module in the ROM.

Feeble starter only because although the disc contents are being locked you don’t yet have any iota of in memory security.

Any handy, open licence encryption that will sit in a tiny module?

@Stuart
You never said no. I’ll take your response as “I might be interested in contributing some effort”.

David:

hey guys, you don’t know me, but I have a very clever idea. Forget every things you know and use, and follow me.

I’ve been here long enough to see a lot of these and this is exactly what I wanted to help avoid – if there was a common vision for RISC OS, these people could be shut down with a single link to that vision and hopefully a plan to get to where the community wants to go. The problem was, and still seems to be, a deep rooted unwillingness to even discuss such a vision.

If you want developers to join in the work you have to give them a reason to. Assembler and BASIC are going to attract a very limited group and even fewer if they can’t see any kind of a plan to where things are heading or if they are even heading anywhere.

The right way is: [snip Linus Torvalds’ e-mail] When one want something, must of the time, the best way is for him to do it :)

When you’re building something from scratch to satisfy only your own need then yes, you can start like that. If you have hundreds, thousands or even millions of people using what you wrote and even just a couple of dozen developers you lose that possibility. Linus started Linux like this, yes, but soon other people joined in because he had a vision and a plan that they agreed with. Linux is still driven by a vision and plans to get there and people join in by the thousands, not just developers.

Rick:

The problem with that approach is that it foists all of the additional dependencies of a second toolchain onto a group of people who do not need it.

That’s how modern development happens, there are tools in place that you may not need for your specific area but to build a whole product in many cases you need multiple tools to achieve it. Web development is a whole lot less complex than an operating system but there are quite often multiple tools written in multiple languages using scripts in various scripting languages to build a single web application. Not wanting to add a second toolchain to build the product because some people might not need it is a pretty weak excuse for not doing it, particularly if the plan was to switch to that new toolchain.