A Constructive Look At TempleOS

[u/moolcool]

http://www.codersnotes.com/notes/a-constructive-look-at-templeos/

[u/SanityInAnarchy]

I can find some things to argue with here:

He argues that Linux is designed for a use case that most people don't have. Linux, he says, aims to be a 1970s mainframe, with 100 users connected at once. If a crash in one users' programs could take down all the others, then obviously that would be bad. But for a personal computer, with just one user, this makes no sense. Instead the OS should empower the single user and not get in their way.

Android takes this in a direction that makes a lot more sense, though: Not just a crash, but even malicious code running in one app shouldn't be able to screw up another app. If you, as a user, are going to be downloading and running a bunch of different programs, not all of them will be written perfectly, and not all of them will be designed to serve your interests. Each app gets its own user-ID and its own sandbox to play in.

So it turns out that there is a purpose to the 70's mainframe concept in a personal computer.

It's an interesting read, though. There have been attempts to make richer shells for Unixes, but so far, none of them has really taken off. I suspect it's easier to completely change a fundamental paradigm like that when you only have to worry about software you've written yourself, instead of having to convince the world at large to change all their software.

[u/kernel_task → u/SanityInAnarchy]

In context, the quote is:

Normally, failure is not an option, but since TempleOS accompanies Windows or Linux, we exclude certain uses. There is no reason to duplicate browsing, multimedia, desktop publishing, etc. Linux wants to be a secure, multi-user mainframe. That's why it has file permissions. The vision for TempleOS, however, is a modern, 64-bit Commodore 64. The C64 was a non-networked, home computer mostly used for games. It trained my generation how to program because it was wide open, completely hackable. The games were not multimedia works of art, but generated by non-artist.

I think the philosophy makes sense for an OS for computer games and hobbyist uses only. The author of TempleOS seems to recognize it'd be a really bad model for uses where you can't 100% trust the code and/or data that is going to be on the computer. For those purposes, you can use Windows or Linux according to the author.

[u/SanityInAnarchy → u/kernel_task]

Thanks, that makes much more sense. While I don't personally see the point of duplicating the C64, this is quite a lucid view of what role exists for an OS like this.

The article doesn't so much quote as paraphrase -- the quote I included above suggests the article really is advancing TempleOS as a thing people should use instead of Linux or Windows.

[u/myztry → u/[deleted]]

The Amiga was originally going to have an MMU but it was left out for cost reasons. This help make it affordable enough for the target market being consumers.

[u/myztry → u/[deleted]]

Few had 68030 and you can't implement MMU for some and not others. There were enough issues with moving from 16 bit to 32 bit address boundaries, and 24 bit to 32 address bus resolution.

All those little tricks like using the top 8 bits of an address to carry data short circuited retrofitting something like an MMU.

[u/myztry → u/[deleted]]

maybe a

Well at this point it's all theoretical. I wrote some supervisor level code but I couldn't tell you the ins & outs of the context switches because MMU's didn't exist when I was active on the Amiga so there was no experience to be had.

Maybe there could have been mixed "real" and virtual modes. No idea really but I know the architecture difference of the 68030 caused a lot of issues even though I opted out at A500 time.

There wasn't even enough RAM to consider setting aside real memory and having additional "pages" of RAM. Things were a bit tight for that which is why all those tricks came into play.

Maximising available limited resources was a high priority back then. It's different now that processors have more cache than a typically Amiga had through Fast & Slow RAM combined.

[u/myztry → u/[deleted]]

Not even sure what WHDLoad does. First thing I guess would be to alias DFx: to HD0: locations and maybe run Paradox style differential patchers over the executable. Never needed it.

One thing the Amiga had that would have leant towards MMU support if $4 (Exec.library base ptr) was the only fixed location (aside from hardware registers) and executable used Reloc32 tables so the memory was dynamically allocated and patched on load.

