plan9port

Plan 9 from User Space (by 9fans)

Plan9port Alternatives

Similar projects and alternatives to plan9port

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a better plan9port alternative or higher similarity.

plan9port reviews and mentions

Posts with mentions or reviews of plan9port. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2023-12-25.
  • Show HN: Towards Oberon+ concurrency; request for comments
    6 projects | news.ycombinator.com | 25 Dec 2023
    [2] https://9fans.github.io/plan9port/
    6 projects | news.ycombinator.com | 25 Dec 2023
  • A pure C89 implementation of Go channels, including blocking and non-blocking selects
    4 projects | /r/golang | 11 Dec 2023
    If you find it too complicated and closely tied to Go internals, you can also check out Plan 9 from User Space's version, which is itself based on libthread from Plan 9 starting from 3rd edition, which is itself based on Alef's implementation of channels (Alef is Go's grandfather).
  • A tutorial for the Sam command language (1986) [pdf]
    5 projects | news.ycombinator.com | 20 Oct 2023
  • Makefile Tutorial
    5 projects | news.ycombinator.com | 22 Sep 2023
  • Mk: A Successor to Make [pdf]
    5 projects | news.ycombinator.com | 16 Jul 2023
    For those curious, Mk is available in Plan 9 from User Space

    https://9fans.github.io/plan9port/

    5 projects | news.ycombinator.com | 16 Jul 2023
    I tried plan9port's mk for a moment out of curiosity. I quickly ran into an annoying usability problem: it compares file mtimes with second accuracy.

    https://github.com/9fans/plan9port/blob/cc4571fec67407652b03...

    With sub-second build times for individual targets, this causes mk to needlessly recompile files because the target may have the same mtime as the prerequisites.

  • Plan 9 from User Space
    5 projects | news.ycombinator.com | 28 Apr 2023
  • Telegraph and the Unix Shell
    8 projects | /r/commandline | 31 Dec 2022
    Folks here might be interested in the Plan 9 user interface and how its terminal and shell interacted. The rio terminal window is lacking control codes, but then allows the user to select back history and edit it for resubmission to the shell. A port of it is available under X via the Plan 9 from User Space port project (https://9fans.github.io/plan9port/).
  • Golang is evil on shitty networks
    21 projects | news.ycombinator.com | 29 Dec 2022
    That code was in turn a loose port of the dial function from Plan 9 from User Space, where I added TCP_NODELAY to new connections by default in 2004 [1], with the unhelpful commit message "various tweaks". If I had known this code would eventually be of interest to so many people maybe I would have written a better commit message!

    I do remember why, though. At the time, I was working on a variety of RPC-based systems that ran over TCP, and I couldn't understand why they were so incredibly slow. The answer turned out to be TCP_NODELAY not being set. As John Nagle points out [2], the issue is really a bad interaction between delayed acks and Nagle's algorithm, but the only option on the FreeBSD system I was using was TCP_NODELAY, so that was the answer. In another system I built around that time I ran an RPC protocol over ssh, and I had to patch ssh to set TCP_NODELAY, because at the time ssh only set it for sessions with ptys [3]. It was a terrible default for trying to do anything that cared about latency.

    When I wrote the Go implementation of net.Dial, which I expected to be used for RPC-based systems, it seemed like a no-brainer to set TCP_NODELAY by default. I have a vague memory of discussing it with Dave Presotto (our local networking expert, my officemate at the time, and the listed reviewer of that commit) which is why we ended up with SetNoDelay as an override from the very beginning. If it had been up to me, I probably would have left SetNoDelay out entirely.

    As others have pointed out at length elsewhere in these comments, it's a completely reasonable default.

    I will just add that it makes no sense at all that git-lfs (lf = large file!) should be sending large files 50 bytes at a time. That's a huge number of system calls that could be avoided by doing larger writes. And then the larger writes would work better for the TCP stack anyway.

    And to answer the question in the article:

    > Much (all?) of Kubernetes is written Go, and how has this default affected that?

    I'm quite confident that this default has greatly improved the default server latency in all the various kinds of servers Kubernetes has. It was the right choice for Go, and it still is.

    [1] https://github.com/9fans/plan9port/commit/d51419bf4397cf13d0...

    [2] https://news.ycombinator.com/item?id=34180239

    [3] http://publications.csail.mit.edu/lcs/pubs/pdf/MIT-LCS-TM-65...

  • A note from our sponsor - InfluxDB
    www.influxdata.com | 25 Feb 2024
    Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality. Learn more →

Stats

Basic plan9port repo stats
27
1,547
6.7
about 1 month ago
Learn 300+ open source libraries for free using AI.
LearnThisRepo lets you learn 300+ open source repos including Postgres, Langchain, VS Code, and more by chatting with them using AI!
learnthisrepo.com