Porting third-party programs to TempleOS | Hacker News Reader

Porting third-party programs to TempleOS

blog.jwhitham.org

254 pointsadamnemecek42 comments

The author of TempleOS posted to reddit/r/programming, and is commenting on it there:

https://www.reddit.com/r/programming/comments/3cd4sn/somebod...

> The "alien" nature of the project makes it interesting.

TempleOS would qualify in some ways as Outsider Art[0]. I wonder how many such "outsider"/"alien" projects there are out there...

[0] https://en.wikipedia.org/wiki/Outsider_art

It's really cool that people are doing stuff with TempleOS if for nothing else than to broaden their horizons. Maybe when the aliens from ID4 visit, we'll be ready.

In ID4 it's implied that our computers are based on technology we've been slowly reverse engineering from the Roswell crash. There's also a deleted scene with a throwaway line about how he's able to write the virus so quickly.

See also the official CERT Advisory [1] on vulnerabilities in the ID4 Alien/OS, warning of potential denial of service attacks by inferior life forms and recommending various workarounds in the event that planetary takeover is necessary (yes, it's a joke, but having been published within hours of the first screening of the movie this may well have been the fastest CERT vulnerability response in history)

[1] http://users.rcn.com/alderete/humor/comp/id4.html

Frotz feels to me like a pitch perfect choice for extending TempleOS's ecosystem. A job well done in so many important ways.

would be funny if Temple OS ended up being better than everything else

This is kind of what happened to OpenBSD, which started as a pretty hardline thing but is now one of the best PC laptop operating systems out of the box.

this is a relative understanding, not an absolute one.

Well it's lack of security makes it probably not an OS you'd want run untrusted code on. Like if you made a browser for it I'm not sure it would be easy to sandbox it to protect your computer from serious harm. Any program can read from and write to any part of memory if I recall correctly.

on the other hand the chances of coming across a virus made for TempleOS is rather unlikely.

As long as it has very little users who are all super tech savvy.

Please explain how that's different from today on other OSes. A JavaScript exploit or other browser corruption is still an issue on current browsers, right? (I only see one Firefox process on my machine, so I'm gonna guess if you break the browser, you have code exec with my user access level.)

A Javascript browser exploit is still an issue, however it won't usually be able to read and write to kernel memory. TempleOS runs entirely in ring0. That means any exploit whatsoever and the exploiter can not just access some of your data, they own your machine entirely from the kernel up.

http://www.templeos.org/TempleOS.html is a good explanation of the point and purpose of the project, one which is reasonable and makes perfect sense. It explains why a TempleOS machine should not ever run unchecked third-party programs (let alone be on any kind of network), but could be an excellent OS to use on a remote abandoned island.

Could you elaborate on the difference kernel vs user as far as the end user is concerned? I'm pretty sure that we've seen how damaging CTOs opening Office docs can be.

And web browsers seemed to take off before Windows NT was the more popular desktop kernel.

> Could you elaborate on the difference kernel vs user as far as the end user is concerned?

* No possibility of a secure experience via strict privilege separation (e.g. strict usage of multiple account, inconvenient but protects against alteration of personal data)

* A ring0 program has unfettered access to the hardware, so the machine itself may be compromised, a breach is not "format & reinstall" let alone "run a bunch of antiviruses" it's possibly "throw the whole machine into the bin and buy a new one".

> And web browsers seemed to take off before Windows NT was the more popular desktop kernel.

Windows 98 didn't run in ring0. It was crap, but not that crap.

To elaborate on the reasoning behind why it may be necessary to throw the machine out, for the people who aren't familiar:

Given full access to the hardware, it's possible (though I haven't tested it to be certain) to flash the BIOS. The machine could be bricked by a remote exploit.

> Given full access to the hardware, it's possible (though I haven't tested it to be certain) to flash the BIOS.

Or the firmware in hardware parts. An attacker with the know-how can not only brick but control your GPU or SSD.

In the context of getting completely compromised, I'm not sure the cost of another computer really adds a lot.

It won’t be able to read and write to kernel memory unless it can capture the user’s password and the user has sudo access. Also, as xkcd says, if you don’t have sudo, “If someone steals my laptop while I’m logged in, they can read my mail, take my money, and impersonate me to my friends, but at least they can’t install drivers without my permission.” https://xkcd.com/1200/

> you have code exec with my user access level

That's the difference. TempleOS has no access restrictions. It's not intended for either multiple users or networking so it really hasn't got even basic security e.g. processes having separate address spaces.

For all that, it's still pretty impressive but it wouldn't be suitable for a general purpose OS for most people.

You can still have security even with a single flat address space, provided you create some capability model or enforce communication boundaries in some other way. From then on memory protection is on a different level than the process.

Indeed. I wasn't suggesting it was an unsolved problem. Just that it's not part of TempleOS. Same with file permissions.

I have no idea if it's something that Terry has thought about but, from what I've read, it's just not a priority: he's been writing a single-user, network isolated system.

I'm not sure why this is getting downvoted, the point is very valid. In most cases it's trivial to get root if you can tamper with the environment of a user that gets root at some point.

https://xkcd.com/1200/

Chrome runs the rendering engine and JavaScript stuff in a sandboxed process that has almost no privileges. Escaping from that is possible if there's a vulnerability in the sandbox, but now you need to combine at least two vulnerabilities which makes it substantially harder.

That would be very unlikely. It has no memory protection as someone else alluded to, has no networking and I dont believe it is open source either.

It is open-source:

http://www.templeos.org/Wb/

So I imagine someone could code networking in there somehow.

This guys father (grandfather?) runs a bookstore in either Lewiston or clarkston. I met him years ago and thought he was slightly crazy bragging about his sons work. Interesting to see it's actually used.

Everyone needs something to be proud of...

and his son is kind of infamous. Not mainstream, but a lot of people know who he is and what he's done.

Terry's TempleOS and folks interacting with him and his OS always reminds me XCom game - as if that's some kind of empathy pinnacle. deeply touching

TempleOS and broken Ruby FFI/C binding libraries are the two main drivers making me want to learn C. Writing stuff within TempleOS would be more fun!

TempleOS doesn't support C. It's written in a language called HolyC.

"The next step would probably be to get some sort of Curses emulation running, so that Nethack can be ported."

make this happen! playing Nethack on TempleOS would be indeed an enlightening and holy experience O_O

Doom seems like the more obvious choice, thematically speaking.

C programs spread like viruses.

If someone were to port the Go compiler to it, there'd be so much more software that could run (natively, statically, no runtime library) without additional effort from the software developers.

If someone made a Go compiler for it, I'd switch - today.

Actually, given how few system calls (relatively speaking) Go makes, it might not be impractical.

because go makes networking so easy, many go programs avail themselves of the network. Even dead trivial programs often use the builtin jsonrpc.

TempleOS has no networking stack and thus porting any of that portion would require significant kernel changes as well.

I have no doubt that there are many other "minor" things like networking that would rear their head on attempting.

It would still be a really cool project to see how far you can get and what compromises would have to be made.

What's so good about native, static, no runtime library? Why not a language with more useful software available, like Python? Even if you do insist on native compilation, why not OCaml or Delphi or Haskell (which have more useful software written in them, even if only because they've been around longer)? What's so special about Go?

I think it would be funny if there was a prophecy that Chain World would one day be ported to TempleOS.

https://en.wikipedia.org/wiki/Chain_World

Reply on news.ycombinator.com