Live data from Hacker News

Urbit: an operating function

urbit.org

11–20 of 177 posts

Re: Urbit: an operating function

#11
the concepts expressed in the first section "Obstacles" are interesting and make for good reading, but the implementation strategy in "Definition" are nuts. The authors completely disregard human nature and usability when designing Hoon. Random variable names? Sigils-only syntax? If they want to replace Unix and the Internet, they should remember why Unix won: because it was easy tp get things done.

In Urbit new developers not only have to learn all the new concept words, they also have to suffer through a brainfuck/perl syntax and a hostile programming style. Success seems impossible.

Re: Urbit: an operating function

#13
post #9
post #7

Earlier quoted context omitted.

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?

Yes -- Urbit is a "server" in the sense of "computer," which you control and which runs your own apps.

IPFS stores and serves your data; so does Dropbox, Cloudflare, etc. In a sense the best way to see IPFS is as a distributed CDN, of course with an immutable namespace that actually works.

Re: Urbit: an operating function

#14
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…

>Interesting stuff, but in my usual 15 minutes of attention-span for things like this, utterly impenetrable.

It's pretty much designed to be as hard to understand as possible.

Look at the source/demo videos - it seems like it's designed to be obfuscated.

https://github.com/urbit/urbit

http://urbit.org/preview/~2015.9.25/materials/part-i

Personally, I can't get over the really made up words.

Re: Urbit: an operating function

#15
post #8

Earlier quoted context omitted.

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.

Really?

"This paper studied the incidence and characteristics of DRAM errors in a large fleet of commodity servers. Our study is based on data collected over more than 2 years and covers DIMMs of multiple vendors, generations, technolo- gies, and capacities. All DIMMs were equipped with error correcting logic (ECC) to correct at least single bit errors"

from conclusion 1.

"The conclusion we draw is that error correcting codes are crucial for reducing the large number of memory errors to a manageable number of uncorrectable errors. In fact, we found that platforms with more powerful error codes (chip- kill versus SECDED) were able to reduce uncorrectable er- ror rates by a factor of 4–10 over the less powerful codes."

DRAM Errors in the Wild: A Large-Scale Field Study : http://research.google.com/pubs/pub35162.html

Re: Urbit: an operating function

#16

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."

Urbit confuses me to frightening levels. Psychedelic substances levels. Kudos to them.

Re: Urbit: an operating function

#17
post #11

the concepts expressed in the first section "Obstacles" are interesting and make for good reading, but the implementation strategy in "Definition" are nuts. The authors completely disregard human nature and usability when designing Hoon. Random variable names? Sigils-only syntax? If they want to replace Unix and the Internet, they should remember why Unix won: because it was easy tp get things done. In Urbit new deve…

The random three-letter variable names are only used in the kernel, and they're meant to only be used in code that's small/simple enough that they're warranted. In my opinion, we use too many of them, and I've been converting many of them to longer, more descriptive names. The rule that "punctuation is syntax, text is content" is useful, and it becomes very natural with a bit of practice.

Hoon is very much not designed to be apparently usable, it is designed to be actually usable. Personally, I find it to be one of the most usable languages I've ever used.

Re: Urbit: an operating function

#19

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."

It's too bad, really, because someone should do a serious general-purpose overlay network project, and it's clear that Urbit isn't it.
Post reply on HN