Re: [9fans] fd and /srv filesystem

[Chris McGee]

Thanks all for the explanations. I think I understand better now.

Chris

> On Oct 4, 2023, at 12:06 PM, o...@eigenstate.org wrote:
> 
> Quoth Chris McGee :
>> Hi All,
>> 
>> I was thinking about file descriptors in the context of Plan 9. On Unix an
>> fd is generally only usable by the current process, and child ones through
>> a fork with some special incantation if one wants to communicate one over a
>> domain socket. This is possibly for security reasons, avoiding other users'
>> processes from trying to guess the fd of a critical file.
>> 
>> It's common practice in Plan 9 to post an fd (sometimes via a pipe) from
>> one process to the /srv filesystem so that others can discover it and open
>> a comms channel. Does the kernel transform the fd into something when
>> posted to /srv so that it can be consumed by any other process in the
>> system?
>> 
>> Thanks,
>> Chris
>> 
> 
> it's all just Chans in the kernel; devsrv just provides
> a way of giving an open chan a name in the namespace.
> 

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tfaa2554a9b74c479-M5fd43d2e15b927fd76e19b2b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] fd and /srv filesystem

[Chris McGee]

Hi All,

I was thinking about file descriptors in the context of Plan 9. On Unix an
fd is generally only usable by the current process, and child ones through
a fork with some special incantation if one wants to communicate one over a
domain socket. This is possibly for security reasons, avoiding other users'
processes from trying to guess the fd of a critical file.

It's common practice in Plan 9 to post an fd (sometimes via a pipe) from
one process to the /srv filesystem so that others can discover it and open
a comms channel. Does the kernel transform the fd into something when
posted to /srv so that it can be consumed by any other process in the
system?

Thanks,
Chris

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tfaa2554a9b74c479-M6b518cab901dcf6bf60bd280
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] Can acme directory listings be customized through plumber?

[Chris McGee]

Hi All,

I heard somewhere that it should be possible to customize directory
listings in acme via some plumber rules. I'm hoping to append the contents
of a file if it exists in a particular directory below the listing.

I'm new to plumber and curious if this is possible. If so, where might I
look to learn more about how to put this together? If not, then I might
have a look at how to program this behaviour into my own copy of acme.

Thanks,
Chris

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T93887e657a7d3332-M027ba7847114382049e72168
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Drawterm GPU (was: Software philosophy)

[Chris McGee]

I was thinking that another way to get access to GPU across other OSes,
chipsets, etc. might be WebGL. I was going to try with one of the web
frontend drawterms out there (maybe aiju's) would be a reasonable starting
point to expose a gpufs and model how it would work such that someday it
could be implemented directly with Plan 9 drivers in the Plan 9 way.

On Sun, Aug 22, 2021 at 7:50 AM sirjofri 
wrote:

> I should mention I thought about the layout of a GPUfs some time ago. I
> just lack lots of knowledge about this, the gist was to write shader
> (code or compiled?) into some files, also write image data and mesh data
> to other files, abd reading results from other files. But as I said, I
> lack lots of knowledge about how GPUs work and never wrote any OpenGL
> code myself, only shader code. It always seemed like it's hundreds of
> hundreds of lines of code to draw a triangle (which is the basic hello
> world program).
>
> sirjofri
>
> 22.08.2021 12:04:41 Frank D. Engel, Jr. :
>
> > While not necessarily unwelcome as a possibility, I don't think
> > GPU-based drawing/gaming is as relevant to this discussion (or as
> > important of a goal for Plan 9 / 9front) as is GPU compute (GPGPU).
> >
> > The ability to leverage GPU resources across CPU servers for
> > computation purposes would be of great benefit to the platform, and
> > working out a driver interface by starting the process remotely via
> > drawterm seems like a sensible step in that direction.
> >
> > On 8/22/21 3:07 AM, sirjofri wrote:
> >>
> >> 22.08.2021 05:16:42 Eli Cohen :
> >>> deep learning is another interest of mine too. hardware support is a
> >>> big deal for that... some kind of support for GPUs would be nice.
> >>> people have discussed that for years... hardware drivers are
> >>> difficult
> >>> and important to do correctly!
> >>>
> >>> I always really liked the "XCPU" and drawterm type ideas of using
> >>> other OSes for their existing strengths along with Plan 9. maybe
> >>> drawterm could have a GPU device driver or something... that being
> >>> said I have sometimes found it ends up surprisingly easier doing it
> >>> all on Plan 9...
> >> That's also something I thought about a few times already: drawterm
> >> with GPU support. The only issue I see is, for realtime applications
> >> like games the draw times would be network bound and thus pretty slow.
> >> It would work for heavy GPU applications where almost no draw calls
> >> will exist (no textures, very low poly meshes, ...), but for heavier
> >> stuff we'd need to address that.
> >> That's the benefit of a native driver: you could calculate the server
> >> side (heavy CPU calculations) on a cpu server, the client/frontend
> >> side (including draw calls) on a terminal and the pure graphics on the
> >> GPU.
> >> I'd still give the drawterm GPU a shot. Maybe I can set drawterm up
> >> for compilation on my work PC (two GTX 1080Ti) and try figuring out
> >> how to do all that stuff. However, I've never done graphics
> >> applications on windows or somewhere else that uses OpenGL or DirectX
> >> (I'd try OpenGL because portability), only written shaders so far.
> >> I'll surely need some time (which is always rare as a game developer).
> >> Btw I don't know the exact specifications for GPU usage for neural
> >> networks. I assume it's all compute shaders? Maybe it's even a kinda
> >> blackbox, put stuff in (draw call), read things out. I assume this can
> >> work perfectly fine for draw times, depending on the data.
> >> sirjofri

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T65ec64adb5137874-M2811fbdfd8c6710bf58ff059
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Plan9 and Pine

[Chris McGee]

Thanks everyone for the ideas, background and links to add to my research.

Cheers,
Chris

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tca918503d5b19459-Ma961623aed6f9538e324bc9e
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] Plan9 and Pine

[Chris McGee]

Hello All,

I'm not sure how many on here are aware of the Pine SBC's. There are a few
different variants of those. Now there are even pre-built laptops and a
phone. There is a plan for a tablet too. https://www.pine64.org/

>From what I can tell the hardware is well documented, inexpensive and well
enough designed. There is a vibrant community that is currently working on
porting different Linux flavours to the phone. Once things are stable the
pine store will begin selling branded versions of the phone with the OS
pre-installed and a portion of the profit going to the community to
continue their work.

Has anyone managed to port Plan 9 to these SBC's? Does anyone have an idea
of how much work this would involve considering there's already 64-bit arm
toolchain in place and raspberry pi working?

Thinking longer term, might it be interesting or useful to this community
to support some of this hardware, even if it was just the Allwinner SoC's,
representing two of the SBC's lines, the original laptop, tablet and phone?
I wonder for example if it might spark some more interest for people to try
Plan 9 if they knew that there is a source of inexpensive and standardized
hardware and things work mostly out of the box.

I have some more far-fetched thoughts. Please, be gentle. :)

Perhaps this is an opportunity for the Plan 9 community to think what it
would mean to run in a phone form factor. From my experience with the
different phone OSes, there's quite a bit of similarity (home screens,
grids of "apps"). Maybe this can be done in more of a Plan 9 style,
simpler, smaller, more composable and no teletypes (or X). If the community
comes up with something then we have a hardware line capable of running it.
If the system is compelling enough to outsiders and a partnership is
established with the pine group then that might be an avenue to fund
continuing improvements.

And then, what about the tablet?

Thanks for reading.

Cheers,
Chris

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tca918503d5b19459-M5b625ce2ded89f4b59696e3a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] a simple graphical application in Go?

[Chris McGee]

You can try this Go library by mischief and some examples in the cmd
package:
https://bitbucket.org/mischief/draw9/src/default/

Last I recall, it worked fine on 9front. I'm not sure about the other
variants.

Cheers,
Chris

On Sat, Apr 4, 2020 at 9:54 AM Kim Lassila  wrote:

> Has anyone written a graphical application in Go on Plan 9? How would the
> Go equivalent of black.c (thank you fgb) look like?
>
> - - - clip - - -
>
> #include 
> #include 
> #include 
>
> void
> main(int, char *argv[])
> {
> Rectangle rect;
> Image *black;
>
> fmtinstall('R', Rfmt);
> if(initdraw(nil, nil, argv[0]) < 0)
> sysfatal("initdraw: %r");
> rect = screen->r;
> black = display->black;
> draw(screen, rect, black, nil, ZP);
> flushimage(display, 1);
> sleep(5 * 1000);
> closedisplay(display);
> print("rectangle was %R\n", rect);
> exits(nil);
> }
>
> *9fans * / 9fans / see discussions
>  + participants
>  + delivery options
>  Permalink
> 
>

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T0d490c91935dc74b-M59941541b5e841e6d425ac7e
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] PoE Support for Plan9 on RPI 4B/3B+?

[Chris McGee]

I can vouch for the fact that the Pi 1,2 and 3 work fine with a simple 12W
10/100 PoE network/power splitter. They work fine with 9front as it is
mostly transparent to the OS as far as I can tell.

Chris

On Mon, Mar 23, 2020 at 5:23 PM Skip Tavakkolian 
wrote:

> The PoE hat shouldn't need any software support. I don't have one, but
> it's basically a DC-DC converter. The Pi PoE hat has an Attiny processor
> for temperature sensing/fan operation.
>
> You can also use a PoE splitter (48V->5V/2.4A micro USB) which would work
> for all Pi's.
>
> -Skip
>
>
> On Mon, Mar 23, 2020 at 12:16 PM  wrote:
>
>> I have four Raspberry Pi model 4B boards and a Raspberry Pi model 3B+
>> board and would like to know whether or not Power over Ethernet (PoE) is
>> supported by the Pi9 port.
>>
>> Has anyone attempted to power a Plan9 cluster/grid over PoE? What PoE
>> network switches would you recommend? Were there any issues? Richard
>> Miller?
>>
>> To be clear, a PoE network enables boards to be powered over an Ethernet
>> network if a side-board (HAT) is connected. [1] A PoE network switch
>> conforming to IEEE 802.3af delivers power through the each Pi's RJ45
>> network connector over Cat 5 cabling. [2]
>>
>> To my knowledge, neither the 9front kernel sources nor the documented
>> list of supported hardware, specifically mentions PoE. [3] It seems the
>> network switch and HAT negotiate power delivery independently of the
>> kernel so I cannot think of a reason why Plan9 would not support
>> powering this way.
>>
>> References
>> [1]:
>> https://www.raspberrypi.org/blog/introducing-power-over-ethernet-poe-hat/
>> [2]: https://ieeexplore.ieee.org/document/1213877
>> [3]: https://9p.io/wiki/plan9/Supported_PC_hardware/index.html
>>
>> --
>> Barry Wasdell (bwasd)
>>
> *9fans * / 9fans / see discussions
>  + participants
>  + delivery options
>  Permalink
> 
>

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Td562795dfef0ca48-M5633cfb7e9950f738a1e7058
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Ottawa Spring 2020

[Chris McGee]

I live nearby and was considering attending BSDCan this year. How many
people do we think might be in the city around that time and interested in
a get-together? I think I count 3 or 4 at the moment.

There seemed to have been some interest about Plan 9 on Twitter among the
BSDCan groups when I did a post about it. I wonder if we they would mind
some non-BSD talks, BoF sessions at the conference itself? I think that the
call for papers deadline is in late January.

Cheers,
Chris

On Thu, Nov 7, 2019 at 7:27 PM Lyndon Nerenberg  wrote:

> BSDCan is June 3-6 2020.  There's a Postgres conference the week
> before at the same venue, so I'll be in Ottawa from May 25 to June
> 12 (taking some vacation time after BSDCan).  If anyone wants to
> do an informal get-together, let's see what we can work out.
> 
> --lyndon

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T565e07f732f7d831-M8349ac29c9fe6228fe55b16e
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[Chris McGee]

This sounds good to me, either Ottawa or Montreal. I've never been to
BSDCan. Could the meetup be part of the conference itself or would it need
to be separately arranged?

On Tue, Oct 29, 2019 at 4:03 PM Dave MacFarlane  wrote:

