git.iko.soy/urbit.org
on master help sign in
blog: add "hosting by tlon", edit "state of urbit"
2c22309édouard
content/blog/20200929-state-of-urbit.md+6−6
compare with master
unifiedsplit
@@ -10,7 +10,7 @@ image ="https://storage.googleapis.com/media.urbit.org/site/posts/essays/state-o
10
10
11<br>
11<br>
12
12
13−![Pajaro Dunes](https://storage.googleapis.com/media.urbit.org/site/posts/essays/state-of-urbit-1.jpg)
13+![Grassy Knoll](https://storage.googleapis.com/media.urbit.org/site/posts/essays/state-of-urbit-1.jpg)
14
14
15<br>
15<br>
16
16
@@ -27,7 +27,7 @@ The tl;dr is that Urbit is much faster, more reliable, and nicer to use than it
27Anyway, let’s walk through the details. We’ll talk about our infrastructure and interface work independently, since that’s how we organize things internally. Then we’ll talk a bit about what’s going on on the network.
27Anyway, let’s walk through the details. We’ll talk about our infrastructure and interface work independently, since that’s how we organize things internally. Then we’ll talk a bit about what’s going on on the network.
28
28
29
29
30−Infrastructure -
30+### Infrastructure
31
31
32![Debugging Interface](https://storage.googleapis.com/media.urbit.org/site/posts/essays/state-of-urbit-2.png)
32![Debugging Interface](https://storage.googleapis.com/media.urbit.org/site/posts/essays/state-of-urbit-2.png)
33
33
@@ -37,14 +37,14 @@ First off, Urbit is about 10x faster for most users. With some careful debugging
37
37
38Second, we got our memory usage under control. Urbit still uses a 2GB memory arena. If the state of your Urbit grows to over 2GB things, uh, fall apart. This used to happen regularly, and now it’s pretty much unheard of. We implemented [tooling](https://github.com/urbit/urbit/pull/3235) to compact and deduplicate the memory image when it’s growing too large. We brought the memory usage of the compiler [down ~90%](https://github.com/urbit/urbit/pull/3041). There are areas where we can be more disciplined about how we use memory, but this is more or less a solved problem for the near term.
38Second, we got our memory usage under control. Urbit still uses a 2GB memory arena. If the state of your Urbit grows to over 2GB things, uh, fall apart. This used to happen regularly, and now it’s pretty much unheard of. We implemented [tooling](https://github.com/urbit/urbit/pull/3235) to compact and deduplicate the memory image when it’s growing too large. We brought the memory usage of the compiler [down ~90%](https://github.com/urbit/urbit/pull/3041). There are areas where we can be more disciplined about how we use memory, but this is more or less a solved problem for the near term.
39
39
40−Third, we implemented a completely new build system. Well, we actually got rid of the build system altogether and [made it a part of the filesystem](https://github.com/urbit/urbit/pull/3041). This made it possible for us to fix our over the air (OTA) updates and make them both fast and reliable. In April, an OTA could bring down your node and would take hours or even days to apply. Today, we regularly deploy OTAs with no fear of them breaking any nodes — they often go from galaxy → planet in a minute or less.
40+Third, we implemented a completely new build system. Well, we actually got rid of the build system altogether and [made it a part of the filesystem](https://urbit.org/blog/ford-fusion/). This made it possible for us to fix our over the air (OTA) updates and make them both fast and reliable. In April, an OTA could bring down your node and would take hours or even days to apply. Today, we regularly deploy OTAs with no fear of them breaking any nodes — they often go from galaxy → planet in a minute or less.
41
41
42We also rewrote a large part of our runtime in Haskell and made overall progress on [network scaling](https://github.com/urbit/urbit/pull/3174). And: we implemented a [principled approach](https://github.com/urbit/urbit/pull/2366) to [error handling](https://github.com/urbit/urbit/pull/3064), making nodes much less likely to become unrecoverable.
42We also rewrote a large part of our runtime in Haskell and made overall progress on [network scaling](https://github.com/urbit/urbit/pull/3174). And: we implemented a [principled approach](https://github.com/urbit/urbit/pull/2366) to [error handling](https://github.com/urbit/urbit/pull/3064), making nodes much less likely to become unrecoverable.
43
43
44The network is stable, fast, and safe from day to day. We’re pretty confident it can grow quite a bit without serious issues. When we shipped OS 1 we really weren’t sure what we could handle. Now we’re standing on much more solid ground.
44The network is stable, fast, and safe from day to day. We’re pretty confident it can grow quite a bit without serious issues. When we shipped OS 1 we really weren’t sure what we could handle. Now we’re standing on much more solid ground.
45
45
46
46
47−Interface -
47+### Interface
48
48
49![](https://storage.googleapis.com/media.urbit.org/site/posts/essays/state-of-urbit-3.jpg)
49![](https://storage.googleapis.com/media.urbit.org/site/posts/essays/state-of-urbit-3.jpg)
50
50
@@ -61,7 +61,7 @@ Those two are by far the most significant, but there’s so much more. We [rewro
61And I almost forgot [Leap](https://github.com/urbit/urbit/pull/3231): an omnibox for navigating around OS 1 with the keyboard. We have plans to make Leap much more powerful — but it’s a great first start toward making OS 1 keyboard accessible. I almost exclusively use [Leap](https://upload.wikimedia.org/wikipedia/commons/0/06/Canon_Cat_keyboard.jpg) to get around OS 1 these days.
61And I almost forgot [Leap](https://github.com/urbit/urbit/pull/3231): an omnibox for navigating around OS 1 with the keyboard. We have plans to make Leap much more powerful — but it’s a great first start toward making OS 1 keyboard accessible. I almost exclusively use [Leap](https://upload.wikimedia.org/wikipedia/commons/0/06/Canon_Cat_keyboard.jpg) to get around OS 1 these days.
62
62
63
63
64−Community + network -
64+### Community + network
65
65
66![Fishing Village](https://storage.googleapis.com/media.urbit.org/site/posts/essays/state-of-urbit-5.png)
66![Fishing Village](https://storage.googleapis.com/media.urbit.org/site/posts/essays/state-of-urbit-5.png)
67
67
@@ -72,7 +72,7 @@ Getting onto Urbit is still relatively challenging. By the standards of software
72Turns out, there are plenty of people who are up for running Urbit themselves and quite a few small communities have sprouted around the network. Overall the network has a fun, cozy feeling. It’s nice.
72Turns out, there are plenty of people who are up for running Urbit themselves and quite a few small communities have sprouted around the network. Overall the network has a fun, cozy feeling. It’s nice.
73
73
74
74
75−What’s next -
75+### What’s next
76
76
77We’re still more or less flat-out, full speed ahead into an even better Urbit-world. The seeds of change were planted when we made Josh the [interim technical director of urbit.org](https://urbit.org/blog/first-steps-towards-urbit-org/). Urbit itself is getting close to the point where the separation between Urbit and Tlon has to become more real. Urbit is aimed at being an ubiquitous platform, Tlon is aimed at making it as usable and useful as possible.
77We’re still more or less flat-out, full speed ahead into an even better Urbit-world. The seeds of change were planted when we made Josh the [interim technical director of urbit.org](https://urbit.org/blog/first-steps-towards-urbit-org/). Urbit itself is getting close to the point where the separation between Urbit and Tlon has to become more real. Urbit is aimed at being an ubiquitous platform, Tlon is aimed at making it as usable and useful as possible.
78
78
content/blog/20200930-hosting-by-tlon.mdnew file+33
@@ -0,0 +1,33 @@
1++++
2+title = "Hosting, by Tlon"
3+date = 2020-09-30
4+description = "The way we see it, hosting is the most important thing, next to Landscape, that Tlon can do to help Urbit continue toward widespread adoption."
5+[extra]
6+author = "Nick Simmons"
7+ship = "~simfur-ritwed"
8+image ="https://storage.googleapis.com/media.urbit.org/site/posts/essays/200930-hosting-by-tlon.jpg"
9++++
10+
11+<br>
12+
13+![Ocean](https://storage.googleapis.com/media.urbit.org/site/posts/essays/200930-hosting-by-tlon.jpg)
14+
15+<br>
16+
17+Urbit users tend to be interesting, creative, and capable people; we’re genuinely impressed with the communities that have formed on the network, and with the quality of discourse there. But for the number of communities to continue to grow, getting on the network has to become dramatically easier. It’s not realistic to expect most people to configure their own Urbit OS node in the command line.
18+
19+At the moment, the biggest lever we have here is to help ordinary users get online, so they can participate in communities inside Urbit, and eventually form their own. This means hosting their Urbit nodes and showing them around the network when they first arrive. There are already several businesses overlapping with this space to varying degrees: [planet.market](https://planet.market/), [urth.systems](https://urth.systems/), and [geturbitid](https://www.geturbitid.com/). Now, Tlon is releasing its own hosting offering. For the uninitiated, “Hosting” just means that we run your urbit ship for you, making it easier for you to get onto the network. We’ve been testing our hosting service with friends and family for the past few months, and now we’re ready to bring it to the rest of the world.
20+
21+To learn more about Tlon hosting and sign up for the waiting list, check out the new [tlon.io](https://tlon.io/) website. We are officially launching the service on October 9th, with a virtual event and demo; we’ll also show off some of the new features and improvements to Landscape, the Urbit web client.
22+
23+To be very clear, hosting isn’t for everyone; if you’re deeply security-conscious or privacy-oriented, you’ll still want to self-host so that nobody else needs to touch your keys. That said, hosting isn’t a walled garden; you’ll get a planet when you sign up for hosting, which you will own 100% and forever. You’ll also always have the option to roll up your data and take it with you if you choose to stop using our service. Your Urbit data is just a single file, and we’ll happily hand it back to you if you ever decide to leave. Nothing will ever stop you from self-hosting.
24+
25+We’ve talked for a while about how the ultimate destiny of Urbit is to escape the control of Tlon. For Urbit to really succeed, it has to be managed by its own community. We started Tlon in order to solidify the foundation of this young platform. Now that Urbit is starting to grow up, Tlon and Urbit will naturally drift apart a bit.
26+
27+Urbit is meant to be universal, ubiquitous infrastructure. Tlon exists to make that infrastructure useful and usable. We expect Urbit, as a platform, to be cared for by the community in collaboration with the emerging [Urbit Foundation](josh’s blog post). We intend Tlon to become increasingly focussed on providing a great user experience for anyone interested in this new network, so the network can continue to grow and thrive.
28+
29+The way we see it, hosting is the most important thing, next to Landscape, that Tlon can do to help Urbit continue toward widespread adoption. We don’t expect to be the only ones providing this service—and look forward to including more contributions from the community here on urbit.org as they continue to mature.
30+
31+If you’re curious to keep up with what Tlon is doing here, head to https://tlon.io and join the waiting list. We’ll be posting updates to that list as well as to the Tlon Transmissions notebook in the Urbit Community group. Going forward we’ll do our best to keep urbit.org neutral and focussed on the technology itself.
32+
33+See you all on the network!