HN user

Fang_

72 karma

building urbit. ~palfun-foslup

Posts1
Comments24
View on HN

Is there any reason besides merge commits ending up in history to not do this with merges instead? ie merge main into feature-1, then feature-1 into feature-2.

Sounds like using --update-refs would let you do all that in a single operation, but you still need to force-push and don't maintain an explicit merge/conflict resolution history, both of which could be considered sub-optimal for collaborative scenarios.

I appreciate the "just the current day" angle, but would gently remind about timezones. A 24-hour rotation isn't super friendly towards people who are online at the edges of that window. You might consider keeping a viewable archive of yesterday, just so one always has time to go back and see comments/replies.

Black to move, and in the final position, the pawn at h4 can be captured en-passant.

They're all legal.

But then, looking at the final position[1], black is in check by the knight on b2. If white's pawn can be captured en passant, this implies the knight was not the most recent move, so the black king was in check on the previous turn as well.

It's obviously not legal to remain in check. What am I missing?

[1] https://raw.githubusercontent.com/tromp/ChessPositionRanking...

Been using a Gergo for well over a year now. I think I might own the first one that was made with the low-profile Kailh Choc switches.

I can't imagine going back to anything else. The low profile, combined with custom key layout (workman, modifiers on homerows, etc) has done wonders for my RSI. Of course, tho "wow, what's that"-factor is also fun.

Not sure what nootropicat is on about.

The language itself is not coupled to the PKI. The PKI ("azimuth") is implemented as a contract on Ethereum. The OS ("arvo"), implemented in the language ("hoon"), has a networking module that respects the PKI, but also affords for (practically) infinite not-PKI-registered identities.

Urbit 7 years ago

Urbit does not run on or via blockchain. Its PKI lives on a blockchain. Urbit itself doesn't care about how packets get from A to B. You run it on a machine you own.

Social communications yes, especially on smaller/more "local" scales.

Full disclaimer: I recently started working for Urbit, but have been involved in its community for about a year and a half now.

It pains me to see people paint the project and its people in this light. I don't know if I'm taking the bait here or playing into your cards or whatever, but I want to try and clear some things up.

He is "The Master", and you are just too stupid to understand his pure clear thought.

Not really. He's actually been really helpful in explaining some of the decisions that were made in the past to me, and it never felt like my say in discussions regarding ongoing work didn't matter.

Anyone questioning anything with Urbit is either attacked, derided, ignored, or pushed aside You're just stupid, I guess.

I don't know what communities you've been in that people just go "you're stupid" when you don't understand something. In my experience with Urbit's chat rooms (and the forums, subreddit, etc.), people are generally friendly and understanding of the struggles that come with jumping into an entirely new stack like this. We know things can be confusing, we know it's hard when you're just starting out. We're also very much ready to help, and do care about discussing concerns and criticism.

I'd be willing to go so far as to say that, right now, Urbit's community is one of the nicest on the internet, but of course that's a tough comparison.

Aside, maybe interesting: the arcane naming of the Hoon stdlib is getting rewritten to be much more sensical and easily understandable. Why? Some community members were displeased, and someone took it upon themselves to make the rewrite happen. We're happily merging that in once it's done.

By definition, they all use Urbit to communicate.

And you can reach us without even installing Urbit on your machine. Take a look at http://urbit.org/stream/

any higher class user can disable sub-users' accounts

"Disable" isn't the right word here. A higher class can choose to stop helping a sub-user with peer discovery and to stop providing software updates to them. But if a sub-user is not content with the service their parent is providing, and/or they feel like they were unjustly blocked, they are free to find a parent that wants to adopt them.

Using that mechanism, communities that oppose each other can cleanly separate and continue doing their own thing without any bloodshed on either side.

not wanting to cut losses because there "could" be something.

Doesn't this apply to pretty much anything happening in the decentralization and crypto spaces right now?

I need say no more.

Well, I've never experienced "disapproval concerning jokes about the group". We're not above joking about the weirdness of our own system, it's something we're very much aware of.

Hi, member of the Urbit team here!

There was definitely a feeling of "holy shit they're doing our thing!" going around, but we can't be entirely sure if they got the idea from Urbit specifically. More likely, they aggregated ideas from all decentralization projects going on right now.

Definitely cool to see these kinds of ideas being represented in more mainstream media though!

Would this violate the terms of service of a system like Facebook?

Yep. As far as I'm aware they don't allow you to display Facebook content next to content of competing sites, like Twitter. But if everyone's doing that locally on their own machines, how will Facebook know? And what can they do to stop them?

If the API is being used, they can take that away. But website scraping will remain as a viable (if slightly sub-optimal) way of getting the data out. Facebook won't stop its users from using its website, after all.

Surely "sleeping barber" sounds like a much more attractive problem to work on than "sleeping dentist".

The point of the analogy is to assign the described traits to the discussed concept, instead of putting the concept in the world of the analogy.

You can only search data if you can read it, so it needs to be unencrypted. With end-to-end, this means only the data you have locally, so you can only do local searches. In the Slack example, (I assume) Slack uses their servers to pre-fetch search results for a faster experience.

Not OK, Google 10 years ago

I still feel this ideal will eventually be realized

Quick shoutout to Urbit here.