A Constructive Look at TempleOS (2015)
codersnotes.com
codersnotes.com
Although there are many people who are instantly dismissive of Davis, I've seen others give him a fair engagement on his ideas. They bend over backwards to give him some credibility. How does Davis respond to this? He stubbornly refuses any and all crticism, no matter how leveled it is.
I've watched him go in circles for pages in forums where people modestly suggest easy improvements to his design. As always, it's a little hard to separate out the mental illness from the person. But to say people don't attempt to engage Davis fairly is flatly disingenuous, and I think the author ought to try it before making that claim.
Actually having to focus on the ideas as opposed to the party has a tenancy to improve the quality of the analysis.
Do you have any examples?
Additionally, though Temple is a legitimate software project, it lacks the aims and design to become widely adopted, meaning it is worth less effort to improve it (and the same can be said for many other projects.) So there is a compounding effect.
In the first place mental and social stability are not only helpful but absolutely essential in any endeavor requiring sustained effort and cooperation from more than one party. A multitude are involved either directly in linux or in projects that depend on same whereas TempleOS is a one man show not just in terms of development but even in terms of usage since if I recall correctly it doesn't do networking. Every user is figuratively an island.
Further it ought to be obvious that there is a substantial difference between Linus sometimes being an asshole and a mental disorder which often leaves the sufferer incapable of meaningfully connecting to reality or the rest of humanity let alone contributing.
Look at Terry he obviously possesses intelligence but it mainly serves to provide a diversion while he wastes his life away between racist paranoid rants on the internet.
If anything his existence is an example of a waste, a waste of everyone else's time and especially a waste of terry who of all people can't get away from himself nor effect his own cure. We do need better ways in the future to help people like terry but we do not need silly equivocation.
It seems like that is what the Linux 'text only' input/output should have been. Instead of parsing ASCII which will bring about the incompatibilities that we see today, it would have been better to have all tools input/output HTML/XML and translate it into human readable text in the shell for when output is redirected to the terminal.
[0] iXBRL is a markup language used for company accounts (I think it might be a requirement for submitting company accounts in the UK). Details: https://en.wikipedia.org/wiki/XBRL Example: http://www.xbrl.org.uk/techguidance/bbbbb-ltd.html
I'm addition to that, a monolithic unikernel (as unikernels usually are) would have the issue of a higher tendency for kernel panics.
So i really can't see unikernels becoming mainstream. If anything the reverse trend is true with more complex kernel designs like micro kernels becoming more favourable as computing hardware gets cheaper.
The real growth area for unikernels is virtualized appliances, eg running a single purpose service as a Xen unikernel. But even that is awfully niche and often better served (particularly in terms of developer and sysadmin productivity) with containers these days.
Unikernel isn't the opposite of microkernel.
Unless I've overlooked a bunch of kernels - and I'm happy to be proven wrong - usually you'll find unikernels to be monolithic because those two approaches address the similar objectives in kernel design (namely simpler layout and improved performance).
However correlation or not, you're probably right that my point regarding monolithic kernels wasn't entirely relevant to the rest of my post and thus just risks confusing things.
So, if you want POLA and damage containment, one option is imitating old designs that pulled that off. Patents expired, too. ;)
However you have to bare in mind that this tangent did start off as an exercise in generalisations so I was following on from that by pointing out that many current multi-user systems also use user accounts as a tool for reducing the exposure a process has. While you'd obviously agree that it's a long way from being the most secure method of hardening a OS, it is still a pretty typical way for many desktop systems to operate.
(There are, of course, some details that would need to be worked out like how to handle unsafe code blocks, how to run programs written in unsafe languages, and how to enforce a policy of only executing code compiled with a trusted compiler, but none of these seem like fundamentally insurmountable obstacles and the benefits of being able to make a system call without any more overhead than a function call are pretty big for certain applications.)
And no, I don't think this solves all of the potential security problems that could exist. What it does accomplish (if you're willing to trust a compiler in the same way that we're expected to trust the MMU in our computers, which might not be warranted at this stage of the development of Rust) is that it solves the problem of one program reaching into another program's address space when it isn't supposed to.
Strictly speaking, it would be more secure to have both compiler-enforced protections and an MMU, so that a compiler bug won't compromise the whole system. It is, however, at least theoretically possible to have secure process isolation without relying on an MMU. That's a big deal, because context switches are expensive and if there's a way to get the same safety without the overhead, someone is likely to build a system that takes advantage of that.
> No police state. Nothing is different from 1990 except we don't have any enemies. The World has gadgets to amuse itself. Eliminate fat-ass government jobs. Eliminate CIA, NSA and TSA. Don't fucken touch my computer, CIA ------. Githib is to register and control dangerous people and code. No cloud.
One needs the context. It's very stream-of-consciousness-y.
May be a good starting point for anyone else interested.
I wasn't aware of this, I have been tinkering with TempleOS for a while now, but I've been missing the networking functionality that Shrine provides.
They've added networking, a package manager and a unix-like shell. That's really cool. You could put it in a container and use it as an emacs alternative.
That's inspiring. I almost want to do this, just for the "nerd cred". It would be a pretty workable environment, and probably faster than emacs.
Was it created by a non-racist, mentally-healthy, socially apt individual wouldn't it be regarded as a neat but not extra-ordinary hobby project?
I believe it would not be so frequently a topic at HN front page. But I would like to hear others opinions on this.
TempleOS does some really cool things. JITed C derivative, unified terminal/texteditor/documentation, and a lot of other cool things.
Just because Terry is "different" doesn't mean his work is any less valuable. More people may see it because of his "antics" but there are still cool things he has done.
Well, there are apps with thousands of users, based on Electron and NW.js, that do "barely anything" and yet load slowly as molasses and use half your CPU.
What's Slack doing compared to a full (if primitive) OS and userland?
Connecting to the internet.
Slack's app has to display images, render scrolling, respond to network events, store and load application state like your preferences and theme, etc. Assuming it does these things - I use the web client.
Slack also has to support multiple operating systems, so it may make technology choices around that.
It's really not hard at all to see why Slack would be much slower than an OS that basically does nothing to boot up.
It's not hard at all to see why Windows, which supports tons of hardware, would be larger on disk and slower to unpack as it boots - lots of drivers and services need to start up to support all of the things that make it not TempleOS.
You seem to underestimate what TempleOS does and overestimate what Slack does. We had apps 10x more complex than Slack (with network IO et all) in 1995 -- and they run faster.
Now using the web stack for Slack desktop might very well be a business decision (and a good one at that), but it's one of the worst performance decisions you can make.
IMO TempleOS is quite extra-ordinary! From the article's conclusion:
"Watching TempleOS execute its built-in test suite is a jaw-dropping experience. I can't help but be impressed as a vast number of demos, games, graphing calculators, debuggers, and compilers all fly before your eyes. To see the sheer amount of content that's been written here over the years, to see such effort expended on a labor of love, is wonderfully heart-warming."
Terry's online behavior has grown increasingly odd, but he project's fame pre-dates the odd behavior
That's some serious paranoia there.
Canada works.
https://www.theguardian.com/society/2015/jun/02/dont-use-joh...
> Whether the rumours are true, I can’t say, but what’s certain is that the truth of Nash’s experience, the way in which he struggled and ultimately succeeded in using the power of his rational mind to overcome his delusional thinking, was replaced with a straightforward lie. And whatever the rationale behind it, the wholly disingenuous use of Nash’s recovery to promote the use of anti-psychotics is to my mind unconscionable.
I think in the coming decades we'll come to see the excessive use of long-term psychiatric medication as barbaric as we now understand the use of therapeutic lobotomies in centuries past to be.
It is common for people to look at a creative work and say/think "Phftt...I could do that." The proof that a person is mistaken is that they don't and won't and never will.
I wish the OSDev community could have a more constructive dialog with Terry and his project.
TempleOS is a vision of what computing might have been like if the middle ages never ended. What if computing technology developed in a monastery for the purpose of glorifying God? (Like illuminated manuscripts and sacred architecture.) We'd expect odd mixtures of the archaic and innovative, weird technological taboos and lots of anachronisms that only made sense theologically. Something like TempleOS.
Knuth's obsession was rewarded by society, while Davis's was scorned. Neither did any real harm.
He wrote it in HolyC language which is an interesting project on its own: http://www.templeos.org/Wb/Doc/HolyC.html.
You can change the OS because of the JIT compiler, run the compiler, and overwrite the running OS.
The command line is interesting. It feeds directly into a JIT compiler, so you have things like Cd("..").
It runs in a single memory space, so processes communicate with each other by writing to each others memory space.
It's built by one person without feedback or collaboration with others.
There are code walk throughs available that you can learn from: http://www.templeos.org/Wb/Home/Web/TOSVideos.html
I've only ever heard positives things said about TempleOS.