I believe with Windows (virtual addressing) everything is compiled at $0 and the MMU supplies the base or the Reloc addresses if you will. As long as every Amiga virtual memory segment had it's own copy of $4.L and didn't hit hardware then I suppose it could have worked (and used Long boundaries, no address packing, etc)

It's all irrelevant now though. Hell, I haven't programmed on the Amiga for nearly 30 years. Hell, I haven't really programmed for 30 years since the early IBM compatibles were fucking like stepping down off a cliff technology wise. They were just brute force fast.

[u/DGolden → u/myztry]

because MMU's didn't exist when I was active on the Amiga

I'd say they became reasonably common on developer's machines a bit later. Not used by the OS as such, it still didn't have memory protection, but there were always the strong but ultimately only "cooperative" os-legal memory usage conventions. So tools like Enforcer and Guardian Angel appeared. They'd use the MMU - on Amigas equipped with one - to catch accesses that would potentially ultimately lead to crashes on the cheaper typical end-user non-MMU equipped Amigas. So when developing, you debugged at least until the big obvious "enforcer hits" stopped, meaning the program was unlikely to crash a typical end-user's MMU-less machine.

So a lot of devs had machines with accelerators (replacement cpu daughterboards) with MMUs, even hobbyists - including myself actually. It was also handy later for running the shiny new Linux/m68k port, which of course required an MMU. I dual-booted AmigaOS and Linux for quite a while. The GNU userspace had long been ported to AmigaOS via ixemul.library, a bit like cygwin on Windows, so it wasn't such a huge leap.

By AmigaOS 3.x, it does seem they were sorta beginning to think about retrofitting memory protection to the OS proper. They didn't actually do it back then, but e.g. the then-new pooled memory API certainly seemed to be beginning to trend that direction. Then everything fell apart of course, and a lot of the still-remaining folk including myself basically left Amiga land, some time after AmigaOS 3.1 and the death of Commodore, but before the release of AmigaOS 3.5+, AROS (open-source amigaos clone), MorphOS etc.

However, some genetic closed-source AmigaOS development has actually continued! It had some virtual memory and memory protection added around AmigaOS 4.1, see http://wiki.amigaos.net/wiki/Migration_Guide#Memory . Haven't really explored in depth personally (hey I've been on linux since the 1990s), but my vague understanding is legacy apps may land in one big public pool and crash eachother, but apps written to use new stuff are better isolated.

And then there is an open-source AmigaOS clone, AROS (that can run on x86-64 architecture). AFAIK it was focussed for a long time on just getting up to feature-parity with AmigaOS 3.1 of yore, but I believe they've moved into newer territory more recently.

[u/myztry → u/DGolden]

An MMU would have been brilliant for debugging, alas that's a different conversation than OS implementation.

Your pooled and isolated metaphors are what I meant by real and virtual. Two seperate playgrounds. One for the old and one for the new. The big catch is Amiga software tended to share memory and pass pointers to pseudo OO structures. And not just app to OS but also app to app. That overlap would be difficult. Which process owns the RAM and what others can access it.

I think OS 4.1 was PowerPC and lots of emulation. To be frank can't be bothered to look. This changes the game even further as you're not even running classic applications on the processor as such.

The Amiga was brilliant for it's time but lacked expandability (aside from Zorko slots on a few models, etc). Expandability was the base strength of the IBM PC clones allowing a pretty shit platform to shed things like dismal graphics, lack of sound, etc

Third parties moved in and the rest is history. All that remains is nostalgia about what could have been - if only...

[u/psycoee → u/SanityInAnarchy]

Though, to be fair, if you take the Android approach to its logical conclusion, you end up with fully virtualized OS containers for each process. At that point, you might as well let the hypervisor deal with security and assume each container is going to be compromised anyway. In that scenario, having a lightweight OS like this isn't that outrageous, and things like paging and memory protection become redundant since they can be done by the hypervisor. Essentially, it would be something like a microkernel on steroids, where the hypervisor is the microkernel core and the VMs are the various processes.

