Re: [9fans] Transfer of Plan 9 to the Plan 9 Foundation

Wow, fantastic news! Congratulations! Is there any way we can donate to the foundation (time or money) to keep things moving along? On Tue, Mar 23, 2021 at 9:09 AM wrote: > We are thrilled to announce that Nokia has transferred the copyright of > Plan 9 to the Plan 9 Foundation. This

Re: [9fans] Software preservation in the post-hg era

> > > > How does it compare performance wise with git9 ? > > https://github.com/oridb/git9 > Based on the unscientific testing I just did of cloning the same repo (dgit's) a few times, they're in the same ballpark (~13s on 9front amd64.) git9 had a couple faster runs and dgit a couple slower

Re: [9fans] Software preservation in the post-hg era

On Mon, Mar 30, 2020 at 9:12 PM Sean Hinchee wrote: > As a footnote, there's a decent git client written in Go that works > alright on plan9 [4], but it's slow and memory intensive at the > moment. > > [...] [4] https://github.com/driusan/dgit This (and the fact that the speed of Go on

Re: [9fans] Software preservation in the post-hg era

On Tue, Mar 31, 2020 at 10:46 AM wrote: > > If anyone has further thoughts, anything they want added, or any lists > > or indices of works they want archived/mirrored, I would love to see > > these posted. > > I think the lede got buried here, and people went of discussing git > clients. > >

Re: [9fans] Request for (constructive?) comments: Plan 9 : 2020

On Tue, Oct 29, 2019 at 3:44 PM Lyndon Nerenberg wrote: > > Lyndon Nerenberg writes: > > > Maybe an unofficial get together around BSDCan in Montreal next spring? > > Doh! BSDCan is in Ottawa, not Montreal. The suggestion still stands. > Ottawa is only about a 2 hour drive from Montreal and

Re: [9fans] Git client

lan 9 box hasn't installed Perl. > > 2019年4月22日(月) 21:10 Dave MacFarlane : > > > > Nice work. (Note to self: avoid libexpat) > > > > Can you run the official git tests in the "t" subdirectory of the git > repo, or do they all depend on some of the ancillary

Re: [9fans] Git client

Nice work. (Note to self: avoid libexpat) Can you run the official git tests in the "t" subdirectory of the git repo, or do they all depend on some of the ancillary git commands that aren't built? If so, I'm curious how many of the tests are passing. On Sun, Apr 21, 2019, 07:07 Kyohei Kadota,

Re: [9fans] Git/fs: Possibly Usable

On Tue, Apr 2, 2019 at 12:49 AM wrote: > One caveat I have: Git's index file format is a bit > boneheaded, so I'm ignoring it. The index doesn't affect > the wire protocol, so this isn't an interoperability issue, > unless you share the same physical repository on both > Plan 9 and Unix. If you

Re: [9fans] plan9port : complete system : kernel : freebsd || linux ?

What do you mean by "a complete, installable system for plan9ports"? If you mean one that uses p9p in place of gnu utils, that's something I've thought about trying to do before, but I'd suggest taking it one step further and seeing if you could use a 9p root filesystem and see how far you can

Re: [9fans] aux/wpa

There's probably a better way, but I do: bind '#l1' /net echo 'key proto=wpapsk essid=wifiname !password=hunter2' >> /mnt/factotum/ctl aux/wpa -s wifiname /net/ether1 ip/ipconfig ether /net/ether1 auth=myauthserver in my /cfg/$host/termrc, since I don't have access to the secstore on

[9fans] Git

I've been trying to do more development of dgit under 9front instead of DragonFly so that it'll force me to catch/fix any major bugs missed by the test suite. I fixed one significant performance problem and now it seems to mostly be useable for basic git usage under Plan 9 (or at least 9front) and

Re: [9fans] 9front VMX

I've always found performance to be terrible for OpenBSD even on physical hardware, so I can't really hold that against vmx.. - Dave

Re: [9fans] Is Plan 9 C "Less Dangerous?"

On Tue, Sep 4, 2018, 22:31 Chris McGee, wrote: > > I believe that the core of the problem with the C language is that is >> based upon abstracting the PDP-11 instruction set. CPUs, such as Intel/AMD >> x64 are vastly more complex so "optimising" C compilers are trying to make >> something