> 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 the train is
> relatively cheap.
> 
> (If there's enough people in the area and an interest in an unofficial
> Montreal get together, I can do what I can help organize..)
> 
> - Dave

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T2e674653159c4ce8-Mc37ca6b748fa35d38ed5538f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[Chris McGee]

It's really great to see this kind of activity.

I am unlikely to be able to come unless it is north eastern US or Canada,
maybe Toronto or Montreal. I know of at least one other Plan 9 tinkerer in
the area.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T2e674653159c4ce8-Ma9f958c3a3f57d1a528cc3a1
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] Pine64

[Chris McGee]

Hi All,

The Pine64 group is working on cheap and documented hardware for a variety
of form factors from compute modules to SBC and even laptops, tablets and
phones. https://www.pine64.org

It's all Arm 64. Has anyone managed to get Plan 9 running on one of these?
It looks like they are interested in getting a variety of software
platforms working on them.

Cheers,
Chris

Re: [9fans] Plan9 on radpberry pi zero ?

[Chris McGee]

Has anyone tried putting Plan 9 on one of these MIPS based SoC’s?

https://vocore.io/v2u.html

The hardware is supposedly open, which might make it easier to work on drivers.

Chris

Re: [9fans] Understanding /dev/draw

[Chris McGee]

Thanks David, you have saved me a bunch of work. If I were to fix/extend
the project would you be interested in the changes or should I just fork it?

On Thu, Apr 18, 2019 at 4:37 PM David Hoskin  wrote:

> > Does anyone know if David is still active in this space?
>
> Hi Chris,
>
> I'm still lurking the list, but I haven't touched this code in years.
> The basic drawing ops are alright but layers are maybe quarter baked.
> All of it is hacky student code written in a sort of lowest common
> denominator of Javascript in the style of C.
>
> That's cool that you were actually able to run it!
>
> -- David
>
> Sorry on behalf of my mail server:
>
>
> ***  Please note that this message and any attachments may contain
> confidential and proprietary material and information and are intended only
> for the use of the intended recipient(s). If you are not the intended
> recipient, you are hereby notified that any review, use, disclosure,
> dissemination, distribution or copying of this message and any attachments
> is strictly prohibited. If you have received this email in error, please
> immediately notify the sender and destroy this e-mail and any attachments
> and all copies, whether electronic or printed. Please also note that any
> views, opinions, conclusions or commitments expressed in this message are
> those of the individual sender and do not necessarily reflect the views of
> Fortinet, Inc., its affiliates, and emails are not binding on Fortinet and
> only a writing manually signed by Fortinet's General Counsel can be a
> binding commitment of Fortinet to Fortinet's customers or partners. Thank
> you. ***
>
>
>

Re: [9fans] Understanding /dev/draw

[Chris McGee]

Hi All,

I managed to get it running after all of these years. In case anyone tries
it again here's a few things that I had to do to get it to work on the
latest 9front.

* Copy the latin1.h header file from the bell labs distribution and copy it
into /sys/src/9/port
* Run ip/httpd/httpd -w /sys/web/9wd (this is where the installation copies
the web app)
* Patch /usr/web/9wd/js/draw/data.js by commenting out the "delete
conn.imgs[id];" line
* Future draw commands come in referring to the old image for some
reason and the server doesn't handle it well

Yes, when I coerce the websocket tool to launch rio instead of acme there's
some oddness when I launch new graphical apps within rio from the windows,
such as acme. They tend to think that they should occupy the entire screen.
Also, be patient because it is quite slow for now.

Does anyone know if David is still active in this space?

Erik, where can I learn more about the layers?

Thanks,
Chris

On Thu, Apr 18, 2019 at 2:08 PM erik quanstrom 
wrote:

> this implementation is enough to run acme,but not a full p9 terminal.
> you'll need layers for that.
>

Re: [9fans] Understanding /dev/draw

[Chris McGee]

Thanks, this looks to be exactly what I was hoping to do. The idea wasn't
as original as I thought.

On Thu, Apr 18, 2019 at 11:27 AM Skip Tavakkolian <
skip.tavakkol...@gmail.com> wrote:

> This might be a good place to start:
>
> https://bitbucket.org/dhoskin/9webdraw/src/default/
>
> On Thu, Apr 18, 2019 at 7:36 AM Chris McGee  wrote:
>
>> Hi All,
>>
>> I'm looking at creating an alternate filesystem for /dev/draw, /dev/mouse
>> and /dev/kbd that hooks up to a web server providing HTML interfaces (e.g.
>> canvas) for Plan 9 UI. I've been reading over the manual pages, which are
>> quite detailed, which is great, but there are some points of confusion for
>> me.
>>
>> In particular, /dev/draw's interface and documentation keep referring to
>> the concept of a "window" indirectly. It seems that in some cases the
>> server providing /dev/draw needs to track windows and refresh them. But,
>> what defines a window in this protocol? Is every image a window or only
>> some of them?
>>
>> Also, I'm trying to understand how off-screen images, such as fonts are
>> loaded. It seems that every image must be associated with a screen and be
>> given a position within the screen. So, how do you prevent the image from
>> being visible to the user?
>>
>> Hopefully, if I can understand some of the high-level concepts here then
>> the manual page will be all that I need. Does anyone have experience with
>> this area or could point me to information that might help clarify it?
>>
>> My next step will probably be to figure out how libmemdraw does all of
>> this on top of a frame buffer.
>>
>> Thanks,
>> Chris
>>
>

[9fans] Understanding /dev/draw

[Chris McGee]

Hi All,

I'm looking at creating an alternate filesystem for /dev/draw, /dev/mouse
and /dev/kbd that hooks up to a web server providing HTML interfaces (e.g.
canvas) for Plan 9 UI. I've been reading over the manual pages, which are
quite detailed, which is great, but there are some points of confusion for
me.

In particular, /dev/draw's interface and documentation keep referring to
the concept of a "window" indirectly. It seems that in some cases the
server providing /dev/draw needs to track windows and refresh them. But,
what defines a window in this protocol? Is every image a window or only
some of them?

Also, I'm trying to understand how off-screen images, such as fonts are
loaded. It seems that every image must be associated with a screen and be
given a position within the screen. So, how do you prevent the image from
being visible to the user?

Hopefully, if I can understand some of the high-level concepts here then
the manual page will be all that I need. Does anyone have experience with
this area or could point me to information that might help clarify it?

My next step will probably be to figure out how libmemdraw does all of this
on top of a frame buffer.

Thanks,
Chris

Re: [9fans] UI design | enhancements.

[Chris McGee]

Hi Darren,

Your goal seem to be to make the system less daunting for new users. I
think there are a number of ways to accomplish this.

Dressing up the UI and/or making it more like popular used interfaces might
be one way to make new users feel more comfortable. One concern with doing
this is that it allows them to come with other assumptions that may
confusions about how the underlying system works. This effort could also
increase complexity and size of the core system. Simplicity, size and
consistency are aspects of Plan 9 that I really value. Otherwise, I might
as well just use BSD or even Linux.

In my experience one of the biggest hurdles to getting curious new users to
give Plan 9 a try is just getting access to a namespace so that they can
give it a try and learn. I think that the quickest path at the moment is to
install it onto a VM like qemu (or yuck, virtualbox) since you can bypass
the whole hardware selection and compatibility pain points. I put some
YouTube videos up showing people step-by-step with a decent number of views
and comments, so I think this helped some people just to get their hands on
it. There are more ideas that I'm playing with to help people get started,
such as building a website where you can get a drawterm in your web browser
and give it a try.

Once a new user has access to the system there could be some exercises and
tutorials to engage them. There could be a variety of these depending on
the background, whether programmer, Linux user, librarian, whatever. The
key in my opinion is to not hide the core system with layer after layer of
"pretty" GUI's, but instead reveal it gradually with decent explanations. I
think that the core of Plan 9 is much easier to explain than other systems
because of its smaller size, relatively consistent interfaces and
versatility. Once you grasp one area it is much easier to begin grasping
more of it using the skills you already have. I can't say the same thing
about Linux or any other system that I have used. Like any tool, there is
some required learning and practice. Good tools amplify your learning as
you practice with it.

Once someone understands how Plan 9 works then I think they will have many
of the tools that they need to build their own networks with it. I
recommend digging into man pages and /sys/doc at this stage. There's a
wealth of well written guides in there, although some could be made a bit
more current. A guide on how to build a home network using raspberry pi
terminals and a CPU/file server from easy to acquire, but well designed,
modern hardware would be a welcome addition.

The system is far from perfect as others will tell you but there's advances
and fixes happening steadily. I'm just not sure if focusing on the initial
user experience through UI look and feel is adding much. I think a more
general discussion of GUI capabilities, such as video and 3D graphics
capabilities, would be great, but more in the context of what kinds of
tasks people want to accomplish. The trick is to fit those improvements
into the rest of the system and not just jamming them in.

Cheers,
Chris

Re: [9fans] any git client?

[Chris McGee]

There is the beginnings of a client written in Go here that should work in Plan 
9.

https://github.com/driusan/dgit

I have heard rumours of a port libgit2 somewhere.

Chris

> On Feb 3, 2019, at 9:32 AM, Mayuresh Kathe  wrote:
> 
> Is there any Git client available under Plan 9?
> If not, is there a port of "libgit2" available?
> 

Re: [9fans] Raspberry Pi 3 B+ image of 9front

[Chris McGee]

I have been intending to try out the new raspberry pi updates too for
9front, but haven't had the chance yet.

A couple of years ago I was building the sd-card images for my raspberry
pis by using qemu to bring up an x86 install of 9front and doing a
cross-compile within to build the new disk image. Here's a script that I
used after the manual 9front install to do that plus a bunch of other
things that you probably don't care about. It does need significant cleanup
and updates.

https://github.com/sirnewton01/rpi-9front/blob/master/postsetup.rc

I'm hoping that it is at least some help to others.

Chris

On Sat, Jan 5, 2019 at 12:10 PM Raingloom  wrote:

> Has anyone made one? I'm trying to put one together but the Plan 9 disk
> tools are... well they are quite different to what I'm used to. I managed
> to build the kernel and the userspace (with CONF=rpi2, which is afaik the
> correct one for rpi3 too?) and am trying to mirror the partitioning of the
> image by Richard Miller (at least more or less, I'll probably have to
> change things for HJFS) and combine the contents from that and a 9front VM.
> Is that a good way to go ahead?
>
>

Re: [9fans] Plan 9 potential target ports (Was: PDP11 (Was: Re: what heavy negativity!))

[Chris McGee]

> I do recall, vaguely, an Olimex comment about graphics being more
> accessible, but I did not make a note, the little that stuck was that
> some hardware manufacturer had embraced a slightly better standard
> than VESA, or some such. There may be some hardware out there that
> does not have "closed" graphics.
>

I thought that aijuboard got around this with an fpga implementation of a
frame buffer and hdmi signalling, but I suppose that ramps up the price
significantly as you'd need an fpga board in there and also an hdmi capable
lcd. Otherwise, I wonder how difficult it would be to set up a framebuffer
on the A64 like what was done with Richard's rpi code.

Chris

Re: [9fans] plan 9 : any pager?

[Chris McGee]

I like how the pager (page) actually shows a page on the screen with the
text you pipe to it. There's some real truth in the name.

On Wed, Oct 3, 2018 at 12:34 AM Mayuresh Kathe  wrote:

> thanks nick.
>
> On Tue, Oct 02, 2018 at 08:23:47PM -0700, Nick Owens wrote:
> > the pager is p(1).
> > On Tue, Oct 2, 2018 at 8:22 PM Skip Tavakkolian
> >  wrote:
> > >
> > > Turn off the scroll in the rio window that the shell is running in,
> then cat the file.
> > >
> > >
> > > On Tue, Oct 2, 2018, 8:15 PM Mayuresh Kathe  wrote:
> > >>
> > >> did plan 9 have any pager? or did every text file to be read had to be
> > >> opened in acme or a similar tool?
> > >>
> > >> btw, is there any pager under plan9port? didn't know what to search
> for,
> > >> hence couldn't find any.
> > >>
> > >> thanks,
> > >>
> > >> ~mayuresh
> > >>
> > >>
> >
>
>

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

