> Blatant plug: Urbit (urbit.org) is a general-purpose OS built on the event-sourced model.
I've looked through its documentation, and while I couldn't make heads or
tails of it, Urbit seems to be everything but an operating system. Espeically that
it needs unix system to run.
Agree, term is wrongly used. Here it is used in the literal meaning of it. A software stack upon which you can execute other apps. The original concept iirc was to run both natively and overlayed but seems they've settled down to just the later.
>It's a freaking web app.
You can use Urbit without ever touching the web app and the neworking protocol is independent of http.
>Summarization: Urbit is a reaction to Unix-driven software complexity that dominates modern software development.
I keep reading explanations about Urbit along these lines but what's perplexing about this explanation is Urbit does nothing to achieve this goal. Regardless of the fact that Urbit is referred to as an operation system it still isn't one. It relies on a conventional OS, often UNIX family OS's like Linux to run. Urbit just layers a new even more complicated software and networking stack on top of the 'Unix-driven software complexity' that still underpins Urbit. Urbit does nothing to address these problems, it just makes them worse. Urbit's underlying software stack (Nock, Hoon, etc.) is just bizarre and non-nonsensical. For example, this gem from the docs:
"A loobean is a Nock boolean - Nock, for mysterious reasons, uses 0 as true (always say "yes") and 1 as false (always say "no")."
Wat? Why?!? And it doesn't end there. Urbit is littered with these WTF design choices and terminology. No one in their right mind is going to build professional software solutions on a platform like this. You might as well just be developing software in something like Brainfuck.
> What that means at the time of writing2 is that it’s a single-threaded interpreter running as a unix process that speaks udp protocol to a meshed network (and http to your browser).
I've looked up Urbit a couple times before, and this paragraph is the first time I ever even had an inkling of what it was.
The whole reason Urbit exists is that Unix + the internet is broken and needs a complete overhaul
Re: the different names, there are slight differences between gates and functions, but I agree they're not important enough to merit the change in name. But hey, it takes a purist to spend 15 years rewriting the whole stack from scratch!
> while (if I recall correctly) decoupling it from the underlying physical machine it's running on
> Urbit is a new clean-slate, full-stack server. It's implemented on top of the old platform, but it's a sealed sandbox like the browser.[0]
It appears that you do indeed recall directly.
Also, thank you. The two quotes from your comment, plus your sentence following, do describe it in a nice single paragraph. Granted, I do have to research most of the technologies in the stack, admittedly.
> why would a developer prefer to write Self-Hosted!Instagram instead of just Instagram?
Because urbit is designed to make that an easy thing to do. Say you've got a webserver, and you want to put a picture of your kid on it, but you only want the server to serve that picture to your Mom. On unix, that's really complicated, you need to do a lot of things to make that happen - not just implement a web app that includes authentication and give your Mom a new login and password to memorize, but also configure the web server properly and make sure your server is locked down and stuff like that.
On Urbit, that would be really easy, the equivalent of "mkdir mom; chmod +r mom; mv pic.png mom", because it abstracts away things like cryptographically verifying identities in the same way that unix abstracts away sending a file to a printer.
If I understand correctly, Urbit is a new OS kernel and application layer, with a new weird FP language on a weird VM. Its first app is a crypto ID system.
I still haven't dived into it, it felt obscure and obtuse last time I checked, but are the cool kids actually using it? I.e. do you have any more link to this niche community, to check what's the status of the project?
> I'm confused. Is this just saying that Urbit supposed to replace my Windows desktop and all the cloud services I use?
You'd run an Urbit instance (a planet) in the cloud (ideally, on three separate machines where a disk write succeeds if two out of three nodes receive it) and then run sub-instances (moons) on each of your personal computing devices (computers, phone, tablets). You could then interact with your planet and/or moons from your browser.
You'd do this because you want to run cloud-type services like photo sharing and (micro)blogging and such, but you _also_ want to do so through your own UI, not UI controlled by someone else whose interests are disaligned with yours, like Mark Zuckerberg's.
I can't imagine it'd replace standard OSs like Windows, macOS, iOS, and Android.
> Also, what does "Urbit's formal semantics makes ships trivial to migrate" mean?
If you want to move a ship (a directory containing your planet's data) from one (cloud?) computer to another, all you need to do is shut it down, scp it to the new location, and then start it back up again.
> the deepest problem with Urbit: it’s light on actual substance. Urbit seems to have spent many years developing fundamental infrastructure – programming languages, tools, etc. – that are a gigantic maintenance burden and orthogonal to its actual mission. That’s a huge distraction, and as a consequence, the “stuff you can do with your Urbit server” section was unimpressive.
This is really the crux. There's nothing on the urbit website but obfuscation of this fact. It's a vanity project reinventing everything from scratch, and the "use cases" are post hoc. If they actually cared about those use cases, they'd do things differently.
Urbit is TempleOS, but written by a neoreactionary instead of a schizophrenic. It's a weird hobby project not a serious attempt to accomplish anything, and it shows up on HN way more than the actual substance merits.
I'd try to explain more here, but I cannot do a better job at than they've already done.
Edit:
Also, it's despised by many on ideological grounds due to its creator's (who is no longer affiliated with the project in any way) political views from a decade ago. I'm not going to comment on this any further, because it's a tired case (discussed in literally every other thread on HN about Urbit) and I find it quite petty.
Blatant plug: Urbit (urbit.org) is a general-purpose OS built on the event-sourced model. Urbit's state is a small, frozen function of its event log.
I don't know of any other generalized event-sourced OSes. But almost every principle Fowler describes in special-purpose event-sourced designs also seems to apply in the general-purpose case.
For example, the connection between CQRS and event-sourcing seems very deep and natural. The connection to patches in a revision-control system is also completely apropos.
When Fowler starts pointing at advanced problems like "we have to figure out how to deal with changes in the schema of events over time," you start to see a clear path from special-purpose event-sourced apps to general-purpose event-sourced system software.
Broadly speaking, one category of answer is: abstract the semantics of your app, until it becomes a general-purpose interpreter whose source code is delivered and updated in the event stream. Then the new schema is just a source patch. And your app is not just an app, but actually sort of an OS.
Actually got a invite to Urbit... but haven't got the time to understand/install it.
Is it an OS? Will it affect any dev work I'm doing now? I understand that this is a huge and large project and support the fundamental ideas behind it, but maybe a super-distilled version of what exactly it is to the layman would be a bit better (in addition to what's already there).
I've looked through its documentation, and while I couldn't make heads or tails of it, Urbit seems to be everything but an operating system. Espeically that it needs unix system to run.
reply