Re: [9fans] question about #include_next directive

How advanced is your git usage? If you're only doing simple merges and pushes dgit (https://github.com/driusan/dgit) is approaching useful since someone taught me how to throw the official git test suite at it. I definitely wouldn't recommend it as a daily driver, but if you only want to push a

Re: [9fans] SCMs

On Feb 14, 2018 02:22, "Rui Carmo" wrote: > On 14 Feb 2018, at 01:47, Bakul Shah wrote: > > Dave MacFarlane's git client (dgit) does a decent job on plan9. This interests me greatly. Last time I checked there wasn’t a good enough got client, so I

[9fans] DKIM with upas

I started hosting my personal domain's email on 9front and wanted to sign my outgoing emails with a DKIM, so I wrote something in Go that reads a message from stdin and writes a DKIM signed version to stdout (https://github.com/driusan/dkim). I was planning on using it in /mail/lib/remotemail by

Re: [9fans] Go on amd64

Nevermind, the problems went away after recompiling 1.9.2 from source a second time, something must have went wrong with my initial bootstrap.. On Dec 20, 2017 19:29, "Dave MacFarlane" <driu...@gmail.com> wrote: What's the latest version of Go on amd64 that anyone's used succe

[9fans] Go on amd64

What's the latest version of Go on amd64 that anyone's used successfully? I just reinstalled 9front after putting in a new SSD on my laptop and I'm getting panics about errors lowering to SSA while trying to compile dgit, but I'm not sure if something went wrong bootstrapping go 1.9.2 or how much

Re: [9fans] git

David du Colombier's rc script is required to bootstrap my version anyways, so it's the best place to start (though dgit should work to for "go get" if you bind it to have the name "git" in your namespace). The upside of his is that it's more reliable and is less likely to have a bug that eats

[9fans] Reimplementing Plan 9 in Go (Was: Re: [9front] bio io functions)

On Fri, May 5, 2017 at 6:21 AM, Stanley Lieber wrote: > > Plan 9 has not yet been re-implemented in Go. > > sl > I started trying to do that at one point, but never got my kernel much farther than booting just enough to run "Hello, world!" compiled with 6c on a FAT

Re: [9fans] Raspberry Pi plan9, keyboard not working.