[Chris McGee]

Thanks Richard,

This looks like it fits the bill: open, small, simple. How was it formally 
verified?

This doesn’t seem to need any of the chisel/scala suff, which is great.

How can I help with the compiler port? Which fpga board do you recommend?

Chris

On Sep 6, 2018, at 1:48 PM, Richard Miller <9f...@hamnavoe.com> wrote:

>> It could be, but after having looked briefly at the size of the design for
>> RISC-V Rocket and especially BOOM I wonder if it's all overly complicated.
>> They even built their own high level hardware language (Chisel) that
>> generates Verilog using Scala. Yuck.
> 
> It's possible to build a simple and perfectly usable RISC-V processor
> on an FPGA in verilog.  The one I use is
> https://github.com/cliffordwolf/picorv32 , written by Clifford Wolf.
> Its small size means it can be (and has been) formally verified, and
> (for some applications at least) you can compensate for the modest
> performance by putting lots of them on one chip.
> 
>> Also, there's appears to be quite alot of compiler optimizations in gcc for
>> RISC-based chips.
> 
> Again, it's possible to build a simple and perfectly usable C compiler
> for RISC-V without going overboard with optimisation.  I've been
> working on re-targeting the Plan 9 C toolchain for RISC-V.  It's at
> the stage where it can successfully compile itself, but floating point
> support is not yet complete.  If anyone is interested, let me know.
> 

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

[Chris McGee]

> What one wants is Plan 9 as a
> model for what may be a family of hardware APIs. It makes sense to
> promote massive parallelism, but the API to it should be sufficiently
> simple for a single individual to manage.
>

This is the what I wonder about. Is this possible at the hardware level and
still support an equally simple, understandable, yet capable, software
system on top? By extension, would Plan 9 would run on such a system or if
it would require some fundamental changes to adapt to it. For example, does
C really need to be thrown out or can it be revised.


> Most computing devices today are single-user, even those like my new
> Android phone that offer shared user capabilities. Incidentally, the
> authorisation model in this case is inadequate for my purpose (share
> with a pre-teen).
>

I am in this boat too, however I have a general aversion to cloud computing
and so I would need some household multi-user systems for data storage and
heavy processing tasks or some distributed equivalent.


> So we have layers and we need the complexity to be shoved into
> well-tested, sealed boxes that can be trusted, while the surface
> remains as simple as 9P.
>

My trouble is that I don't trust the sealed boxes anymore after Meltdown,
Spectre, Rowhammer, etc. Perhaps simple and auditable hardware might help
with this.

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

[Chris McGee]

> Take a look at greenarraychips.com and how Chuck Moore tries to
> simplify the whole instead of software or hardware.
>

Thanks, that is a very interesting read on the topic of asynchronous and
highly parallel computing. I'm not sure if the designs for these are very
simple though.

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

[Chris McGee]

> Wasn't that the whole point of RISC?
>

It could be, but after having looked briefly at the size of the design for
RISC-V Rocket and especially BOOM I wonder if it's all overly complicated.
They even built their own high level hardware language (Chisel) that
generates Verilog using Scala. Yuck.

Also, there's appears to be quite alot of compiler optimizations in gcc for
RISC-based chips.

Could you get away with a much simpler, smaller hardware design and still
run Plan 9 in a reasonable way? Maybe one side of the software/hardware
divide has to take on more complexity to help simplify the other side?

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

[Chris McGee]

> 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 simple take advantage of something far more complex.  Perhaps we
> should call them "complexifying" compilers.
>
> Generally, model-to-model transformations (which is effectively what
> compilers do under the covers) are easier to define when we transform from
> a higher level of abstraction to a lower level of abstraction.  As folks in
> the MBSE field explain it, trying to put a pig together from sausages.
>

I wonder if the hardware world suffers from some of the same complexity
problems the software world does. Is it possible to build much simpler
hardware as well or are there real physical properties that force them to
be as complex as they are now?

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

[Chris McGee]

> > Could even be that the many-eyes approach encouraged the complexity;
> > in fact, that could easily be the unintended consequence.
>
> I suppose it made complexity seem less bad, for a while, but I was
> thinking economic factors likely drove it to get more complex.  Also, I get
> the impression that some people just love complexity, but these days I'm
> not so sure.  Complexity does have some real benefits.
>

I hadn't considered this. I just assumed that complexity = job security +
sell + lock-in. It's easy to love something that is raking in the cash.

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

[Chris McGee]

Thanks everyone. This is pretty much what I expected was the case. I just 
wanted to confirm my understanding.

Plan 9 C was re-engineered with some
focus on readable code. Readability is expected to make bugs more apparent, 
making it less “dangerous.” Linux is so huge and hard to read that even simple 
things like C have become sharp edges that cut people. While the idea that many 
eyes makes bugs shallower seems to have failed in the world of complex behemoth 
software it may work here.

I’ve read some of the 9front kernel code trying to make it work on raspberry 
pi. I admit that I didn’t find any bugs at that time. The code is relatively 
easy to follow even for me. So, I suppose it’s working nicely.

Chris

> On Sep 3, 2018, at 12:07 AM, Lucio De Re  wrote:
> 
>> On 9/2/18, hiro <23h...@gmail.com> wrote:
>> "prevailing wisdom" sounds like an oxymoron.
>> 
> Yes, real wisdom is for some (evolutionary? counter-evolutionary?)
> reason unlikely to prevail.
> 
> Go figure.
> 
> Lucio.
> 

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

[Chris McGee]

Hi All,

I'm reading this article about how they are going through the giant heaping
pile of Linux kernel code and trying to come up with safer practices to
avoid the "dangers" of C. The prevailing wisdom appears to be that things
should eventually be rewritten in Rust some day.

https://lwn.net/SubscriberLink/763641/c9a04da2a33af0a3/

I'm curious how the Plan 9 C compiler fits into this story. I know that it
was designed to avoid many of the pitfalls of standard C. Does it try to
address some of these dangers or is it focused on making code more readable
so that problems are more apparent?

How does everyone feel about the Plan 9/9front kernel? Have they gone
through hardening/testing exercises over the years? I'm curious what tools
are available to help discover bugs.

Cheers,
Chris

Re: [9fans] Acme create new file

[Chris McGee]

Thanks all, these suggestions worked great. I don’t know how I missed it in the 
docs and tutorials.

Chris

> On May 13, 2018, at 5:49 AM, Charles Forsyth <charles.fors...@gmail.com> 
> wrote:
> 
> Type B filename in the tag of an existing frame in the directory and execute 
> it with button 2; or type B filename as a command in that directory in a win 
> frame or rio window.
> 
> 
>> On 13 May 2018 at 02:22, Chris McGee <newton...@gmail.com> wrote:
>> Hi All,
>> 
>> I’ve been using acme for a while and really enjoying the capability in such 
>> a small (code size) tool.
>> 
>> I’ve been creating new files by executing New to create a new window, typing 
>> the full path of the new file and then Put to save it. Am I missing an 
>> easier way to do this, perhaps via a directory window where I want the new 
>> file?
>> 
>> Thanks,
>> Chris
> 

[9fans] Acme create new file

[Chris McGee]

Hi All,

I’ve been using acme for a while and really enjoying the capability in such a 
small (code size) tool.

I’ve been creating new files by executing New to create a new window, typing 
the full path of the new file and then Put to save it. Am I missing an easier 
way to do this, perhaps via a directory window where I want the new file?

Thanks,
Chris

Re: [9fans] how to undo in Rio shell window and Acme editor?

[Chris McGee]

There’s a ‘win’ command you can executed in acme to get an interactive rc shell 
window.

> On May 9, 2018, at 11:40 AM, 刘宇宝  wrote:
> 
> Great thanks for your idea,  file oriented design is very flexible! The 
> prompt function may be used to automatically backup the output of previous 
> command,  a poor man's undo buffer :-D
> 
> I tried to execute "rc" in Acme, seems Acme always execution command with 
> /dev/null as stdin, I can't embed an interactive rc session into Acme and 
> leverage the undo buffer of Acme window.
> 
>> On May 9, 2018, at 10:14 PM, Steve Simon  wrote:
>> 
>> hi.
>> 
>> i think it is humour of a kind.
>> 
>> i cannot speak for acme but rio has no undo buffer, so what you ask for is 
>> not possible.
>> 
>> you can save a windows content (including history). e.g. /dev/wsys/11/text 
>> /tmp (assuming the window you want is number 11, cat /dev/winid to get the 
>> current windows id)
>> 
>> -Steve
>> 
>> 
>> On 9 May 2018, at 11:55, 刘宇宝  wrote:
>> 
> I miss much the *universal* shortcut Ctrl-z on Window and Command-z on 
> macOS,  does Rio and Acme have the equivalent?
> 
 
 Both the Ctrl key and the z key are fully supported on 9front Systems.
 To remove undesired characters from the screen, the Backspace key is
 also automatically provisioned, free of charge. 
>>> 
>>> Wow, is this kind of humor like the picture at the bottom of 
>>> http://fqa.9front.org/ ?
>>> 
>>> I'm not a troll,  I wrote several articles to introduce Plan 9 some days 
>>> ago, I'm seriously asking :-D
>>> 
>>> Maybe I already got the answer @_@
>>> 
>>> Thanks,
>>> Yubao Liu
>> 
>> 
> 

Re: [9fans] There is no fork

[Chris McGee]

Thanks everyone. This thread has been a fascinating read for me.

Chris

Re: [9fans] Backgrounding a task

[Chris McGee]

> Think about multiple processes owned by multiple users running on a
> cpu server.  Which processes should be allowed to join which
> namespaces?
> 
> Perhaps allowing only the hostowner to join namespaces for debugging
> and administration purposes would be acceptable.

Ah, right. What about only allowing a process to join another namespace if the 
user is the same?

> This seems a contrived example.  Would you really spend HOURS working
> on setting up a namespace by hand?  Surely you would instead be
> working on a script that builds the namespace for you; make the
> computer do the work.  Then when you mess up, you can modify the
> script, create a new window, and try again.

Yes, good point. That's the best way to do it. Also screen file can help add 
commands to the script post facto. The hours term isn't so much in the 
development of the environment but more to do with the amount of time you could 
be working in that shell instance. All the while not remembering all of the 
things you did to the namespace and environment in that time.

Cheers,
Chris

Re: [9fans] Backgrounding a task

[Chris McGee]

The namespace join facility looks interesting. Do you have a patch somewhere 
for it?

> Of course, a lot of the isolation that per-process namespaces give you
> is suddenly undone by the introduction of this facility.  

I'm not sure if the lack of isolation is any different than what can be done 
with a child process that shares the namespace. Is there a particular case that 
you are thinking?

> At this
> point I'm not entirely convinced that it's worth the trouble.

I think that it can be depending on how much time you have spent building up a 
namespace for a process. Perhaps I have spent hours working on something slowly 
customizing the namespace mounting and binding things. If I end up running a 
long running command that blocks and I want to work in parallel with it then I 
must remember everything that I have done and repeat in a new window. It seems 
like something the computer should do for me or at least help me to do it.

Re: [9fans] Go 1.4.3 compilation on Raspberry Pi

[Chris McGee]

There are some binaries available here if you want to use them to bootstrap:

http://www.9legacy.org/download.html

Chris

On Oct 11, 2017, at 6:13 AM, Richard Miller <9f...@hamnavoe.com> wrote:

