| Full disclaimer: I recently started working for Urbit, but have been involved in its community for about a year and a half now. It pains me to see people paint the project and its people in this light. I don't know if I'm taking the bait here or playing into your cards or whatever, but I want to try and clear some things up. > He is "The Master", and you are just too stupid to understand his pure clear thought. Not really. He's actually been really helpful in explaining some of the decisions that were made in the past to me, and it never felt like my say in discussions regarding ongoing work didn't matter. > Anyone questioning anything with Urbit is either attacked, derided, ignored, or pushed aside
> You're just stupid, I guess. I don't know what communities you've been in that people just go "you're stupid" when you don't understand something. In my experience with Urbit's chat rooms (and the forums, subreddit, etc.), people are generally friendly and understanding of the struggles that come with jumping into an entirely new stack like this. We know things can be confusing, we know it's hard when you're just starting out. We're also very much ready to help, and do care about discussing concerns and criticism. I'd be willing to go so far as to say that, right now, Urbit's community is one of the nicest on the internet, but of course that's a tough comparison. Aside, maybe interesting: the arcane naming of the Hoon stdlib is getting rewritten to be much more sensical and easily understandable. Why? Some community members were displeased, and someone took it upon themselves to make the rewrite happen. We're happily merging that in once it's done. > By definition, they all use Urbit to communicate. And you can reach us without even installing Urbit on your machine. Take a look at http://urbit.org/stream/ > any higher class user can disable sub-users' accounts "Disable" isn't the right word here. A higher class can choose to stop helping a sub-user with peer discovery and to stop providing software updates to them. But if a sub-user is not content with the service their parent is providing, and/or they feel like they were unjustly blocked, they are free to find a parent that wants to adopt them. Using that mechanism, communities that oppose each other can cleanly separate and continue doing their own thing without any bloodshed on either side. > not wanting to cut losses because there "could" be something. Doesn't this apply to pretty much anything happening in the decentralization and crypto spaces right now? > I need say no more. Well, I've never experienced "disapproval concerning jokes about the group". We're not above joking about the weirdness of our own system, it's something we're very much aware of. |
Indeed not. I looked at Urbit as a way to do untrusted computation spread across multiple nodes. Think of a distributed Lambda not dissimilar to that of IPFS, but for computation. I tried to give it a fair shake. However roadblocks were everywhere. I would have to throw out most of my computing knowledge and start over to even analyze it. And writing programs in Hoon is ridiculous. My current tooling - nonfunctional. It not only disregards current nomenclature, but any sort of tooling I have to develop, make, and troubleshoot.
In the end, the further I try to get the 10,000 mile view, its just a federated system with a screwy network topology. And as tptacek has noted, the base code has very strongly written "bad choices", CS-wise.
> I don't know what communities you've been in that people just go "you're stupid" when you don't understand something. In my experience with Urbit's chat rooms (and the forums, subreddit, etc.), people are generally friendly and understanding of the struggles that come with jumping into an entirely new stack like this. We know things can be confusing, we know it's hard when you're just starting out. We're also very much ready to help, and do care about discussing concerns and criticism.
My experiences with Urbit have been primary documentation (which I am told elsewhere is the last place to look ?! ), people who show up from the "woodwork" on any thread that mentions Urbit, and some very hostile conversations on the 'web primarily discussing Yarvin's statements.
And unlike libraries like JQuery or Node.js , I can use them without being "part" of the community. I import them, load them, and use them. No muss, no fuss. Whereas, Urbit's community is inexorably tied to the foreign code and systems. I cannot simply download and use it - there's tons of content that is shared within the community. In coded language of Urbit, no less.
To understand, I have to use. To use, I have to understand. Both of these are going to take a great amount of time; and the knowledge here is non-transferable.
And strangely, once people start using that language, they seem to fail to explain the fundamental principles on which they rest on. I note this as the same type of trap that esoteric and religious cults use. They fail to explain what their terms really mean - and then it is a mixture of giving up, ignoring them, anger, or derision.
> And you can reach us without even installing Urbit on your machine. Take a look at http://urbit.org/stream/
Thank you. I saw that earlier. It looks something like Disqus or IRC on a website. It's obviously done with Urbit, but alas, it still doesn't help with deciphering any of the nomenclature.
> "Disable" isn't the right word here. A higher class can choose to stop helping a sub-user with peer discovery and to stop providing software updates to them. But if a sub-user is not content with the service their parent is providing, and/or they feel like they were unjustly blocked, they are free to find a parent that wants to adopt them.
So it's not true that Tlon can't just say $user's compute node is hereby expelled? Because my initial understanding was that Yarvin implemented instead of Galaxies/Stars/Planets, it was Dukes/Generals/Earls, and his compute node was the unique role of "Prince" - with the ability to expel anyone he saw fit.
> Doesn't this apply to pretty much anything happening in the decentralization and crypto spaces right now?
Indeed.. But that's a whole other ball game there. And yes, some of the cryptocurrencies most certainly have their own very cult-like status and effects. But you and I digress. I'm only here speaking of Urbit.
Ideally, what I want is the following:
1. Provide first principles how the system works. Use standard topologies, algorithms, and other established analytical methods.
2. Disambiguate the coded words describing primitives in the language. If the VM is emulating a non-Von-Neumann architecture, discuss it!
3. Network Protocol analysis: these should be well documented and established. I'm guessing they're also written in Hoon, which means they're nigh unreadable and excludes any existing tooling.
4. Fully document and vet the mathematical principles in the implemented crypto. Because I dont trust black box systems - and yes, Hoon is most certainly "black box" for 99.99% of programmers.
I'm sure there's something in Urbit that isn't documented elsewhere, or a algorithm that the world outside Urbit hasn't seen. Im interested in seeing they get their rightful place as part of mathematical tools we all use. In that end, Urbit is a neat project.
But for the reasons I've highlighted, I believe it would be an error to put any sort of time in this system outside of a curiosity.