TempleOS
templeos.org
templeos.org
I am Kenneth from the BBC interview: https://www.bbc.co.uk/programmes/m000b4r3
Things were pretty much on a downward spiral after 4chan funded his drum set: Terry got kicked out, and then Terry's van got impounded along with $1000 of a lot of electronics. Once he was homeless living in CA, people thought (and rightfully so) that he would die on the streets. It's such a shame what happened, honestly. 15+ years of social isolation and events in his past ultimately led to his downfall. His death made me very distraught, especially after meeting him in person months prior. Meeting him left a profound effect on me because he was so appreciative and seemed mentally sharp when he engaged with me.
It's a very sad story on many aspects and likely controversial (giving him publicity, contacting authorities, ignoring him, banning him, etc); all these actions had consequences and forged his mind this way.
I wish more people would support him and his family instead of encouraging him in his dementia.
This software is certainly good food for thoughts, not just about computers, but life in general, so it could be worth including it in some sort of museum.
(small warning: he was very rasist, but because of his illness it is hard to tell if he could do something about this)
[1] https://news.ycombinator.com/threads?id=TerryADavis&next=926...
https://news.ycombinator.com/threads?id=TempleOS
I remember seeing 4 or 5 different handles once he started getting deaded/shadowbanned.
I miss him a lot. Not his spout-outs, but him and his technical insights.
RIP Terry!
Shame is one thing, and IMO already reason enough to want privacy but one could argue that it's debatable.
Being bullied, however, (as stated in another comment) really shows why privacy is needed. Even if you get all the praise in the world, if you get too much negativity, one can die from it (most likely indirectly). I find it very harsh and unfortunate to say, but this seems to be the case. While everything is debatable, I could imagine that not everyone thought about this particular reason (I haven't nor have I ever read this from privacy advocates) and find it a more compelling reason to uphold privacy.
One idea I miss very often while programming: embed info like pictures in your code (as comment).
It would be great to add flowcharts, diagrams, screenshots into code as comments (an IDE could collapse this as needed).
Does anyone know if there are languages that also can do this?
I was interested reading Terry's posts and thoughts, and spent some time playing with TempleOS. Unfortunately some people couldn't leave him alone.
It was discussed in HN (2014): https://news.ycombinator.com/item?id=8658283
Website: https://shrine.systems/
Source code: https://github.com/minexew/Shrine
Without context, it strikes me as somewhat akin to adding details to a Picasso. The reason I'd use TempleOS is to get a peek into Terry Davis's mind, so what happens when someone else adds networking support?
Is it seen as a research project? Just something fun to play with?
[1] https://alligatorbrowser.github.io/voidnill.github.io/a/a32....
I've been thinking about writing a technical analysis of TempleOS, in the style of the the Xinu OS textbook [1]. No strong reason for doing so, though it is curious how much more one could learn about him by identifying patterns in the code and OS structure.
It will probably take me a while to recover from my current burnout to look at a holy-influenced C dialect, though. A venture into the library of babylon requires preparation. So, I'm just passively collecting writings that already exist, and the likes, like you just posted. I'm on the #templeos IRC on irc.rizon.net, if you would like to chat sometime. It's pretty inactive, with sprinkles of relevant conversation occasionally.
tl;dr: The creator was a brilliant programmer who experienced a psychotic break late in his life, which led to chronic and severe schizophrenia. He killed himself in 2018.
According to his Wikipedia page #1) He passed away August 11, 2018, just the same day he posted his last video on YouTube (the same as included on his TempleOS home page): https://youtu.be/oH41gGBVpkE
His Wikipedia #1) page says the following about his passing: "Investigators could not determine whether his death was suicide or accidental, although the train engineer believed his death to be a suicide. The police report stated that Davis was walking with his back toward the train and that he turned around before the moment of impact".
Bless his soul!
Warning: not for the faint of heart - banned for obvious reasons.
I lived through it - on 4chan, reddit , and HN.
It's still not obvious to me why he'd be banned, I don't think you should hand wave it that easily.
The guy had mental issues, but he had some amazing lucidity at times.
If I owned a movie theatre or restaurant I surely wouldn't ask someone with vocal tourettes to leave the establishment, and if I did i'd be ostracized all over the media and community -- so it's not as clear to me as you seem to think it should be why he was treated the way he was on the various forums.
I get that he said abrasive and racist comments routinely; but I think there is something to be said about the fact that his voice was routinely listened to and considered on 4chan's /g/, and routinely sequestered and removed on HN and reddit. 4chan turning their attention to him wasn't a good thing, nor is it usually ever, but that forum did give him a place to talk without fear of bannings, karma struggle, deaded comments, whatever.
Treating someone as good as they are treated on 4chan is a low bar. Back then the HN method of constant deading and shadowbanning felt heavy handed and unneeded; we're supposed to be adults who are aware that mentally ill individuals exist in real life and here on HN, but the way it was dealt with was by silencing an already schizophrenic person so that the 'normal' crowd could go on with business as usual.
I can't think of a more head-in-the-sand response, and I'm not even saying that it wasn't a required action to keep the forum discourse on some level of civility , but boy does what happened to Terry make me feel nauseous -- the same kind of feeling I get in the pit of my stomach that is usually a sign for me that I am witnessing something morally uneven. I don't know the solution, nor do I claim to. I just feel bad about what happened.
As someone who chatted in emails with him after his bannings, I still feel bad about his treatment and demise, and I miss him and his technical insights immensely. I think he got a poor run of life, and I wish that more people had been supportive of him, able to filter out the profane for the insight -- especially since he became fascinatingly technically capable and astute when spoken to personally with your 'vocabulary filter' on.
Terry was an individual by which most mistook his trees for the forest -- and I'm glad to read in this thread that I'm not the only one with that positive sentiment towards him and his memory.
I wonder what would happen if we can find a way to build software protection in supervisor mode, ditching user mode and associated context switches.
Ideally, OS's would explicitly support information protection domains (after all, this is already a feature in some niche, specialized OS's) and only sensitive info/data would be protected by a switch to a different protection domain. Most user tasks which deal entirely with non-critical data could simply run in a shared address space.
That's nonsense! Separate address spaces have nothing to do with hardware vulnerabilities. The MMU uses address spaces to isolate processes from each other, which is required for proper multi-tasking.
If you don't use process isolation, every task can overwrite the heap and stack of every other running task (including the OS kernel and drivers!). Information disclosure (in this context) is only relevant in virtual environments, where multiple tenants have to be strictly isolated from each other and affects (hardware) VM supervisors.
It's a different topic entirely.
This is not a concern if all code is rigorously checked for memory safety which is quite feasible in principle, and possibly already the case for some uses of WASM/WASI. (Native binary code would need to be annotated with low-level proofs, to be checked by the OS.)
It's impossible to automatically check memory safety at compile time as that implies solving the Halting Problem.
Runtime checks would need to rely on the compiler enforcing these checks in the RTL. This, however, can easily circumvented using return-oriented programming (remember: you don't want the MMU to protect stack spaces).
No amount of software-based sandboxing or compile-time checks can effectively prevent non-isolated processes from accessing and corrupting each other's state. That's exactly why MMU were introduced in the first place.
Experiments using Software-Isolated Processes like Microsoft's Singularity [1] rely on complete toolchains from OS kernel to "safe" languages and runtimes and are not suitable for every requirement (e.g. hard real-time becomes near impossible).
The SIP concept also just shifts the burden of proving correctness from app and system developers to compiler and toolchain developers and we all know that those guys never make mistakes ;)
[1] https://www.microsoft.com/en-us/research/wp-content/uploads/...
For the general case, yeah. And while I agree that I would not remove process isolation, I think they have a point about "almost guaranteed to be safe" languages could be potentially used without isolation (not with zero risk, of course).
We have a lot of modern languages that are memory safe at least in theory. However quite a few rely on the OS using these safety features in the background. For example the Java Runtime uses segfaults to catch null pointers instead of actively checking for them, at least as far as I remember.
For example, if you are building a grid computer, you don't need mechanisms that were designed to protect university students from one another. Consider if everything is driven from a single codebase. Your type system can provide protections that have traditionally been done by the kernel.
I am currently playing with this. Have a boot loader up, and a handoff to c++. Today I am looking at page-management.
There are some interesting trade-offs that come from unconventional approaches like this. For example, I have read that if you make SIMD registers available to the kernel, it hurts the performance of context-switching. (https://os.phil-opp.com/minimal-rust-kernel/)
A mitigation I am considering: do all interrupt handling on one core, and then have all other cores for work-processing. Use channels to communicate between the burnt interrupt core and the worker cores. Downside of this: worker cores would need to poll for new messages. In low-activity periods, I could slow the poll interval. I would be interested to hear from anyone who has gone deep on this, or knows of papers.
For what you're doing I recall reading about IncludeOS[1] which seems to have similar goals