>> I am trying to compile Go 1.4.3 on my Raspberry Pi following David's
>> instructions on https://github.com/golang/go/wiki/Plan9.
> 
> I believe that route to bootstrapping go from scratch on Plan 9
> will work only for 386.
> 
> On arm, you can either cross-compile go1.4 on another go platform
> (eg plan9/386, plan9port on linux/386, or linux/arm), or start with
> a pre-compiled plan9/arm package (there are several to choose from
> on http://www.9legacy.org/download.html).
> 
> Once you have that, you can run it on Plan 9 on the Raspberry Pi to
> bootstrap the current release of go.
> 
> 

Re: [9fans] Backgrounding a task

[Chris McGee]

Thanks for the tip! I'll give that a try.

Chris

> On Oct 7, 2017, at 12:04 AM, Skip Tavakkolian <skip.tavakkol...@gmail.com> 
> wrote:
> 
> Spitballing here: in the new window do something like
> 
> cat /proc/123/ns | rc 
> 
> Or first massage the ns then generate an output for rc.
> 
>> On Fri, Oct 6, 2017, 4:34 PM Chris McGee <newton...@gmail.com> wrote:
>> Hi All,
>> 
>> When I'm using Unix, there's a workflow that I use for long running commands 
>> that I'm hoping to find the equivalent in the Plan 9 way of doing things.
>> 
>> I will occasionally run a command, realize that it will take a long time to 
>> complete. I don't want to kill it. I'll just Ctrl-Z and bg to put it into 
>> the background using the shell. It's almost as if I had run it with '&' in 
>> the first place. I can then run other commands in the same working 
>> directory, environment and shell history.
>> 
>> Is there an equivalent to this workflow in Plan 9?
>> 
>> I realize that the whole job control system dates back to old single session 
>> terminals, which isn't a problem with Rio where you can draw new windows at 
>> will. Initially I thought, that you just drag that window to a corner 
>> somewhere and let it complete. But, if I draw a new window it won't be in 
>> the same working directory, have the same environment and namespace. Maybe 
>> there is a way to create a window that inherits these from an existing 
>> process?
>> 
>> Chris

[9fans] Backgrounding a task

[Chris McGee]

Hi All,

When I'm using Unix, there's a workflow that I use for long running commands 
that I'm hoping to find the equivalent in the Plan 9 way of doing things.

I will occasionally run a command, realize that it will take a long time to 
complete. I don't want to kill it. I'll just Ctrl-Z and bg to put it into the 
background using the shell. It's almost as if I had run it with '&' in the 
first place. I can then run other commands in the same working directory, 
environment and shell history.

Is there an equivalent to this workflow in Plan 9?

I realize that the whole job control system dates back to old single session 
terminals, which isn't a problem with Rio where you can draw new windows at 
will. Initially I thought, that you just drag that window to a corner somewhere 
and let it complete. But, if I draw a new window it won't be in the same 
working directory, have the same environment and namespace. Maybe there is a 
way to create a window that inherits these from an existing process?

Chris

[9fans] Test, please ignore

[Chris McGee]

Test

Re: [9fans] git client-ish

[Chris McGee]

Thanks for setting this up. It's going to be really helpful for my work.

Cheers,
Chris

> On Dec 5, 2016, at 12:14 PM, Dave MacFarlane <driu...@gmail.com> wrote:
> 
>> On Sat, Dec 3, 2016 at 8:12 PM, Chris McGee <newton...@gmail.com> 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 to pull request away.
> 
> - Dave
> 

Re: [9fans] git client-ish

[Chris McGee]

Thanks for the tool.

I managed to get it working on plan9front/386 Go 1.8 beta1 with a network 
connection. I will probably try it soon on plan9/arm.

Initially, it did not compile. Here are the quick fixes that I needed to make.

1) There is no syscall.Stat_t on plan9, instead the stat.Sys() returns a 
syscall.Dir

index.go:AddFile():
I changed stat to be fstat.Sys().(*syscall.Dir)
csec = stat.Mtime (This is how APE maps ctimes)
cnano = uint64(0) (There does not seem to be any nanosecond precision on mtimes 
in plan9)
uint32(stat.Qid.Path) (Roughly equivalent to inode numbers)
uint32(0) (GID’s are strings in plan9)
uint32(0) (UID’s are strings)
I assume that you want the library to be platform neutral so these should 
probably be abstracted.

2) Compile error

sha1.go:GetTree()
Sha1FromString(commit.Tree.Id.String())

The tests seem to be passing. I will try more rigorous tests. If the github bug 
gets fixed then I can submit pull requests.

Cheers,
Chris

> On Dec 3, 2016, at 2:20 PM, Dave MacFarlane  wrote:
> 
> 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 currently have any machines with all of
> Plan 9, Go, and a network connection to test it on.
> 
> Would someone who has all of the above kindly try compiling it on Plan
> 9 and let me know if there's any problems? It's at
> https://github.com/driusan/go-git.You'll need the 9legacy git rc hack
> for Go to bootstrap it..
> 
> You should be able to:
> go-git init
> go-git clone*
> go-git fetch*
> go-git add file (from the root of the working directory only)
> go-git checkout file (same)
> go-git commit -m 'message'
> go-git status
> go-git merge (fast-forward only)
> go-git push works over https to GitLab, but not GitHub (GitHub
> responds with "200 OK" and no body but doesn't update the references,
> so I opened a ticket to see if I can get more information from them
> about why it doesn't work.. you also need to run as "go-git push
> localbranchname", which isn't the standard git command line.. )
> 
> The happy paths for a few other git plumbing commands are implemented.
> 
> The code's not very well written (I didn't know much about git
> internals or Go when I started, and mostly just wanted to hack
> something together that works at first), but if anyone wants to
> contribute, you can try to email me a patch using ape/diff in some
> kind of format that I can apply under DragonFlyBSD and commit under
> your name until whatever the issue with GitHub is is resolved..
> 
> * large repositories will likely crash because the Go zlib
> implementation is greedy on the underlying io.Reader, and the hack
> that I added to rewind to the end of the last compressed block when
> reading packfiles isn't 100% accurate.
> 
> - Dave
> 

[9fans] New 9front image for raspberry pi

[Chris McGee]

Hi All,

I have published a new version of 9front image for raspberry pi. This version 
has a draft of an interactive tutorial in acme. I hope that it can help new 
people like myself to discover some of the basics of the system.

https://github.com/sirnewton01/rpi-9front/releases/tag/nov2016-4 


Cheers,
Chris

Re: [9fans] Using plot(1)

[Chris McGee]

Thanks,

> not sure what you mean by pipe the output, if you want to save the graph
> you need to do that by grabbing the window, there could be things like 
> gifplot which render the plot command stream into a gif, but it doesn't (yet).

Yes, this is what I was after. I'll try fetching the window buffer and extract 
it from there. I'll see if a command line switch can be added easily to plot to 
do just that.

> i am pretty sure graph has a "don't clear the screen" option if that will do 
> for you,
> however my suspicion is that if you close and reopen the stream to plot it 
> will
> clear and redraw the screen. i thing (guess) that you would need to send all 
> your
> plot commands in a single stream.

I was thinking that if plot didn't automatically clear the window (maybe with 
an option) you could add a background to the plot. Another option could be for 
plot to have an image command that imports and draws one from a file.

>> o
>> ra -1.0 -1.0 1.0 1.0
>> e
>> co r
>> cf r
>> di 0.0 0.0 1.0
>> co k
>> li 0.0 -1.0 0.0 1.0
>> li -1.0 0.0 1.0 0.0
>> cl


I tried this same plot program on a raspberry Pi with much slower graphics and 
I noticed that the red circle is drawn for an instant and then disappears 
behind a white box that covers most of it. I tried it without the lines and 
it's the same thing. Not sure what is clipping the circle. Very strange.

Chris

[9fans] Using plot(1)

[Chris McGee]

Hi All,

I’m trying graph and plot out. I have some questions.

Is there a way to pipe the output of plot or do I need to pull that out of the 
screen/window buffer? Also, is there a way to plot on top of an existing image?

I tried making a simple plot routine to draw a red unit circle with x and y 
axes. The lines are drawing fine, but the circle is completely cut off except 
for a hint of the top-most and bottom-most edges. Here’s the routine that I’m 
using. Is there something obvious that I’m doing wrong?

o
ra -1.0 -1.0 1.0 1.0
e
co r
cf r
di 0.0 0.0 1.0
co k
li 0.0 -1.0 0.0 1.0
li -1.0 0.0 1.0 0.0
cl

Thanks,
Chris

Re: [9fans] Trouble finding current window directory in acme

[Chris McGee]

Thanks, that will work.

Chris

> On Nov 26, 2016, at 12:56 PM, Antons Suspans <an...@ml.lv> wrote:
> 
> On Sat, Nov 26, 2016 at 12:41:21PM -0500, Chris McGee wrote:
>> How does one get the /dev/acme/acme directory to be present in a normal 
>> document window? Alternatively, is there a simple way to find the index of 
>> the current acme window so that I can use the /dev/acme/x directory?
> 
> Use /mnt/acme/$winid for that purpose. It's described in acme(1).
> 
> Hope this helps,
> Antons
> 

[9fans] Trouble finding current window directory in acme

[Chris McGee]

Hi All,

I’m in the process of writing an interactive tutorial for plan9/acme. I’m 
hoping to demonstrate how to execute a command on a text file that uses the 
current selection as input.

According to the acme manual page there should be a /dev/acme/acme (or 
/mnt/acme/acme) directory that represents the current window within acme. There 
should be the usual body, ctl, addr, etc. files. On a regular document window 
I’m finding that the directory is empty. However, when I run an interactive 
“win” window the files are there for that window.

How does one get the /dev/acme/acme directory to be present in a normal 
document window? Alternatively, is there a simple way to find the index of the 
current acme window so that I can use the /dev/acme/x directory?

Thanks,
Chris

Re: [9fans] How to take a portion of a screenshot

[Chris McGee]

I tried to write an rc script that would make a screen video as an animated 
gif. I have something that almost works, but ran into a few 
problems/limitations.

* I can’t seem to find a way to have an incrementing loop counter in rc shell 
(best I could do is check the size of a growing list variable)
* The gif command barfs when the GIF is any larger than a few megabytes due to 
an allocation error
* I couldn’t think of a good way to name the image files so that they can be 
sorted into the correct sequence as input to togif

I’ll try banging my head on the solution again tomorrow. I’m hoping that either 
it can be a one-liner of rc shell scripting or put into a full utility script 
(e.g. recscreen) that anyone could use.

Thanks,
Chris

> On Nov 23, 2016, at 3:07 PM, Skip Tavakkolian <9...@9netics.com> wrote:
> 
>> it's one of the reasons I'm liking plan 9.
> 
> ingenious glenda.
> 

Re: [9fans] How to take a portion of a screenshot

[Chris McGee]

Thanks Richard,

That is the kind of thing I was looking for. And yes, it's one of the reasons 
I'm liking plan 9. Each piece does one thing we'll.

Chris

On Nov 23, 2016, at 11:06 AM, Richard Miller <9f...@hamnavoe.com> wrote:

>> I'm working on some documentation and would like to include a portion of the 
>> screen in a particular window. What's a good way to take the shot but also 
>> snip out the piece that I'm interested in?
> 
> Making a screenshot is one of those delightful examples of
> the elegant simplicity of Plan 9:
> 
>cat /dev/screen >screenshot.pic
> 
> To select a rectangle from an image you can use crop(1)
> 
> 

Re: [9fans] Plan 9 5th Edition

[Chris McGee]

This one might be adapted to work for gitlabs. It only supports read only type 
commands: clone, checkout, pull.

http://9legacy.org/9legacy/tools/git

It could be a start.

Chris