I recommend a simple wireless keyboard/mouse combo. That way the dongle only takes up 1 of the USB ports for both keyboard and mouse, since they share the dongle. I never had any problem with either of both the wireless combos that I've tried with Richard's arm port on my pi. (I think one was

Re: [9fans] SHA-1 collision and venti

Why not skip sha-256 and go directly to Sha3? On Sun, Feb 26, 2017 at 4:02 PM, Kim Shrier wrote: > I have had a personal project on my list of "things to do > when I have time", is to redo venti using sha256. Does > any body see any problems with doing that? > > Kim > > --

Re: [9fans] Update APE

Doesn't being a secret, dark hidden project imply existence? On Tue, Feb 21, 2017 at 5:20 PM, wrote: > Jens Staal writes: > >> If someone could backport apex from Harvey, that would be cool. > > I've seen this "Harvey" thing mentioned

[9fans] my git client, again

I finally got a laptop that can connect to my network under Plan 9 so I can work on my Go git client, and enough of it's done that I'm primarily developing it under 9front/amd64 now. I've caught most of the stupid things where I was taking for granted things that the official git client had done

Re: [9fans] [9front] DHCP not working on usb ethernet dongle

I don't think it's related, since there's no primary ethernet or /net on the laptop for it to conflict with (there's just a wifi card that isn't supported, which is why I needed the dongle in the first place.) I spent some time comparing nusb/ether/asix.c to the axeg(4) driver on my lunch hour

Re: [9fans] git client-ish

On Sat, Dec 3, 2016 at 8:12 PM, Chris McGee wrote: > > The tests seem to be passing. I will try more rigorous tests. If the github > bug gets fixed then I can submit pull requests. The bug that was preventing me from pushing to GitHub is now fixed, so if you update feel free

Re: [9fans] git client-ish

ests. If the github > bug gets fixed then I can submit pull requests. > > Cheers, > Chris > > On Dec 3, 2016, at 2:20 PM, Dave MacFarlane <driu...@gmail.com> wrote: > > I mentioned in another thread that I had started working on a pure go > git client a while

[9fans] git client-ish

I mentioned in another thread that I had started working on a pure go git client a while ago, then abandoned it, which gave me an itch to pick it up again. I've finally implemented enough that it can bootstrap its own development, and theoretically be used on Plan 9, but then I realized I don't

Re: [9fans] Plan 9 5th Edition

On Wed, Nov 16, 2016 at 6:53 PM, Chris McGee wrote: > For git, there's a wrapper script for github and others. But yes, a fuller > featured git would be good. There are some projects trying to do that in Go. > Maybe that'll work someday. I know I started a really half-assed,

Re: [9fans] More about /dev/draw

On Mon, May 30, 2016 at 8:37 AM, Richard Miller <9f...@hamnavoe.com> wrote: > > It turns out that the interface 9pi used for querying framebuffer depth > > is also now broken. Setting framebuffer_depth=N in config.txt used to > > work for changing the pixel format, now it doesn't. > > OK, new

Re: [9fans] More about /dev/draw

Probably a typo, I was going from memory. I thought it was a multiple of 8 bits per component, not for the whole thing, so that (and a typo) would explain it. But the bigger problem was that even if you only have 1 bit for r, g, and b you should be able to represent yellow as 110, so any

Re: [9fans] More about /dev/draw

, May 29, 2016 at 8:58 AM, Charles Forsyth <charles.fors...@gmail.com> wrote: > > On 29 May 2016 at 13:44, Dave MacFarlane <driu...@gmail.com> wrote: > >> Why would the alpha channel work differently with the same image from the >> same code with the same ha

Re: [9fans] More about /dev/draw

. The 50% alpha worked fine in drawterm but didn't change anything locally..) On Sun, May 29, 2016 at 6:50 AM, Charles Forsyth <charles.fors...@gmail.com> wrote: > > On 28 May 2016 at 18:23, Dave MacFarlane <driu...@gmail.com> wrote: > >> Does anyone have any pointers? >

Re: [9fans] More about /dev/draw

or plan9/arm. > > > On Sat, May 28, 2016 at 10:24 AM Dave MacFarlane <driu...@gmail.com> > wrote: > >> Either I'm going insane, the default Plan 9 /dev/draw in-memory >> implementation >> doesn't implement draw(3), or possibly both. >> >> Wh

[9fans] More about /dev/draw

Either I'm going insane, the default Plan 9 /dev/draw in-memory implementation doesn't implement draw(3), or possibly both. When I do the following, it works as expected under both drawterm and a locally mounted instance: 1. Allocate a screen with an 'A' message 2. Allocate an image on the screen

Re: [9fans] 9front sam in plan9port.

Speaking as the author of it, I wouldn't be offended by either. It's only, like, a week old, and mostly written for myself. But it's not going to work under Plan 9 until I finish the /dev/draw shiny driver that I started and have been procrastinating on finishing. I should probably try it and see

Re: [9fans] A couple questions about /dev/draw and /dev/kbmap

In that case, is there any way to get the current max packet size that 9p will allow for a read or write, or to determine if you're drawing to a local machine or not? I'm not seeing anything obvious under /dev or /env. On Wed, May 4, 2016 at 10:45 PM, wrote: > you wont

[9fans] A couple questions about /dev/draw and /dev/kbmap

Hi 9fans, I have most of a working prototype of a Go Shiny driver for Plan9, but there's a couple issues that I'd like to resolve and cleanup that I'd like to do. First, reads and writes to /dev/draw/n/data seem to fail if it's larger than 65536 bytes. At 4 bytes per pixel, that's not very much

Re: [9fans] Go on Plan 9?

I've managed to get Go running on an RPi2 using a similar method, but: 1. You need to make sure you're using go-tip. <= 1.6 doesn't have Plan9/arm support. 2. I had to apply this patch that Richard Miller sent me to my kernel: term% diff /n/sources/contrib/miller/9/bcm/mem.h /sys/src/9/bcm/mem.h