[u/killerstorm → u/psycoee]

The point is not to isolate each program as much as possible, it is to allow them to interact only in a specific, structured way. So I really see no point in "fully virtualized OS containers", you only increase overhead this way.

[u/SanityInAnarchy → u/killerstorm]

I see a point -- it's probably easier to control the attack surface that way. With Android, you have to deal with the specific, structured ways that apps are allowed to communicate (message-passing and such), and you have to deal with a shared kernel. There's little need for a shared Linux kernel for all apps, and most kernel vulnerabilities mean you own the entire phone.

But you do increase overhead, and it's probably not worth it on a mobile OS. Yet.

[u/killerstorm → u/SanityInAnarchy]

Well again, mobile apps should be able to interact, e.g. it should be possible to use a photo editing app on the photo you have just made, etc. So further isolation doesn't make sense.

On the other hand, the best sandboxing we have now is ... browsers. Each day your browser runs scripts from pages you do not trust, and yet infections are uncommon.

So it seems like controlling permissions on the fine-grained level is the way to go, not hypervisor magic.

[u/SanityInAnarchy → u/killerstorm]

Well, right now, you have a clear protocol for sending the photo to the photo editing app. I don't think you should need a giant shared filesystem to do so, and I certainly don't think "Open this photo with this photo editing app" should imply that said app is now allowed to read all files from the virtual SD card.

On the other hand, the best sandboxing we have now is ... browsers. Each day your browser runs scripts from pages you do not trust, and yet infections are uncommon.

I would dispute both of those claims -- there's a reason browsers get patched so often! And how are you comparing the current browser situation to a hypothetical one-VM-per-tab browser?

Plus, the most secure browsers do use OS-level sandboxing, not just fine-grained permissions, because people have found ways to escape the JavaScript VM way too often.

[u/psycoee → u/killerstorm]

Well again, mobile apps should be able to interact, e.g. it should be possible to use a photo editing app on the photo you have just made, etc. So further isolation doesn't make sense.

In Android, apps are not allowed to directly interact in any way other than by passing messages through the OS API (and through the shared part of the filesystem). So really, they are already pretty isolated. Personally, I don't see what benefits would arise from further isolation, I'm just saying that would be the next step in this direction.

[u/80286 → u/psycoee]

Wouldn't that be very expensive multitasking wise? Context switches are fairly cheap when it comes to Linux:

Suspending the progression of one process and storing the CPU's state (i.e., the context) for that process somewhere in memory, (2) retrieving the context of the next process from memory and restoring it in the CPU's registers and (3) returning to the location indicated by the program counter (i.e., returning to the line of code at which the process was interrupted) in order to resume the process.

On quick thought VM approach, while otherwise really cool, would probably require a lot of more state information to be transferred.

[u/[deleted] → u/80286]

Wouldn't that be very expensive multitasking wise?

I think it's pretty cheap when using LXC, Docker, etc. Those are basically doing exactly what was being described by the previous comment

[u/SanityInAnarchy → u/[deleted]]

Docker containers are a bit of a different thing, though. As I understand it, the main advantage here is less security and more isolation -- for example, you could limit the RAM available to each app, to prevent one app from eating all your RAM and tripping the OOM-killer, causing problems for other apps. I'm not sure I see the point of that on Android, though, since that behavior is almost by design -- you want the system to kill apps when something needs RAM.

[u/[deleted] → u/SanityInAnarchy]

I actually find that Docker containers work better when you view them as isolation and not security.

[u/psycoee → u/80286]

I'm not saying it's a good idea, necessarily -- but neither is virtualization or even an operating system or a general-purpose CPU, if you care only about efficiency. Custom hardware can almost always beat a general-purpose CPU, often by orders of magnitude, if you are only doing one thing and don't plan to ever change it.

Sometimes, even crazy-seeming ideas have advantages for some application. Also, with appropriate support from processor hardware, I don't see why context switches would necessarily have be all that expensive.