> On Nov 21, 2016, at 10:08 AM, Wes Kussmaul  wrote:
> 
> 
> 
> On 11/21/2016 03:46 AM, Sigrid Haflinadóttir wrote:
> 
> 
>>Very kind!  Where can I download your Plan 9 git client?
> 
> I'm afraid mine is something of a "stone soup" offering. Perhaps someone can 
> add value to the soup by providing a client.
> 
> 
> -- 
> Wes Kussmaul
> 
> The Authenticity Institute
> 738 Main Street
> Waltham, MA 02451
> 
> office +1 781 790 1674
> mobile +1 781 330 1881
> 
> THIS COMMUNICATION IS INTENDED ONLY FOR THE USE OF THE PERSON TO WHOM IT IS 
> ADDRESSED.
> 
> If it was addressed incorrectly there's not much I can do but ask you 
> politely to pretend you didn't see it. Any disclaimer suggesting that the 
> sender has some kind of recourse is just wishful thinking.
> 
> If I had a message from you that was digitally signed using your Osmio VRD™ 
> identity credential from the Osmio Vital Records Department 
> (http://osmio.ch), we could easily and at no cost exchange
> encrypted messages and files with each other.
> 
> 
> 

Re: [9fans] Plan 9 5th Edition

[Chris McGee]

I like the idea of focusing on the functionality, not specific software, that 
could go into a 5th edition. It seems that stepping back and rethinking popular 
industry trends led to some of the unique and interesting decisions that gave 
us plan9 in the first place.

Here is what I'd like to see
-3D graphics (something akin to /dev/draw except for graphics pipelines)
-Location capabilities (gps, map drawing, routing)
-Mobile interface (clean, simple, optimized for small and touch screens)
-2D graphics editing (edit photographs or make raster art from scratch, layers, 
antialiasing, filesystem for scripting)
-3D printing (manipulate 3D model data, output one of the standard formats for 
printers)
-Knowledge/AI system (plug in statements, make inferences)
-Notifications (deliver events, alerts and reminders to my attention in a 
consistent manner)
-Search quickly for files based on content (indices, also accessible via 9P, 
there's a paper floating around about this)
-Easily find disk space statistics (free disk space for each file system)
-Single Instruction Multiple Data (language and compiler for writing programs 
that can use these special instructions)
-Video playback and recording (support for most popular 3 codecs, including one 
of the free ones, syncing of audio stream, record from camera and/or screen)
-Clean HTML (not fully featured web browser, instead render existing HTML in a 
clean, readable way, not unlike the various reader modes in popular web 
browsers, convert to PDF/PS)

I think that each of these can be done in the plan9 way with simple, consistent 
and elegant implementations that integrate well with the rest of the system. 
The focus is to enable capability and not necessarily to just port existing 
software, repeating existing complexity and bloat.

Chris

> On Nov 19, 2016, at 3:37 PM, Charlie Lin  wrote:
> 
> Any features that should be incorporated into Plan 9?
> 
> 
>> On Nov 16, 2016 17:27, "Charlie Lin"  wrote:
>> Any plans for Plan 9 5th edition?
>> 
>> My desires:
>> ISO-compliant C compiler and preprocessor
>> Port other programming languages (especially Go) to here
>> Start a source code repository
>> Port Git, SVN, Mercurial, et cetera to here

Re: [9fans] Plan 9 5th Edition

[Chris McGee]

There's also Gogits.

https://github.com/gogits/git

I haven't tried it yet.

Chris

> On Nov 17, 2016, at 11:16 AM, Dave MacFarlane <driu...@gmail.com> wrote:
> 
>> On Wed, Nov 16, 2016 at 6:53 PM, Chris McGee <newton...@gmail.com> 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, wholly-abandoned implementation
> here: https://github.com/driusan/go-git
> when I was starting to learn Go so that I could fix a bug in some of
> my code on Plan 9 (eventually I just made
> the change, tested it, and copied the file to a supported git platform
> over drawterm, and commited it from there..)
> 
> Who else is trying to do it?
> 
> - Dave
> 

Re: [9fans] Plan 9 5th Edition

[Chris McGee]

It doesn't build for me anymore. Fixing the make file seemed non trivial.

Chris

> On Nov 17, 2016, at 12:50 PM, Ori Bernstein <o...@eigenstate.org> wrote:
> 
> https://bitbucket.org/oridb/libgit2
> 
> If someone wants to actually turn it into a git client, it at least builds
> (or used to).
> 
>> On Thu, 17 Nov 2016 11:16:20 -0500, Dave MacFarlane <driu...@gmail.com> 
>> wrote:
>> 
>>> On Wed, Nov 16, 2016 at 6:53 PM, Chris McGee <newton...@gmail.com> 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, wholly-abandoned implementation
>> here: https://github.com/driusan/go-git
>> when I was starting to learn Go so that I could fix a bug in some of
>> my code on Plan 9 (eventually I just made
>> the change, tested it, and copied the file to a supported git platform
>> over drawterm, and commited it from there..)
>> 
>> Who else is trying to do it?
>> 
>> - Dave
>> 
> 
> 
> -- 
>Ori Bernstein
> 

Re: [9fans] Plan 9 5th Edition

[Chris McGee]

A C compiler that supports the latest spec would be nice as long as it doesn't 
sacrifice compile times. I like how quickly the system can recompile itself. 
Maybe extend pcc to include new features?

Go works pretty well and is on its way to be a supported platform. I use it 
quite frequently on 9front.

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.

Mercurial is already there on 9front via python.

Chris

> On Nov 16, 2016, at 5:27 PM, Charlie Lin  wrote:
> 
> Any plans for Plan 9 5th edition?
> 
> My desires:
> ISO-compliant C compiler and preprocessor
> Port other programming languages (especially Go) to here
> Start a source code repository
> Port Git, SVN, Mercurial, et cetera to here

Re: [9fans] Hack font for plan9

[Chris McGee]

Thanks for checking it out.

I'll check the tool for sizing problems.

Chris

On Nov 16, 2016, at 9:27 AM, Steve Simon  wrote:

>> I have converted the open source font called Hack to plan 9 font format.
> 
> Thats nice, not sure if I will switch, I will try it for a week or so...
> 
> I think the sizes are wrong, the 14 point in the hack directory looks close 
> to 9 point in
> the plan9 pelm font.
> 
> -Steve
> 

[9fans] Hack font for plan9

[Chris McGee]

Hi All,

I have converted the open source font called Hack to plan 9 font format. It's 
designed to render source code and is working well for me.

https://github.com/sirnewton01/plan9-font-hack/releases

I used the this tool to convert it.

https://github.com/sirnewton01/ttf2plan9

I hope that they are useful.

Chris

Re: [9fans] Making available a pre-compiled go binary for Miller's plan-9 Pi image (Chris McGee)

[Chris McGee]

Thanks David,

Will you add new Go releases there as they come out so that we can bootstrap 
from previous releases?

Also, the Git script is working quite well for me. Thanks for that too.

Chris

> On Nov 13, 2016, at 1:07 PM, David du Colombier <0in...@gmail.com> wrote:
> 
> I've updated the Go binary packages with the fix to make.rc:
> 
> http://9legacy.org/download/go/go1.7.3-plan9-386-bootstrap.tbz
> http://9legacy.org/download/go/go1.7.3-plan9-amd64-bootstrap.tbz
> http://9legacy.org/download/go/go1.7.3-plan9-arm6-bootstrap.tbz
> http://9legacy.org/download/go/go1.7.3-plan9-arm7-bootstrap.tbz
> 
> -- 
> David du Colombier
> 

Re: [9fans] 9front on raspberry pi

[Chris McGee]

> On Nov 7, 2016, at 6:44 AM, arisawa  wrote:
> 
> by the way I said about raspi 1
>> the display size is 1920x1200.
>> when I try to resize a window, the mouse cursor flips and it is difficult to 
>> resize.
> This phenomenon was stopped when I connected lan cable.
> I don’t know the reason.

Interesting data point. Thank you. I tend to keep mine plugged into an active 
Ethernet switch. I'll try without to see if I can narrow down the problem.

> 
> I looked the source code and I guess for raspi 1:
> Plan9BCMpin
> GPIO01711
> GPIO11812
> GPIO22713
> GPIO32215
> GPIO42316
> GPIO52418
> GPIO62518
> GPIO7 4 7
> GPIO82824
> GPIO92921
> GPIO1030?
> GPIO1131?
> SDA 2 3
> SCL 3 5
> CE1 726
> CE0 824
> MISO 921
> MOSI1019
> SCLK1123
> TxD14 8
> RxD1510
> 
> and I tried some experiments.
> 
> (a) turn led light on/off that is connected to GPIO0 pin

Cool, good to know that part is working for others.

> 
> term% echo function out GPIO0 >ctl
> term% echo 1 > GPIO0
> term% echo 0 > GPIO0
> term% 
> 
> the result is OK.
> 
> (b) read GPIO1 status
> 
> term% echo function in GPIO1 >ctl
> 
> I expected:
> term% cat GPIO1# low voltage
> 0
> term%
> 
> however I have:
> term% cat GPIO1# low voltage
> 00...
> 
> I expected:
> term% cat GPIO1# high voltage
> 1
> term%
> 
> however I have:
> term% cat GPIO1
> 11...
> 
> is this a feature or bug?
> 

This part is inherited and merged in from original 9front source code. As we 
discussed before there seems to be no manual page. I'm not sure the intended 
behaviour and I have not yet tried reading from a gpio pin myself.

So in either case on the read it just repeats forever until interrupted?

Chris

Re: [9fans] 9front on raspberry pi

[Chris McGee]

Hi All,

I have cleaned up some of the concurrency code and USB. The new release is here:
https://github.com/sirnewton01/rpi-9front/releases/tag/nov2016-2 


Thanks,
Chris

Re: [9fans] 9front on raspberry pi

[Chris McGee]

Apologies Richard for misspelling your last name.

Chris

> On Nov 1, 2016, at 9:35 PM, Chris McGee <newton...@gmail.com> wrote:
> 
> Hi All,
> 
> I have released an experimental 9front raspberry pi image that I use for my 
> cluster.
> https://github.com/sirnewton01/rpi-9front/releases/tag/nov-2016
> 
> Highlights:
> -Latest 9front release 2016-10-27
> -Merged in Richard Millar’s kernel from a couple of months ago
> -Retains 9front GPIO filesystem structure
> -Link local ipv4 address on boot (low likelihood of collisions)
> -Discovery of other nodes using multicast DNS through the ‘find9p’ command
> -9fs mount other nodes on the network
> -Go 1.7.3
> -Git script (works with github and google source repos)
> 
> Cheers,
> Chris

Re: [9fans] 9front on raspberry pi

[Chris McGee]

Thanks,

I'm thinking that could be related to USB problem making the mouse jump around.

Chris

> On Nov 2, 2016, at 8:05 AM, arisawa <aris...@ar.aichi-u.ac.jp> wrote:
> 
> hello Chris,
> 
>> 2016/11/02 20:17、Chris McGee <newton...@gmail.com> のメール：
>> 
>> What's wrong with the large display?
> 
> the display size is 1920x1200.
> when I try to resize a window, the mouse cursor flips and it is difficult to 
> resize.
> 
> 

Re: [9fans] 9front on raspberry pi

[Chris McGee]

> but something weird.
> term% mount -a '#G' /dev
> mount: can’t open '#G': permission denied
> I don’t know the reason.

Maybe you want to use bind instead?

> 
> using large display is frustrating...
> my portable HDMI display of 1280x800 works fine.
> 

What's wrong with the large display?

Re: [9fans] 9front on raspberry pi

[Chris McGee]

The GPIO doesn't have a manual page as far as I know. The implementation came 
from what is in 9front mainline and is in #G. I agree that it would be good to 
have a manual page for it there.

mDNS is running as bcast9p process and is written in Go. It's based on a Go 
library and uses udp multicast support for plan 9 that is only in latest git 
master branch, slated for Go 1.8.

Go SDK in this image is 1.7.3 though. It should be reasonably stable.

Chris

> On Nov 2, 2016, at 3:57 AM, Steve Simon <st...@quintile.net> wrote:
> 
> hi,
> 
> this is interesting.
> 
> can you tell me what the gpio file system looks like (pointer to man page?). 
> also, is the mDNS client the go one discussed recently or a c implementation?
> 
> i have never go'ed and have been thinking about writing a upnp renderer for 
> plan9 for years...
> 
> -Steve
> 
> 
>> On 2 Nov 2016, at 07:48, arisawa <aris...@ar.aichi-u.ac.jp> wrote:
>> 
>> I’ve tried both pi1 and pi2.
>> both devices successfully boot up.
>> 
>> my impression only in primitive usage is:
>> pi2 is fine. thanks Chris!
>> pi1 is a bit unsteady on usb device. usb keyboard is sometimes accidentally 
>> detached.
>> 
>> 
>>> 2016/11/02 14:05、arisawa <aris...@ar.aichi-u.ac.jp> のメール：
>>> 
>>> thanks, i will try.
>>> 
>>> is this for pi1 or pi2 or both?
>>> 
>>>> 2016/11/02 10:35、Chris McGee <newton...@gmail.com> のメール：
>>>> 
>>>> Hi All,
>>>> 
>>>> I have released an experimental 9front raspberry pi image that I use for 
>>>> my cluster.
>>>> https://github.com/sirnewton01/rpi-9front/releases/tag/nov-2016
>>>> 
>>>> Highlights:
>>>> -Latest 9front release 2016-10-27
>>>> -Merged in Richard Millar’s kernel from a couple of months ago
>>>> -Retains 9front GPIO filesystem structure
>>>> -Link local ipv4 address on boot (low likelihood of collisions)
>>>> -Discovery of other nodes using multicast DNS through the ‘find9p’ command
>>>> -9fs mount other nodes on the network
>>>> -Go 1.7.3
>>>> -Git script (works with github and google source repos)
>>>> 
>>>> Cheers,
>>>> Chris
>>> 
>>> 
>> 
> 
> 

Re: [9fans] 9front on raspberry pi

[Chris McGee]

Thanks for trying it out. Can you raise a github issue with any error messages 
or data that I can use to try to fix the problem?

I understand that Richard's kernel that I used should work with Pi 1, 2 and 
zero. I have tried it with a Pi 1 B+ and Pi 2 B.

Sent from my iPhone
> On Nov 2, 2016, at 3:48 AM, arisawa <aris...@ar.aichi-u.ac.jp> wrote:
> 
> I’ve tried both pi1 and pi2.
> both devices successfully boot up.
> 
> my impression only in primitive usage is:
> pi2 is fine. thanks Chris!
> pi1 is a bit unsteady on usb device. usb keyboard is sometimes accidentally 
> detached.
> 
> 
>> 2016/11/02 14:05、arisawa <aris...@ar.aichi-u.ac.jp> のメール：
>> 
>> thanks, i will try.
>> 
>> is this for pi1 or pi2 or both?
>> 
>>> 2016/11/02 10:35、Chris McGee <newton...@gmail.com> のメール：
>>> 
>>> Hi All,
>>> 
>>> I have released an experimental 9front raspberry pi image that I use for my 
>>> cluster.
>>> https://github.com/sirnewton01/rpi-9front/releases/tag/nov-2016
>>> 
>>> Highlights:
>>> -Latest 9front release 2016-10-27
>>> -Merged in Richard Millar’s kernel from a couple of months ago
>>> -Retains 9front GPIO filesystem structure
>>> -Link local ipv4 address on boot (low likelihood of collisions)
>>> -Discovery of other nodes using multicast DNS through the ‘find9p’ command
>>> -9fs mount other nodes on the network
>>> -Go 1.7.3
>>> -Git script (works with github and google source repos)
>>> 
>>> Cheers,
>>> Chris
>> 
>> 
> 
> 

[9fans] 9front on raspberry pi

[Chris McGee]

Hi All,

I have released an experimental 9front raspberry pi image that I use for my 
cluster.
https://github.com/sirnewton01/rpi-9front/releases/tag/nov-2016 


Highlights:
-Latest 9front release 2016-10-27
-Merged in Richard Millar’s kernel from a couple of months ago
-Retains 9front GPIO filesystem structure
-Link local ipv4 address on boot (low likelihood of collisions)
-Discovery of other nodes using multicast DNS through the ‘find9p’ command
-9fs mount other nodes on the network
-Go 1.7.3
-Git script (works with github and google source repos)

Cheers,
Chris

Re: [9fans] Making available a pre-compiled go binary for Miller's plan-9 Pi image (Chris McGee)

[Chris McGee]

Thanks David, Stanley,

I managed to get the cross compile to work using the 9legacy go binaries and 
the git script.

The workaround for the error I received before is to create a dummy rc script 
called 'install' and put it into my /bin. The go make.rc script calls it and 
continues on seemingly fine afterwards.

Chris

> On Oct 30, 2016, at 9:47 PM, Stanley Lieber <s...@9front.org> wrote:
> 
> Chris McGee <newton...@gmail.com> wrote:
> 
>> I tried this command with both go 1.7.3 and master branches. Both fail
>> right after “ Building packages and commands for host, plan9/386”
>> with an error “install: ./install not found.”
>> 
>> It seems like the go bootstrap tool is trying to call a binary called
>> “install” but there are none on my system. Is there such a command on
>> p9bl? Maybe 9front doesn’t have it?
>> 
>> It works fine if I don’t try to cross compile to plan9/arm or even
>> linux/386.
>> 
>> Chris
>> 
>>> On Oct 30, 2016, at 4:39 AM, David du Colombier <0in...@gmail.com>
>> wrote:
>>> 
>>>> To cross compile with make.rc do you just set GOARCH and GOOS and
>> just run it?
>>> 
>>> Yes and you can add the --no-rebuild flag to prevent cmd/dist to
>> remove the existing binaries.
>>> 
>>> For example:
>>> 
>>> ℅ GOOS=plan9 GOARCH=arm make.rc --no-rebuild
>>> 
>>> -- 
>>> David du Colombier
>>> 
> 
> 'install' is from BSD. It does not exist in Plan 9.
> 
> sl
> 
> 

Re: [9fans] Plan9 usage but used to parallel MPI on linux..

[Chris McGee]

I would be interested in manuals or papers on this subject as well.

Plan9 is well suited to distributed computing with its per process namespaces 
and network transparent resource access. Do grid computing projects built on 
plan9 use the built-in OS facilities such as cpu and 9p or do they generally 
favour custom protocols and for what reasons?

Cheers,
Chris

> On Oct 30, 2016, at 8:33 PM, Darren Wise  wrote:
> 
> Heya folks,
> 
> Can anyone point me in the right direction of some manuals concerning the use 
> of a beowulf cluster style of computing setup, i'm so used to MPI installs 
> and limiting myself to terminals that being what it seems ooout-f-he-box this 
> already is setup with parallel computing in mind..
> 
> Also some examples would be great of common current usages of such.
> 
> 
> 
> > Kind regards,
> > Darren Wise Esq, 
> > B.Sc , HND, GNVQ, City & Guilds.
> > 
> > Managing Director (MD)
> > Art Director (AD)
> > Chief Architect/Analyst (CA/A)
> > Chief Technical Officer (CTO)
> > 
> > www.wisecorp.co.uk 
> > www.wisecorp.co.uk/babywise 
> > www.darrenwise.co.uk 

Re: [9fans] Making available a pre-compiled go binary for Miller's plan-9 Pi image (Chris McGee)

[Chris McGee]

I tried this command with both go 1.7.3 and master branches. Both fail right 
after “ Building packages and commands for host, plan9/386” with an error 
“install: ./install not found.”

It seems like the go bootstrap tool is trying to call a binary called “install” 
but there are none on my system. Is there such a command on p9bl? Maybe 9front 
doesn’t have it?

It works fine if I don’t try to cross compile to plan9/arm or even linux/386.

Chris

> On Oct 30, 2016, at 4:39 AM, David du Colombier <0in...@gmail.com> wrote:
> 
> > To cross compile with make.rc do you just set GOARCH and GOOS and just run 
> > it?
> 
> Yes and you can add the --no-rebuild flag to prevent cmd/dist to remove the 
> existing binaries.
> 
> For example:
> 
> ℅ GOOS=plan9 GOARCH=arm make.rc --no-rebuild
> 
> -- 
> David du Colombier
> 

Re: [9fans] Making available a pre-compiled go binary for Miller's plan-9 Pi image (Chris McGee)

[Chris McGee]

To cross compile with make.rc do you just set GOARCH and GOOS and just run it?


> On Oct 29, 2016, at 2:46 PM, David du Colombier <0in...@gmail.com> wrote:
> 
> > Maybe cross compile isn't working with Go on plan9 yet?
> 
> I don't know about bootstrap.sh, but cross-compiling works fine on Plan 9 
> using make.rc.
> 
> -- 
> David du Colombier

Re: [9fans] Making available a pre-compiled go binary for Miller's plan-9 Pi image (Chris McGee)

[Chris McGee]

Thanks David,

These binaries are great as a starting point to compile newer versions of Go.

I almost fully automated the preparation of my 9front rpi sd card images. Cross 
compiling from plan9 386 to plan9 arm using the bootstrap fails with this error:

Install: './install' not found

Maybe cross compile isn't working with Go on plan9 yet?

Thanks,
Chris

> On Oct 28, 2016, at 4:14 PM, David du Colombier <0in...@gmail.com> wrote:
> 
> As you wish:
> 
> http://www.9legacy.org/download/go/go1.7.3-plan9-386-bootstrap.tbz
> http://www.9legacy.org/download/go/go1.7.3-plan9-amd64-bootstrap.tbz
> http://www.9legacy.org/download/go/go1.7.3-plan9-arm6-bootstrap.tbz
> http://www.9legacy.org/download/go/go1.7.3-plan9-arm7-bootstrap.tbz
> 
> -- 
> David du Colombier
> 

Re: [9fans] Making available a pre-compiled go binary for Miller's plan-9 Pi image

[Chris McGee]

Thanks David,

I will give this a try.

Chris

On Oct 28, 2016, at 2:58 AM, David du Colombier <0in...@gmail.com> wrote:

>> you have to have an n-1 version of Go to compile n
> 
> You have to bootstrap from Go >= 1.4.
> 
> If you want to build the current Go source from scratch on plan9/386,
> you can just do:
> 
> cd /tmp
> git clone -b go1.4.3 https://go.googlesource.com/go go1.4
> cd go1.4
> hget http://9legacy.org/go/patch/syscall-exec.diff | ape/patch -p1
> cd src
> make.rc
> 
> GOROOT_BOOTSTRAP=/tmp/go1.4
> cd /tmp
> git clone https://go.googlesource.com/go
> cd go/src
> make.rc
> 
> This is documented on https://github.com/golang/go/wiki/Plan9
> 
> -- 
> David du Colombier
> 

Re: [9fans] Making available a pre-compiled go binary for Miller's plan-9 Pi image

[Chris McGee]

I was thinking about this myself. I'm more in favour of a script that downloads 
the go source and compiles it since it seems to be more in the spirit of plan9.

The trouble is that Go has made it harder to do now that you have to have an 
n-1 version of Go to compile n. This started with 1.5 but 1.5 doesn't seem to 
compile or run well on plan9.

Maybe a compromise would be to have tbz binaries for 1.7 and a script that 
takes them and uses it to compile a fresh copy from sources and cleans up the 
bootstrap. Otherwise, you need to cross compile from another OS. Yuck.

Chris

> On Oct 27, 2016, at 12:26 PM, Marshall Conover  wrote:
> 
> Hi All!
> 
>I compiled a Go binary for use on Richard Miller's raspberry pi image in 
> contrib (thanks for that Richard, by the way). I threw up a link to the 
> binary in a previous email a week or two ago, but I think that email got spam 
> filtered, so I won't link it again - but, is there a good place to make this 
> available for ease-of-use? Woudl've been nice to just hget a tgz and extract 
> it when I was getting things up and running the other day, instead of getting 
> go set up on my linux box, compiling it, setting the final_goroot, etc. 
> Richard, if you're comfortable with it, I could pass it to you to throw up on 
> your contrib.
> 
> Thanks!
> 
> Marshall

Re: [9fans] libtask

[Chris McGee]

Yeah, I saw that and it made me chuckle, especially once I discovered the 
recursive reflection.

It's reasonably easy to program in it. I know that it can handle 16 bit 44.1 
kHz stereo pcm streaming over a network. Does that it "performing?"

Chris

> 
> Reading the description of the go-p9p, it says "A modern, performant 9P 
> library for Go.".  I'm guessing "modern" refers to being implemented in Go.  
> Any pointers on how performance was measured or what it was measured against?
> 
> 
> 
>> On Tue, Oct 18, 2016 at 11:32 AM Chris McGee <newton...@gmail.com> wrote:
>> If you're interested in Go, this 9p library has worked reasonably well for 
>> my servers.
>> 
>> https://github.com/docker/go-p9p
>> 
>> 
>>> On Oct 18, 2016, at 1:31 PM, Iruatã Souza <iru.mu...@gmail.com> wrote:
>>> 
>>> https://github.com/iru-/lua9p
>> 
>>> 
>>> 
>>>> On Thu, Oct 13, 2016 at 3:47 PM, yy <yiyu@gmail.com> wrote:
>>>>> On 13 October 2016 at 18:03, Steve Simon <st...@quintile.net> wrote:
>>>>> Anyone written or ported a small simple 9p library;
>>>> 
>>>> As part of a GSoC project I wrote
>>>> https://bitbucket.org/yiyus/devwsys-prev/src/tip/libninep/ (man pages
>>>> can be found in the same repo). There is a ninepserver but not a
>>>> ninepclient because the only client I wrote was to be used with p9p,
>>>> so I was using 9pclient(3), but it should be relatively easy to write
>>>> one if you need it.
>>>> 
>>>> 
>>>> --
>>>> - yiyus || JGL .
>>>> 
>>> 

Re: [9fans] libtask

[Chris McGee]

If you're interested in Go, this 9p library has worked reasonably well for my 
servers.

https://github.com/docker/go-p9p


> On Oct 18, 2016, at 1:31 PM, Iruatã Souza  wrote:
> 
> https://github.com/iru-/lua9p
> 
>> On Thu, Oct 13, 2016 at 3:47 PM, yy  wrote:
>>> On 13 October 2016 at 18:03, Steve Simon  wrote:
>>> Anyone written or ported a small simple 9p library;
>> 
>> As part of a GSoC project I wrote
>> https://bitbucket.org/yiyus/devwsys-prev/src/tip/libninep/ (man pages
>> can be found in the same repo). There is a ninepserver but not a
>> ninepclient because the only client I wrote was to be used with p9p,
>> so I was using 9pclient(3), but it should be relatively easy to write
>> one if you need it.
>> 
>> 
>> --
>> - yiyus || JGL .
>> 
> 

