Hacker Newsnew | past | comments | ask | show | jobs | submit | dharmatech's commentslogin

I've been messing around with ocaml on plan9:

https://github.com/dharmatech/ocaml


Cool project!

Just for fun, looking at code count as a rough measure of complexity.

rubish: 26,842

rc (plan9 shell): 5,888

To be fair, rubish does a lot more than rc. rc is pretty minimal.

rc source:

https://github.com/9front/9front/tree/front/sys/src/cmd/rc

Measures below:

    $ wc -l `find . -name '*.rb'`
      1124 ./rubish/execution_context.rb
        43 ./rubish/frontend.rb
      260 ./rubish/builtins/hash_directories.rb
      510 ./rubish/builtins/echo_printf.rb
      834 ./rubish/builtins/bind_readline.rb
      182 ./rubish/builtins/directory_stack.rb
      299 ./rubish/builtins/read.rb
      324 ./rubish/builtins/trap.rb
      129 ./rubish/builtins/arithmetic.rb
      862 ./rubish/completion.rb
      988 ./rubish/expansion.rb
      431 ./rubish/completions/git.rb
      114 ./rubish/completions/ssh.rb
      530 ./rubish/completions/bash_helpers.rb
      453 ./rubish/completions/help_parser.rb
      167 ./rubish/ast.rb
        46 ./rubish/frontend/tty.rb
      1179 ./rubish/runtime.rb
      127 ./rubish/lazy_loader.rb
        63 ./rubish/data_define.rb
      1163 ./rubish/runtime/command.rb
      153 ./rubish/runtime/job.rb
      7270 ./rubish/runtime/builtins.rb
      306 ./rubish/config.rb
      2442 ./rubish/repl.rb
      1316 ./rubish/codegen.rb
      1180 ./rubish/lexer.rb
      742 ./rubish/history.rb
      1169 ./rubish/parser.rb
        67 ./rubish/startup_profiler.rb
      848 ./rubish/prompt.rb
        47 ./rubish/data/readline_config.rb
      716 ./rubish/data/builtin_help.rb
      251 ./rubish/data/shell_options.rb
        53 ./rubish/data/completion_data.rb
        5 ./rubish/version.rb
      248 ./rubish/shell_state.rb
      140 ./rubish/arithmetic.rb
        61 ./rubish.rb
    26842 total

rc:

    $ wc -l *.c *.h *.y
      547 code.c
    1173 exec.c
      234 getflags.c
      259 glob.c
      240 havefork.c
      137 here.c
      301 io.c
      436 lex.c
      169 pcmd.c
      78 pfnc.c
      494 plan9.c
      539 simple.c
      74 subr.c
      37 trap.c
      190 tree.c
      420 unix.c
      109 var.c
      85 exec.h
      72 fns.h
        7 getflags.h
      28 io.h
      167 rc.h
      92 syn.y
    5888 total


I definitely think we should be exploring decentralized approaches to services we use.

I also would like to see an emphasis on local-first approaches.

This experiment, in the spirit of UNIX, composes git and text files to form a social network:

https://github.com/dharmatech/9social

Video demo: https://youtu.be/q6qVnlCjcAI


Interesting, we've also experimented with hosting git repos on Freenet, see: https://github.com/freenet/freenet-git


Consider in your presentations leading with this as a demo to motivate the technical infrastructure you've put in place.

It is hard to grok what Contracts, etc. etc. allow you to do in the abstract so working through how it allows us to build a decentralized GitHub might be a good anchor in a tangible use case.


Appreciate the suggestion. It's often difficult to know where to start when explaining a project like this.

The freenet-git work is quite recent but we do feature River, our group chat app, fairly prominently on our installation page[1] so that people can quickly try out something useful. River is by-far the most fully developed app so far.

[1] https://freenet.org/quickstart/


This is cool!

OK, time for inception... 9social on freenet-git

¯ \ _ ( ツ ) _ / ¯


Hey pjmlp (waves),

I know you've been an advocate for OSes and languages that are outside of the mainstream.

