Live data from Hacker News

Urbit: an operating function

urbit.org

1–10 of 177 posts

Re: Urbit: an operating function

#4
Reading anything from them always reminds me of TempleOS. There are some hilarious gems if you skim it, like "Urbit is highly intolerant of computation error, for obvious reasons, and should be run in an EMP shielded data center on ECC memory."

Re: Urbit: an operating function

#5
Interesting stuff, but in my usual 15 minutes of attention-span for things like this, utterly impenetrable. Can anyone who has had the privilege of being invited to the Urbit network enlighten us as to just how useful it is shaping up to be in light of, say, the situation with IPFS by comparison? (http://ipfs.io) Because to me, it seems that IPFS may well be ahead in terms of actual applicability right now. Am I mistaken?

Re: Urbit: an operating function

#6

Reading anything from them always reminds me of TempleOS. There are some hilarious gems if you skim it, like "Urbit is highly intolerant of computation error, for obvious reasons, and should be run in an EMP shielded data center on ECC memory."

I always think of TempleOS as well. Both project maintainers have created some impressive and/or interesting technology that is hindered by inflated self importance and being different for the sake of being different. Another common point - HN has a soft spot for both and upvotes most content related to these projects.

Re: Urbit: an operating function

#7
post #5

Interesting stuff, but in my usual 15 minutes of attention-span for things like this, utterly impenetrable. Can anyone who has had the privilege of being invited to the Urbit network enlighten us as to just how useful it is shaping up to be in light of, say, the situation with IPFS by comparison? ( http://ipfs.io ) Because to me, it seems that IPFS may well be ahead in terms of actual applicability right now. Am I mi…

I love IPFS, and it's definitely ahead in terms of applicability.

IPFS is solving a different problem -- it's a storage network, not a personal server. IPFS is more comparable to Freenet or BitTorrent. Urbit is more comparable to Sandstorm, although of course they're technically very different.

Re: Urbit: an operating function

#8

Reading anything from them always reminds me of TempleOS. There are some hilarious gems if you skim it, like "Urbit is highly intolerant of computation error, for obvious reasons, and should be run in an EMP shielded data center on ECC memory."

TempleOS is definitely more of a religious experience. They're also way ahead of us in CGA graphics.

I think pretty much anything but the most fly-by-night data centers use parity memory, but I'm always concerned by the failure to spend a couple extra bucks on chicken wire for EMP shielding. The Carrington event actually did happen.

Re: Urbit: an operating function

#9
post #7
post #5

Interesting stuff, but in my usual 15 minutes of attention-span for things like this, utterly impenetrable. Can anyone who has had the privilege of being invited to the Urbit network enlighten us as to just how useful it is shaping up to be in light of, say, the situation with IPFS by comparison? ( http://ipfs.io ) Because to me, it seems that IPFS may well be ahead in terms of actual applicability right now. Am I mi…

I love IPFS, and it's definitely ahead in terms of applicability. IPFS is solving a different problem -- it's a storage network, not a personal server. IPFS is more comparable to Freenet or BitTorrent. Urbit is more comparable to Sandstorm, although of course they're technically very different.

Like I said, I'm yet to finish boning up on what, exactly, Urbit is .. Sorry - not trying to be pedantic - but how is IPFS not a personal server? I can serve content with it right now, in fact - its what I mostly use it for at the moment.

I guess Urbit is more of an 'operating environment' that allows applications to be built, then?

Re: Urbit: an operating function

#10
post #8

Reading anything from them always reminds me of TempleOS. There are some hilarious gems if you skim it, like "Urbit is highly intolerant of computation error, for obvious reasons, and should be run in an EMP shielded data center on ECC memory."

TempleOS is definitely more of a religious experience. They're also way ahead of us in CGA graphics. I think pretty much anything but the most fly-by-night data centers use parity memory, but I'm always concerned by the failure to spend a couple extra bucks on chicken wire for EMP shielding. The Carrington event actually did happen.

I wouldn't be so sure of that -- none of Google's clusters use ECC, for instance.
Post reply on HN