Re: [9fans] 3D graphics as a filesystem

[Chris McGee]

Cool. Do you have any code that you can share for that? What does the file 
protocol look like?

> On Oct 12, 2016, at 7:17 PM, Jules Merit <jules.merit.eurocorp...@gmail.com> 
> wrote:
> 
> Yeah I prototyped draw3d with 9vx driver to host GPU on Linux system. MesajGL 
> if 9p file exists it supports mode of that name to transfer to gpu. It helps 
> if you have DooM handy to try writing it in rc.
> 
> 
>> On Oct 12, 2016 4:06 PM, "Chris McGee" <newton...@gmail.com> wrote:
>> Hello All,
>> 
>> I am looking at the specs for a GPU and was thinking about something 
>> analogous to /dev/draw, but for 3D graphics. Kind of like OpenGL except 
>> exposed as a filesystem so that it is network mountable and programmed in 
>> any language (even rc).
>> 
>> Does anyone know if this kind of thing has been done before for plan 9? Any 
>> relevant papers or documents out there?
>> 
>> My first thought involves representing elements in the graphics pipeline as 
>> files where you can write shader language code. Also a vertex file to write 
>> or read floating point vertex data. Maybe something more abstract would be 
>> better with scene graph and camera controls would be better match for a 
>> filesystem implementation.
>> 
>> Thanks,
>> Chris

[9fans] 3D graphics as a filesystem

[Chris McGee]

Hello All,

I am looking at the specs for a GPU and was thinking about something analogous 
to /dev/draw, but for 3D graphics. Kind of like OpenGL except exposed as a 
filesystem so that it is network mountable and programmed in any language (even 
rc).

Does anyone know if this kind of thing has been done before for plan 9? Any 
relevant papers or documents out there?

My first thought involves representing elements in the graphics pipeline as 
files where you can write shader language code. Also a vertex file to write or 
read floating point vertex data. Maybe something more abstract would be better 
with scene graph and camera controls would be better match for a filesystem 
implementation.

Thanks,
Chris

Re: [9fans] "The Name Game"

[Chris McGee]

Very nice introduction.

> On Oct 7, 2016, at 7:05 PM, Skip Tavakkolian  
> wrote:
> 
> A wonderful and entertaining talk by Charles about key ideas in Plan 9 and 
> Inferno.
> 
> https://youtu.be/3d1SHOCCDn0
> 
> Thanks also to Ron for posting it.
> 

Re: [9fans] Cpu command and namespace

[Chris McGee]

Thanks Skip,

That's the part I was missing. I thought that the current namespace is 
preserved after cpu command on the remote. But then I realize that it would be 
difficult to remap the bin namespaces to a different cpu architecture.

I suppose that I can always bind over what I want from /mnt/term or customize 
the profile script to do it automatically in cpu case.

Chris

On Oct 6, 2016, at 12:14 AM, Skip Tavakkolian <9...@9netics.com> wrote:

>> I was under the impression that the namespace should come from the client.
> 
> perhaps it's a confusion over cwd when you cpu to another machine?
> 
> supermic% pwd
> /usr/fst
> supermic% cpu -h rpi
> rpi% pwd
> /usr/fst
> rpi% 
> 
> since typically everything is served by fs, it is all the same
> content.  the local namespace is exported by the local cpu and the
> far-end cpu mounts it on /mnt/term.
> 
> e.g.
> 
> rpi% devsysname='/dev/sysname' for (i in `{seq 3}) {
>echo $devsysname ' = ' `{cat $devsysname}
>devsysname='/mnt/term'^$devsysname
>}
> /dev/sysname  =  rpi
> /mnt/term/dev/sysname  =  supermic
> /mnt/term/mnt/term/dev/sysname  =  dell
> rpi% 
> 
> 

[9fans] Cpu command and namespace

[Chris McGee]

Hi All,

I tried running a cpu server using aux/listen1 on one of my plan9 machines and 
running cpu from another to connect to it. I set auth to none for now.

When I connected I noticed that the namespace was the local namespace of the 
server, not the namespace of the client before connecting. I was under the 
impression that the namespace should come from the client.

Am I doing something wrong here or is my understanding incorrect? Maybe I need 
to get authentication set up properly?

Thanks,
Chris

Re: [9fans] 9P - Meaning of iounit

[Chris McGee]

Thanks Richard, James,

Chris

> On Oct 3, 2016, at 11:05 AM, Richard Miller <9f...@hamnavoe.com> wrote:
> 
> term% lookman iounit
> man 2 fcall # fcall(2)
> man 2 iounit # iounit(2)
> man 3 proc # proc(3)
> man 5 0intro # 0intro(5)
> man 5 open # open(5)
> man 5 read # read(5)
> 
> 

[9fans] 9P - Meaning of iounit

[Chris McGee]

Hello All,

I am learning the 9p protocol and implementing a 9P server. After reading the 
9p manual page, the types of messages and much of the overview is clear. There 
are a number of items that are less clear.

For example, it took some time to figure out how to provide a directory 
structure on a Tread.

Lately, I’m looking at the “iounit.” Initially, I had thought of it as a way to 
give the size of a file on Topen. After some testing I realized that the 
network subsystem in plan9 is expecting the iounit to be large enough to write 
commands into a /net/tcp ctl file. With a small iounit, the network subsystem 
truncates the commands, such as “connect xyz|1234” to match the size of the 
iounit.

So, what is this mysterious iounit? Is there another man page or plan9 document 
that describes it in more detail?

Thanks,
Chris

Re: [9fans] Terminal possibliities...

[Chris McGee]

I believe that it is documented somewhere on Russ Cox’s website or on plan9port.

Basically, you can hold down the ctrl or alt keys while clicking/dragging to 
simulate the same action with the middle or right mouse button. I think that 
chording is possible too by holding down both ctrl and alt at the same time. 
Although, I’m not sure how you would do chording with the left and middle or 
left and right. Maybe you can use shift in those cases.

I’m wondering if this kind of thing has been discussed before. Perhaps there 
are good reasons to keep the functionality out of p9bl or 9front?

Chris

> On Oct 2, 2016, at 10:28 PM, s...@9front.org wrote:
> 
> Could you explain exactly what the modifiers are and how they work?
> 
> sl
> 

Re: [9fans] Terminal possibliities...

[Chris McGee]

Is there any interest in putting these p9port style keyboard modifiers into 
p9bl or 9front?

It might be a good backup for when I don’t have a true three button mouse 
kicking around.

Chris

> 
> Since I'm on a macbook with a one-button touchpad I end up using
> the keyboard modifiers plus the patch submitted by djeannot24 to
> plan9port (see https://codereview.appspot.com/6115053 
> ) to help get
> around the lack of buttons.
> 
> Jim
> 

[9fans] 9p - meaning of iounit

[Chris McGee]

Hello All,

I am learning the 9p protocol and implementing a 9P server. After reading the 
9p manual page, the types of messages and much of the overview is clear. There 
are a number of items that are less clear.

For example, it took some time to figure out how to provide a directory 
structure on a Tread.

Lately, I’m looking at the “iounit.” Initially, I had thought of it as a way to 
give the size of a file on Topen. After some testing I realized that the 
network subsystem in plan9 is expecting the iounit to be large enough to write 
commands into a /net/tcp ctl file. With a small iounit, the network subsystem 
truncates the commands, such as “connect xyz|1234” to match the size of the 
iounit.

So, what is this mysterious iounit? Is there another man page or plan9 document 
that describes it in more detail?

Thanks,
Chris

Re: [9fans] Terminal possibliities...

[Chris McGee]

Sure, they would work but it's one more thing to have to charge. My drill 
batteries are always charged and I already own them.

> On Oct 1, 2016, at 9:40 AM, James A. Robinson <jim.robin...@gmail.com> wrote:
> 
> Honestly I had been assuming one of those usb battery packs would work. :)
> 
> On Sat, Oct 1, 2016 at 4:59 AM Chris McGee <sirnewton...@yahoo.ca> wrote:
> I found some $4 voltage regulators that will convert 18v Lithium ion drill 
> batteries to power my Pi. Could be useful for field work.

Re: [9fans] Terminal possibliities...

[Chris McGee]

> I forgot the thinkpad also has an inbuilt battery. Good for mobility
> and against flaky power in development countries.

I found some $4 voltage regulators that will convert 18v Lithium ion drill 
batteries to power my Pi. Could be useful for field work.

Re: [9fans] Terminal possibliities...

[Chris McGee]

It would be interesting to hear how this works out in practice. The bandwidth 
requirement is probably so low compared to typical traffic from a hotel, 
compared even to smart phones.

> On Sep 30, 2016, at 3:49 PM, James A. Robinson  wrote:
> 
> Is anyone here using Plan 9 as a terminal to connect to remote CPU / File 
> servers over the internet to get work done?
> 
> If I set up a small Plan 9 cluster at home, I'm thinking it'd be pretty neat 
> to be able to connect to the network at home over the internet.
> 
> While I have a laptop and could put 9front on it, I also really like the 
> thought of carrying around a little Raspberry Pi and portable keyboard/mouse 
> as an alternative.  Sitting here in a cheap motel room, I realized that all 
> the hotel rooms I've been in over the past few years have a decent flat 
> screen television that takes an HDMI input and has had decent, if not 
> amazing, WiFi to the internet.
> 
> Jim
> 

Re: [9fans] Questions on the browser as a platform if plan 9 had gained marketshare

[Chris McGee]

Wow,

That sounds cool.

Thanks,
Chris

> On Sep 22, 2016, at 6:49 PM, michaelian ennis  
> wrote:
> 
> Not exactly what you meant but Coraid did implement a something like this 
> that had 9p on it.  Sort of.  It was an ARM based PCIe card spoke 9p over 
> something like IL without the IP (bwc called it EL) using network ports on 
> the card.  
> 
> Sometimes they appear on ebay as "coraid mass storage NIC" or some such.  Not 
> the repurposed SuperMicro Cards but something that looks mor complicated with 
> a SO-DIMM socket on it. 
> 
> The ARM CPU was also used for other services running on/for the platform that 
> were performed by the card.  The card could be powered by POE so the chassis 
> could be powered down and the card could still be accessed. The firmware on 
> the card was, IIRC, not quite plan9 but constructed mostly from plan9.
> 
> Ian

Re: [9fans] IP Multicast - Results

[Chris McGee]

Hi All,

Multicast is working fine for me with the latest patches in 9front hg on my 
raspberry Pi.

Thanks Cinap, Alex et al for pointing me in the right direction.

Current status is that I can use multicast dns to discover nodes on my local 
network using a Go library and some patches to the Go networking code to add 
multicast support. I'm going to try and see if I can get that contributed to 
the next version.

Btw, I noticed that the net manpage doesn't accurately describe the format of 
/net/ipifc/x/status files. It says there are 9 columns but mine has more than 
that and also some extra rows for assigned IP addresses. Does anyone know if 
this is a 9front specific deviation or if the man page is just way out of date?

Chris

> On Sep 17, 2016, at 7:53 AM, Chris McGee <sirnewton...@yahoo.ca> wrote:
> 
> I recompiled with the latest in hg. I'm still not having success with the 
> multicast. I'm going to start adding debugging to figure out what's going on.
> 
> Chris
> 

Re: [9fans] Questions on the browser as a platform if plan 9 had gained marketshare

[Chris McGee]

> Would this be fast enough for what we experienced back then with early 
> websites, however? What with the stats on how people close or click away from 
> a tab within N seconds if it hasn't fully loaded yet, I'd think that having 
> to compile at all could've been prohibitive to people taking this route vs. 
> web forms. Though, I'm not sure how user behaviors or expectations of speed 
> were back then for the web.

I have a couple of ideas in this area. If a more guided interface is needed 
then when you mount a service you can hook up a console to a file using "con" 
command allowing for interactive prompts such as "enter search criteria" and 
responses. Still no remote code required.

Another option is to provide a readme.txt file describing the service, relevant 
files, etc. Inside that document are examples of shell commands that you can 
run.

echo 'search cat pictures' >> ctl

Open the readme in acme, edit the examples, select and middle click on it and 
it runs the command. You learn how to use the service and again, there is no 
remote command execution other than what you selected and ran.

> 
> I was thinking what may have eventually happened would have been an 
> interpreted language would pop up that would be what web applications were 
> written in, sort of like java applets, except not embedded in the browser, 
> and hopefully in a simpler language. Early web applications were also very 
> simple 'put info in textbox and hit enter' forms, if I remember correctly, so 
> a small, expandable runtime that would be quickly started up in a sandbox 
> might have been on equal footing with html, assuming it was indeed able to 
> start up and run quickly (or maybe just fork a running one into a new 
> namespace?). Ideally, developers could then write their own libraries (in C 
> or whatever they like) that the web language would hook into that could do 
> more powerful things - and those libraries might be the time to provide 
> source and makefiles, or binaries if they wanted to keep things close to the 
> chest.

That's possible that an interpreted language would have taken off. With OS 
level sandboxing, hopefully people run these within the sandboxes, providing 
access the minimal set needed for the service.

> 
> Thinking more on the 'writing to a ctl file' idea, which I'm really getting 
> into, I was thinking users may have ended up making their own graphical 
> interfaces for web services; UIs that abstracted away the actual writing to 
> ctl files and put it in a GUI for less advanced users. It'd've been 
> interesting to see a competition in UI design among OSS interfaces for web 
> services, sort of like what we see today with apps for reddit on phones 
> (except hopefully they wouldn't all be awful). Or, maybe everyone would just 
> use the service-provider's provided interfaces.

I think that many GUI's were created to hide ugly, inconsistent and large 
layers underneath. I have a hypothesis that if you start with a small, well 
designed system with a simple interface that people can and will use it of the 
alternative is a system that is brittle, complex and allows accidental security 
breaches at the click of a button. Textual interfaces can good and usable, with 
a bit of learning. Add graphics only when the problem warrants it (eg. CAD) or 
it truly simplifies the interface.

> Do you think there would've been fewer large databases if things had gone 
> this way? Just thinking on my banking example, it seems like it'd be easiest 
> to just have a /bank.com/users/ folder with the relevant files in 
> it that users could union-mount, since you're not forced to show things 
> through a web interface. Though, I suppose a bank could just expose that 
> folder as an interface for what's actually a DB running in the background.

The bank may expose files, but it doesn't necessarily mean you can edit them 
like simple text files. Plan 9 has some really interesting paradigms with read 
only files, updating using control file protocols, append only files, file 
descriptors that return errors for invalid writes. I've only scratched the 
surface. It could be a really interesting project to write up how different 
paradigms work for certain scenarios.

Chris

Re: [9fans] Questions on the browser as a platform if plan 9 had gained marketshare

[Chris McGee]

I was thinking more along the lines of hardware implementation of 9P minus any 
OS. For example, a disk serves up a filesystem via 9P or an Ethernet device 
serving a /net with 9P.

Chris

> On Sep 20, 2016, at 2:16 AM, David Pick <d.m.p...@qmul.ac.uk> wrote:
> 
>> On 19/09/16 21:55, Chris McGee wrote:
>> 
>> 
>> 
>> Maybe 9P could be implemented in a SoC.
> 
> It already has: the Raspberry Pi is built round a SoC...
> ...all that's needed is to boot from SoC ROM instead of the SD card.
> 
> -- 
> David Pick
> Network Security Manager, IT Services
> Queen Mary University of London
> Tel: +44 (0) 20 7882 7079
> Mob: +44 (0) 7973 379 161
> E-Mail: d.m.p...@qmul.ac.uk
> 
> Normal working days are Monday to Wednesday inclusive
> 
> Worried about Cyber Security? Check out the
> Cyber Security Information and Training described at
> http://connect.qmul.ac.uk/qmandyou/staff/items/2016/item177974.html
> 
> 

Re: [9fans] Questions on the browser as a platform if plan 9 had gained marketshare

[Chris McGee]

If plan 9 had taken off I wonder if there would be peripherals with built-in 9P 
support.

For example, a network adapter that you can mount into /net/etherxyz over USB, 
PCI using a 9P connection. No driver needed, except to communicate with the bus.

Also, external storage (hdd, ssd) with a built in filesystem exposed as 9P. 
UTF-8 file names, of course.

Maybe 9P could be implemented in a SoC.

Chris

Re: [9fans] Questions on the browser as a platform if plan 9 had gained marketshare

[Chris McGee]

> 
> > You just mount search engine, route planning tool, or even shopping site 
> > and echo commands into the ctl file. 
> 
> I hadn't thought of this - was more thinking on the user union mounting, say, 
> google.com/bin into their bin directory and running a google operation. The 
> concept of just echoing into a ctl file is really interesting from a security 
> perspective.

Right, in this case there is no remote code execution. Web users run all kinds 
of code they are unaware of today. It's a major problem.

It also helps to create a certain uniformity and expectation of how services 
should work.

Mounting a bin directory from some remote servers is a potential vector for 
malicious code and requires all services to provide binaries for all platforms 
(arm, x86, riscv,...). Instead, serving the source code and mkfile allows for 
audit ability (what did I just run?) and support for their own platform. Plan 9 
compilers were designed not just to produce optimal code but also for speed of 
compilation.

Re: [9fans] Questions on the browser as a platform if plan 9 had gained marketshare

[Chris McGee]

Hi,

I have been pondering the same kind of thing myself lately. In an alternate 
bizarro universe, what would the web look like that is modelled more around 
plan 9 concepts. Heres my fantastic take on this.

First, there is a focus on simplicity of implementation and interface over 
flashiness of UI. As a result, services are much easier to use directly rather 
than having to rely on html/js UIs. You just mount search engine, route 
planning tool, or even shopping site and echo commands into the ctl file. And 
you get back results as numbered files with simple text output. User 
doesnt accidentally run malicious software embedded in the service. 
Its all just 9P.

If a service is complex enough, due to complexity of the problem it is trying 
to solve (not invented complexity). Source code is posted on the service in C 
source code form. User runs mk, which is super fast because the compilers are 
optimized for this. They run the program in a rfork+rio sandbox. Users quickly 
learn how simple this is and do it regularly so that in trusted programs 
dont have access to what they shouldnt. The process isnt 
automatic so it doesnt happen without user knowledge. Pop ups and such are 
not possible.

User wraps the connection in tls if they dont want any snooping. Sensitive 
services such as banking dont allow unencrypted sessions.

URLs are just relative paths, navigable using acme and plumber. Absolute 
links to sites dont exist since the user can map their namespaces any way 
they choose. Instead, documents may give 9P connection information and 
locations. Cross site linking becomes very clear. To facilitate ease of 
navigation and discovery services pop up to curate documents with nice easy 
relative linking within that service.

Multimedia documents with both pictures and text are compiled into self 
contained files kind of like PDF without hyperlinks and arbitrary code 
expectation. Links between documents are relative paths as above. Users are 
accustomed to using simple text or even markup/markdown for most things. This 
rich format is for longer and more focused reading sessions: studying a topic, 
leisure reading.

Implementers of Internet services have a strong focus on simplicity of 
implementation and interface, but also in adopting common conventions. For 
example, a ctl file where you send commands and numbered directories with 
results of each invocation. Perhaps a new convention could be to include a 
readme file and maybe man page with details about how to use the service. Also, 
services are designed to be focused enough and standard enough that they can be 
easily interact with other services using pipes, redirects, etc. so that the 
user can combine them to suit their needs.

Services take advantage of the simplicity of plan 9 and 9P to easily sandbox, 
proxy and load balance their services. Also, commodity and mixed architecture 
systems are easily integrated for free or new services that are built with 
whatever hardware they can find.

Single signon is achieved using symmetric encryption. If the service recognizes 
your public key and you are able to sign a message using your private key you 
can proceed. Not sure how much overlap there is here with what is in tls and 
factotum. Something like factotum could be useful to allow you to specify 
different keys (identities) for different services. The point here is that 
authentication is in the users control and not the service. The user ever 
only needs to remember one password or store their thumbprint in one place.

Thats all I have so far.

Chris

Re: [9fans] IP Multicast - Results

[Chris McGee]

I recompiled with the latest in hg. I'm still not having success with the 
multicast. I'm going to start adding debugging to figure out what's going on.

Chris

Re: [9fans] IP Multicast - Results

[Chris McGee]

Ooh thanks. In hg?

Chris

> On Sep 16, 2016, at 5:26 PM, cinap_len...@felloff.net wrote:
> 
> updated the code for multicast and promisc mode in nusb/ether...
> 
> --
> cinap
> 

Re: [9fans] IP Multicast - Results

[Chris McGee]

Thanks Alex, Cinap,

Right, the Pi uses USB for its built in nic.

I wanted to make sure that I have narrowed down where the missing functionality 
is. It sounds like I need to have a look at how multicast filtering works with 
supported PCI nic cards and apply that to nusb/ether.

Chris

Re: [9fans] IP Multicast - Results

[Chris McGee]

Yes, same here. Both are wired directly to a dumb switch using link local 
addresses. No router.

I tried 225.0.0.1 port 1234 on both ends.

I cant figure out what the contents of the buffer is. Just random bytes? 

It is weird that the ifc number gets filled in after pinging the multicast 
address.

Chris

Re: [9fans] IP Multicast - Results

[Chris McGee]

Hi Alex,

I tried the mcastsend and mcastrecv on my two raspberry Pis running 9front.

Im seeing similar routes as in my own experiment without the interface 
number, tagged as 4m for IPv4 multicast. I can ping each device from the other 
using their unicast addresses.

Unfortunately, it doesnt seem to be working. Both ends are sitting idle.

Do you remember if you needed to add/remove routes to make it work? Also, did 
you use 9front or the bell labs distribution?

Thanks,
Chris

Re: [9fans] IP Multicast - Results

[Chris McGee]

Thank you Alex,

I will give these a try tonight. I'm happy to hear that multicast can work and 
it's likely just some silly mistake on my end.

Chris

> On Sep 15, 2016, at 12:23 AM, Alex Musolino  wrote:
> 
> I was playing around with multicast on 9front the other week and
> managed to get something working (for some definition of working). I
> have attached 2 test programs for sending and receiving multicast
> datagrams. Unfortunately, it seems you can't send/receive messages
> from the same host. I'm not sure what's missing to get that part
> working.
> 
> Also, note that the dial in mcastrecv.c is just a hack to get the
> local address via getnetconninfo, which doesn't seem to work given the
> announce directory.
> 
> Hopefully these are of some use. Would be interested to hear how to
> fix the mentioned (and unmentioned) shortcomings.
> 
> --
> Cheers,
> Alex Musolino
> 
> 
>