I finally got around to living in plan9...

My experiment, a social network for plan9 written in rc and some awk.

https://github.com/dharmatech/9social


Cool! Trying out new ideas is very good way to open mindsets, even if those systems aren't used regularly, they serve as inspiration for future improvements.

The video is kind of interesting.


Thanks for checking it out, pjmlp!


I agree that owning the data is ideal:

https://news.ycombinator.com/item?id=48129841


Our social media should be decentralized and local first, allowing for bespoke clients on any OS.

This is an experiment towards that:

https://github.com/dharmatech/9social

The first client is written for plan9. This keeps the design honest. (If it can run on plan9/rc/acme...)

Video demo:

https://youtu.be/q6qVnlCjcAI

The current implementation is less than 3000 lines of code.

And speaking of Emacs... 9social was heavily inspired by an Emacs project called Org Social:

https://github.com/tanrax/org-social


> decentralized local-first social network that is based on git and plain text files.

Nice! This sounds just like what I'd been thinking the system should be like.

But how do you manage identity/authentication , or discovery of other users?


> how do you manage discovery of other users

Here's my personal profile on 9social:

https://github.com/dharmatech/9social-user-dharmatech

Each profile has a `following` file which shows who they're following:

https://github.com/dharmatech/9social-user-dharmatech/blob/m...

So, once you know someone on the network (now you know me!) you can see who they follow. And who each of them follow... And so on.


> how do you manage identity/authentication

Well, each user's profile is just a git repository (possibly on github). So I'd think about identity/authentication in the same way users think about it for their code projects.

If you have specific scenarios you're wondering about, feel free to ask.


> Nice! This sounds just like what I'd been thinking the system should be like.

Cool! Thanks for checking it out!


I love this idea. Thank you for the examples!

I've been thinking of this as well:

Something like old school Facebook in UI, but functions more like MSN Messenger. You connect to your contacts via P2P, and download/upload updates to your social media network.


> You connect to your contacts via P2P, and download/upload updates to your social media network.

Yup, local-first is central to the design.

And, you only see who you explicitly follow.


I love your username!

I hope there's a sympy-thagoras out there.

( • ‿ • )


Sounds similar to scuttlebutt


I absolutely LOVE secure scuttlebutt (SSB).

Their local-first approach inspired that aspect of the 9social design.

However, a big difference is that SSB is a sophisticated protocol.

With 9social, the heavy lifting is done by git and a set of conventions.


> I love this idea. Thank you for the examples!

Thanks for checking it out!


If you also want federation, end to end encryption, offline mode and collaborative edition, have a look at https://nextgraph.org


How to upvote in bold? /j


It's plan9 so:

"There's a filesystem for that."

¯ \ _ ( ツ ) _ / ¯


Amazing that it can run in plan9!

It would be awesome if go was a first class language on 9front. I.e. ships with it.

I've been messing around with a social network for plan9:

https://youtube.com/watch?v=q6qVnlCjcAI&si=MBCeM0QdA0WsKAe7

It's all in rc and awk. There are places where go (or clojure!) would have been nice.


Love the demo for 9social! I'm not a user myself but I'm always inspired by the Plan 9 ways :)


Thanks for checking it out!


I started publishing amd64 and arm (32) binaries for Plan 9 in GH releases. I tested the amd64 one on 9front and everything seems to work. The CLI is not very Plan9-y but I'm happy to make the port more native at some point :)


Ah, awesome!

I'll head over to the releases.


I've been messing around with a decentralized social network where you only see who you choose to follow.

It's implemented for plan9, but clients could be made for any OS:

https://youtube.com/watch?v=q6qVnlCjcAI


While reading though this book, I messed around with a basic computer algebra simplifier in Lean:

https://github.com/dharmatech/symbolism.lean

It's a port of code from C#.

Lean is astonishingly expressive.


How was the process of getting used to the ortholinear keyboard?


It took me much shorter than I expected, maybe a week or two. I'm quite quick on it now.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: