hn_urbit_thr123

Joined 4 years ago

Karma
17
Submissions
19
Member since
Apr 22
View on Hacker News

Recent submissions

Comment · 2 years ago
Like most platforms, it's valuable IFF a lot of people build on it. But the fact that I can make an on-topic, constructive and informative comment about it and still get downvoted tells you everything you need to know about how likely that is.
Comment · 2 years ago
Sorry if I was unclear, it's a hard thing to summarize, but the useful part of it is in being a platform for app development, not just the fact that it hosts stuff. "End user server-side apps" isn't really a thing that exists, because current server-side applications e.g. wordpress have to run on a variety of stacks, have to reinvent user authentication, etc. Another way to put it would be that urbit is a platform on which to run build server-side apps in the same sense that Android is a platform for client-side apps.

It does work tolerably well, people are building stuff on it, but I think it's too widely-hated to build a network effect. (Source: search for urbit on HN and click on literally any thread)

Comment · 2 years ago
100% urbit. The idea behind it (briefly: "personal server", an easy-to-use, no-frills place for an end-user to run server-side use cases like storing important files, hosting a blog, etc that's portable between cloud hosts and designed for long-term stability over performance) is a good one. Implementing it as a novel VM with built-in identity and crypto makes sense. It includes some genuinely hard/useful features, like exactly-once messaging between nodes. Kelvin versioning (counting down towards "done" rather than counting up as features are added) is a great idea for software that serves infrastructural purposes. Charging a one-time fee for cryptographic identities is an elegant way to make a de facto reputation network that disincentivizes malicious actors, and is also that rarest of beasts, a non-dumb reason to use a distributed ledger.

It had so much going for it, but it was DOA from launch for two reasons: first, the implementation is so bizarre that the kernel documentation is frequently mistaken for an elaborate joke, and second the founder's racist blog went viral at virtually the same time as the public launch. It's not technically failed I guess as it's still being developed and does work, but a network without a network effect can only go so far.

I honestly think the "personal server" idea would be incredibly useful, and it would also be very profitable (not the software itself, but for cloud providers) if every suburban family rented a $15/mo VPS. I post about it here from time to time in the hopes that someone will fork it or re-implement what is basically a great idea, but in a non-ridiculous way and without #cancelled taint of the founder. Bezos, if you're reading this, please put a small team on it just to see if it goes somewhere, I'll be your first customer.

Comment · 3 years ago
I really like the idea of Kelvin versioning for an OS: instead of counting up and adding features forever, count down until you're done.
Comment · 3 years ago
Thanks for working on this. Have you considered abandoning urbit references and nomenclature? I've been casually following urbit a long time, and think there's a case to be made that it has accumulated enough toxic baggage to rub off on onto any project with even a whiff of association. I mean, you can see this thread as well as I can. Would it be realistic or possible to keep what you've got in plunder but reframe it in such a way as to make it less susceptible to guilt by association?
Comment · 3 years ago
I'm not bored, just sad. The "personal server" thing is a cool idea. I think the world would be better if it existed and worked well enough for wide adoption, but it seems like it'll never happen because the first guy to try to build one was a weird racist. So sorry to rag on you for something literally every other commenter in this thread is doing, it's just dispiriting to see, over and over.
Comment · 3 years ago
The problem isn't that you're wrong, it's that this is the same cutting insight everyone has in their first five minutes of exposure to urbit. It's like going to Australia and telling everyone you meet that vegemite probably won't take off in America because it tastes weird. We know, man.

But there's also probably some new and interesting criticisms one could make? Perhaps about the actual project described in the article? And maybe after having read it and understand it? That doesn't seem like too high a standard.

Comment · 3 years ago
If you decided to make a fork of linux, and wrote an article explaining why, would you expect it to be easily comprehensible to someone who's never used linux?
Comment · 3 years ago
It's disappointing how much low-effort bashing there is in this whole thread. Sure urbit is weird and has a lot of baggage and questionable design decisions, but the project we're discussing is explicitly an attempt to separate out a few good ideas and remove the bad parts. Is that really deserving of casual mockery?

I know I'm shouting into the void here, and under a pseudonym to boot, but this is an active FOSS project that real live people work on in their spare time because they hope it'll be important and useful. I like to think it's a convention here not to shit on such people for comedy value.

Comment · 3 years ago
My (relatively unbiased and informed) summary of what urbit is from the last time it came up is here: https://news.ycombinator.com/item?id=31124343

As someone who thinks urbit would solve an important use case but is too hopelessly weighed down by the stench of its founder to go anywhere, a good fork seems is a reason for optimism, so best of luck Plunder team!

Comment · 3 years ago
There's no rollback, it's an atomic transaction. The certainty that messages are always handled completely or fail completely is one of the big design constraints that made the whole thing so hinky.
Comment · 3 years ago
Yes, but the receiver can be faulty. If it acknowledges the message and then crashes before handling it, you've got at-most-once, and if it handles the message and then crashes before acknowledging it, you've got at-least-once. You can avoid this if the receiver handles and acknowledges in a single transaction, but I only know of one platform that implements this and everyone hates it (hence the throwaway).
Comment · 4 years ago
You don't have to understand the linux kernel to buffer overlow a linux application; If they do something like "Here's the IP of a running urbit with 100BTC in it, good luck!" and it's still up in a few years, that'd be compelling.

But more generally, if it's true that the only way to make a provably secure app is to design the OS and language around that purpose, then the problem you describe is general too - it will always be a challenge to find auditors.

Comment · 4 years ago
Is it even realistic to make a provably secure/stable applications on an OS like windows or linux? This (provable correctness of programs, at the expense of performance) is one of the explicit design goals or urbit. I know HN hates urbit and don't want to rehash that, but it seems like a good goal for some use cases and I'm not sure it's possible to achieve without building the OS around it.
Comment · 4 years ago
How do you keep apps from accessing other apps' data on linux? By creating separate user accounts with limited permissions for the apps to run under, right? Same deal here. Except that in urbit, "different user account" implies that it's running in a separate VM.

I'm not arguing with you, just trying to answer your questions. If you want to make really damning accusations about how awful urbit is, it will help to learn more about how it works :)

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton