Re: [9fans] Re: Inferno OS

[Marshall Conover]

Hi Dharani,

I can suggest two places:

There is the inferno-os google group here:
https://groups.google.com/g/inferno-os

And if you're open to using discord, there's an #inferno channel that gets
occasional traffic on the 9fans discord hosted by Henesy:
https://discord.gg/RXu6xPnY . That invite will work for 7 days, and can be
used by an arbitrary number of people.

I'm sure others will have ideas as well.

Cheers,

Marshall



On Sun, Feb 26, 2023 at 9:30 PM Tharaneedharan Vilwanathan <
vdhar...@gmail.com> wrote:

> Hi David,
>
> I tried to build based on the script and it worked. I was happy to see
> Inferno up and running. Thanks a lot.
>
> Do you know if there is any forum that discusses on Inferno/Limbo? Long
> back I remember discussing in a forum called "inferno-list".
>
> Thanks
> dharani
>
>
> On Sun, Feb 26, 2023 at 12:42 PM  wrote:
>
>> I made a GitHub Action to build Inferno on Ubuntu 22.04:
>>
>> https://github.com/dboddie/inferno-test-builds/blob/hosted-386/.github/workflows/ubuntu-22-04.yml
>> I didn't manage to produce something simple, small and self-contained
>> that could be downloaded, though you could use the steps to build your own
>> installation, or use GitHub to build it for you.
>>
> *9fans * / 9fans / see discussions
>  + participants
>  + delivery options
>  Permalink
> 
>

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tecab5f4d7c7dcc7c-M607bfc399d1923578b7693ee
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] iwp9: call for papers

[Marshall Conover]

I can pick this up. I'll ping you off-list, Ori.

Thanks for the clarification, khm!

Cheers,

Marshall

On Sat, Feb 4, 2023 at 10:45 AM  wrote:

> Quoth Marshall Conover :
> >
> > Will this iwp9 be filmed?
> 
> I'd love it if someone volunteered to film, but
> I'm not currently aware of anyone with equipment
> and a desire to do the editing and upload.
> 
> Anyone feel like stepping up to do this?
> 

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tcb1e8931f4fed60b-Mcd1105b3925d429f92331ff8
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] iwp9: call for papers

[Marshall Conover]

Hi Ori,

A question on iwp9 popped up in the Discord that I can't find an answer to
(though I may be missing it), and I figured it'd be good for the mailing
list as well:

Will this iwp9 be filmed?

I see in the "important dates" the "Camera-ready version" for March 13th,
but I'm not sure what that refers to.

Looking forward to it,

Marshall

On Tue, Jan 31, 2023 at 11:30 PM  wrote:

> Quoth o...@eigenstate.org:
>
> > Call for Papers
> > ---
> >
> >   Jan 30:  Paper submission deadline
> >   Jan 30:  Proposals for hackathons and tutorials deadline
> >   Feb 13:  Paper acceptance notification
> >   Feb 27:  Works in progress submission deadline
> >   Mar 6:   WIP acceptance notification
> >   Mar 10:  Registration deadline
> >   Mar 13:  Camera ready version
> >   April 21-23: Workshop
> 
> We've gotten a bunch of submissions, but there are several people
> who have asked for more time to finish up their papers. As a result,
> we're extending the submission deadline as follows:
> 
> Feb 12, 2023: Paper submission deadline
> Feb 12, 2023: Proposals for hackathons and tutorials deadline
> Feb 24, 2023: Paper acceptance notification
> Feb 27, 2023: Works in progress submission deadline
> Mar 6, 2023: WIP acceptance notification
> Mar 10, 2023: Registration deadline
> Mar 13, 2023: Camera ready version
> April 21-23, 2023: Workshop
> 

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tcb1e8931f4fed60b-M5772f49f5fac853ef082663c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Re: Plan 9 applying to GSoC

[Marshall Conover]

Adding a +1 for sirjofri's idea 3, which seems like it would be achievable,
has clear objectives, and a compelling result.

For idea 4, a notable utility is pipefile -
https://9p.io/magic/man2html/1/pipefile. It allows you to stitch a command
in-between the reading and/or writing of a file. It'd be worth eyeballing
and considering for the purposes you're thinking of, and may provide a
jumping-off point.

Cheers,

Marshall

On Sat, Feb 19, 2022 at 11:33 AM  wrote:

> sirjofri  writes:
>
> > (3) A high-level filesystem interface for UI widgets. Many modern UI
> > layouts can be described as a hierarchy of containers. The UI
> > filesystem would start as an empty window, which is reflected by an
> > empty filesystem. The user could create widget containers (hbox, vbox)
> > by creating directories and files, as well as input boxes, buttons and
> > more by creating files. The hierarchy would directly reflect the drawn
> > window. The user can listen to files for button interaction and write
> > text to labels etc..
> 
> Ballastero(sp?) and lsub's Octopus (Omero?  O-something) does something
> like this.  With it, you can tar/untar a Tk UI from one system to
> another.  IIRC, it was implemented with Inferno.  Since I is similiar to
> 9, it probably wouldn't be too hard to port.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Td4449edc4863e16e-M709844316c73d6efec7d190b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Sponsoring a new Intro book by the Flan 9 Poundation

[Marshall Conover]

Hi mycroftiv!

I'd be happy to lend some support and at least match your bounty. There's a
lot to explore in the 9 universe beyond what has been covered so far, and I
think the work you've done with ants and grid has been fantastic - and
shows your dedication to growing the ecosystem and welcoming new people.

For those who haven't, I'd recommend trying out the grid. It's connectable
from any 9 system, instructions are here:
http://wiki.9gridchan.org/Connecting/index.html
For those who would like to check out the grid's discussion but run linux
like myself, Sigrid created a client '9gc' that's able to access the
gridchat. It's here: https://git.sr.ht/~ft/9pro

I've found the community to be welcoming, helpful, knowledgeable - and,
unlike my lurker self, very active.

Thank you mycroftiv,

Marshall
a_mistake


On Mon, Jan 24, 2022, 06:14 mycroftiv 9gridchan <
mycrof...@sphericalharmony.com> wrote:

> Hi 9fans, Got some new ideas im excited about right now.
> Apparently the author of the well-known 'intro to OS abstractions'
> book has political views that are not cool and support oppression
> maybe I have heard secondhand.
> We need a better book to introduce people to 9.
> I'd like to see something created that talks about all forms of 9 and
> of the ANTS variant especially since if im bipolar and spending my
> money to try to help plan 9, im obviously also gonna be hyping my
> stuff along with trying to fight against right wing ideas.
> The cause to make plan 9 an accepting welcoming community for all
> humans requires good information resources and support.
> The funny-named organization I just thought up, The Flan 9 Poundation,
> offers a bounty from me personally of at least $200 for producing this
> content. The name is an obvious namespace pun. We want to work in a
> friendly way with everyone but we also want good stuff and peace and
> support for minority trans disabled mentally wacked out
> counterculture.
> 
> Peace and love and lets make Plan 9 amazing and full of rainbow love,
> JenBen

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T627a29a7babaf29e-Me8db3788460dfc8f35de711b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] astro: meeteeor shouwer?

[Marshall Conover]

Today's the peak of a seasonal meteor shower. I'm pretty excited, gonna be
out in the middle of nowhere this weekend, thinking of doing a timelapse.

On Wed, Jul 28, 2021 at 7:34 PM Anthony Sorace  wrote:

> Speaking of astro, anyone know the story behind this?
>
> :; astro | sed 2q
> 2021  7 28
> Pisces australid  meeteeor shouwer
>  :; agrep meeteeor /sys/src/cmd/astro/*.c
> /sys/src/cmd/astro/search.c:61:
>  event("%s  meeteeor shouwer",


-- 
Have a good day,

Marshall Conover

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tacdc412c0e6f68f2-M896d7f0e5ac6a84894b82141
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] help

[Marshall Conover]

The most recent humpback whale sighting I could find is this:
https://www.stuff.co.nz/environment/125480446/humpback-whales-put-on-spectacular-show-in-sounds

Live long and prosper,

Marshall

On Sun, Jun 20, 2021 at 10:55 AM Spock via 9fans <9fans@9fans.net> wrote:



-- 
Have a good day,

Marshall Conover

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T1bf00692daa5f082-M97f0a8e6e9023e7290decde7
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[Marshall Conover]

Absolutely awesome.

On Tue, Mar 23, 2021 at 11:47 AM  wrote:
>
> Quoth a...@9srv.net:
> > Obviously, for folks in the Plan 9 community, there isn't a way to say
> > "thank you" to Bell Labs, and its various parent organizations, that's
> > really adequate. None of us would be talking about any of this if it
> > weren't for the work done there for decades. All of us here at the Plan
> > 9 Foundation express our sincerest thanks to the team at Nokia who made
> > this possible, the Plan 9 alumni who supported the effort, and the Plan
> > 9 community who have kept kernels booting and the userland useful.
> >
> > The historical releases are available right now at:
> > https://p9f.org/dl/
> >
> > You can read Nokia's press release on the transfer here:
> > 
> > https://www.bell-labs.com/institute/blog/plan-9-bell-labs-cyberspace/
> >
> 
> Thanks for putting in the work -- it's much appreciated.



-- 
Have a good day,

Marshall Conover

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tf20bce89ef96d4b6-M3daebdba73f2eb3d33c2e962
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Plan 9 Foundation

[Marshall Conover]

Same! Enjoyed helping out with iwp92020, happy to help further.

On Wed, Feb 10, 2021 at 11:07 AM Steve Simon  wrote:

> > How do we get involved in or become a member of the foundation?
> 
> I too am interested in supporting plan9 in any form I can.
> 
> -Steve


-- 
Have a good day,

Marshall Conover

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T973ff41a99053355-M2c692b4a4c8158d3e3ebd082
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] u9fs in go?

[Marshall Conover]

Also of note is droyo's styx library, which I've found useful
personally in creating a 9p message queue, and which a few of us on a
9fans discord server use for additional projects:
https://github.com/droyo/styx

I'm not aware of anyone having created a u9fs equivalent using it, however.

Good luck!

Marshall



On Sun, Jul 12, 2020 at 7:00 PM David du Colombier <0in...@gmail.com> wrote:
> > Did anybody try to reimplement u9fs in go?
> > If not yet, which 9p go package would you recommend to use?
> > (I don't need any authentication only 9p.)
> 
> There is a multitude of 9P implementations in Go.
> 
> For example, this one, which includes a program to serve
> local files as a 9P filesystem:
> 
> https://github.com/Harvey-OS/ninep
> 
> --
> David du Colombier



--
Have a good day,

Marshall Conover

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tea875067b53dce5f-M579b37f678ba27330cbebc59
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] 9front kernel panic on bootstrap on rpi

[Marshall Conover]

Hi Dan! Just a note - you can only send plaintext emails to the 9front
mailing list, as a spyware prevention measure. It's likely what hung
you up.

On Fri, May 1, 2020 at 6:20 AM Daniel Morandini via 9fans
<9fans@9fans.net> wrote:
>
> Dear ori,
> thank you for the reply! First, the boot problem has been resolved with 
> cinap’s answer, the mice problem persists though.
>
> > 1) You're likely to get better results on the 9front mailing
> >   list. (9fr...@9front.org)
> I did actually, but I always get an error message back (containing only my 
> message actually, and some protocol information) when I try to send. I’m 
> subscribed to the list though, I can receive.
>
> > cpu% sha1sum 9front.pi.img
> > ffb9f6569c7c239a58f0e6e508aac9d2418333af9front.pi.img
> We got something on this ori!
> % shasum -a 1 9front-7408.1d345066125a.pi.img
> d058861d64b02fd2d068f94b8f398e1a559c579c  9front-7408.1d345066125a.pi.img
>
> > From what I understand, the difference there is that 9front
> > will parse the HID descriptor, while 9legacy will hardcode
> > the boot protocol. There are a number of places that this can
> > be going wrong -- from bad HID descriptors to power brownouts
> > to USB bugs.
> > As far as the mouse: First question -- does it work if you
> > plug it into a PC? (You can test with a USB stick). If it
> > fails there, then it's likely a problem with HID parsing.
> It does. With PC you mean microsoft? Anyway, I just tested out and it works 
> on macOS 10.15, Windows 10, 9legacy.
>
> > Second question: Does it work with a powered USB hub? If
> > yes, then it's likely to be the Pi's power limitations.
> > Third question: Does it work with a different mouse?
> > If not, then it'll take more work to investigate.
> I have just another mouse here, a nacon gaming mouse. It requires 5v though 
> and it does not work on any rpi I have. I don’t have powered USB hub here for 
> testing, but I can find one if needed!
> 
> Tell me what I can do to help you more.
> 
> jecoz



-- 
Have a good day,

Marshall Conover

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Td646dc8a14a94c8a-Me4a2a9459b5230910087243b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[Marshall Conover]

Hi all! We've gotten a few crude suggestions. While they weren't
ill-intentioned, please make sure you're not saying stuff that's
inappropriate at a workplace level. If you're not comfortable with
that requirement, or aren't sure if you should suggest something,
feel free to send me an email. Thanks!


On Tue, Oct 29, 2019 at 3:02 PM Rodrigo G. López  wrote:
>
> indeed!
>
> On Tue, Oct 29, 2019, 7:41 PM  wrote:
>>
>> ; 9fs docs.google.com
>> srv: timeout establishing connection to net!docs.google.com!9fs
>
>
> 9fans / 9fans / see discussions + participants + delivery options Permalink



--
Have a good day,

Marshall Conover

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T7414e0ecd12c8643-M0d69ab2518e280404d400227
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[Marshall Conover]

Hi All!

Next, I'm thinking it's probably best to ask for location suggestions
for consideration and research. I've made a google doc:
https://docs.google.com/spreadsheets/d/13DHIIlFQzMsDJ2fhx18cK6AmpJlBlOICVDZMb63xz7k/edit?usp=sharing

Feel free to add any locations that sound like a good idea to you.
Also feel free to add your name behind a location you'd be happy to go
to if someone has already suggested it.

This isn't meant to be the final round of voting; once we have
locations, we'll do some digging to see what's available in those
areas. Once we know that, we'll probably do a more serious poll for
attendees and a ranked-choice vote on location.

Let me know if there are any thoughts, concerns, or questions!

Thanks!

Marshall

On Tue, Oct 29, 2019 at 12:36 PM David Bulkow  wrote:
>
> We're here. Just very very quiet.
>
> On Tue, Oct 29, 2019 at 12:24 PM Nicolas S. Montanaro  wrote:
>> 
>> If indeed it ends up being held in the US I’d love to come - have yet to 
>> find any 9fans here in New England.
>> 
>> Cheers,
>> - Nicolas
>
> 9fans / 9fans / see discussions + participants + delivery options Permalink



-- 
Have a good day,

Marshall Conover

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

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

[Marshall Conover]

Hi All!

The poll's here: https://www.surveymonkey.com/stories/SM-YX9F7TC7/

Looks like we've got roughly 20 who would certainly attend, and maybe
5-10 additional based on location and what's available.

There's also a decent set of topics for discussion and events in the polling.

That sounds, to me, like enough people to at least entertain the idea,
and a fairly reasonable and manageable size from the perspective of
planning and execution.

Thanks!

Marshall

On Sat, Oct 26, 2019 at 4:32 PM Marshall Conover  wrote:
> > The survey seems more cute than useful. E.g. there's a *big* difference 
> > between
> > "travel a couple of hours" and "anywhere.".. I wouldn't consider travel to 
> > the
> > US... whereas I would consider travel to Europe...
>
> That's a good point. A ranked-choice deal based on locations would be better.
> Like you said, this is best just for a first-pass headcount - and
> having the countries
> people are in + their answer of how far they'd like to travel should
> hopefully help give
> a head-start on getting the list of actual potential venues down for
> later polls. I also
> have no idea what I'm doing.
>
> > I would be willing to kick in some $$$ to help pay to have the event 
> > streamed.
>
> Streaming is a great idea! One person's suggested they'd like to have coding
> going through the event as well, so that may also be a good way to keep
> tele-attenders involved.
>
> In the mean time, thanks for all who've voted so far! I figure I'll
> give it a day and then
> send the results out and see what people think.
>
> Mars
>
>
> On Sat, Oct 26, 2019 at 3:28 PM Lyndon Nerenberg  wrote:
> > > In that vein, here's a poll: https://www.surveymonkey.com/r/VJNQYGC
> > 
> > The survey seems more cute than useful. E.g. there's a *big*
> > difference between "travel a couple of hours" and "anywhere."  And
> > even though it's close by, I wouldn't consider travel to the US (a
> > couple of hours) due to the insanity involved in getting through
> > US immigration, whereas I would consider travel to Europe (~9 hours).
> > Asia would be out, due to travel time and cost.
> > 
> > But as a general gauge of initial interest it's certainly useful.
> > 
> > Sadly, while I'd love to go, 2020 doesn't look like a year where
> > I'll be doing much travelling :-(  But I would be willing to kick
> > in some $$$ to help pay to have the event streamed.
> > 
> > --lyndon
>
>
>
> --
> Have a good day,
>
> Marshall Conover



-- 
Have a good day,

Marshall Conover

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

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

[Marshall Conover]

> The survey seems more cute than useful. E.g. there's a *big* difference 
> between
> "travel a couple of hours" and "anywhere.".. I wouldn't consider travel to the
> US... whereas I would consider travel to Europe...

That's a good point. A ranked-choice deal based on locations would be better.
Like you said, this is best just for a first-pass headcount - and
having the countries
people are in + their answer of how far they'd like to travel should
hopefully help give
a head-start on getting the list of actual potential venues down for
later polls. I also
have no idea what I'm doing.

> I would be willing to kick in some $$$ to help pay to have the event streamed.

Streaming is a great idea! One person's suggested they'd like to have coding
going through the event as well, so that may also be a good way to keep
tele-attenders involved.

In the mean time, thanks for all who've voted so far! I figure I'll
give it a day and then
send the results out and see what people think.

Mars


On Sat, Oct 26, 2019 at 3:28 PM Lyndon Nerenberg  wrote:
> > In that vein, here's a poll: https://www.surveymonkey.com/r/VJNQYGC
> 
> The survey seems more cute than useful. E.g. there's a *big*
> difference between "travel a couple of hours" and "anywhere."  And
> even though it's close by, I wouldn't consider travel to the US (a
> couple of hours) due to the insanity involved in getting through
> US immigration, whereas I would consider travel to Europe (~9 hours).
> Asia would be out, due to travel time and cost.
> 
> But as a general gauge of initial interest it's certainly useful.
> 
> Sadly, while I'd love to go, 2020 doesn't look like a year where
> I'll be doing much travelling :-(  But I would be willing to kick
> in some $$$ to help pay to have the event streamed.
> 
> --lyndon



--
Have a good day,

Marshall Conover

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

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

[Marshall Conover]

While that might be about right, maybe it'd be better if we polled to
see for interest, and also got a good idea of where people live to
help get insight on where to host.

In that vein, here's a poll: https://www.surveymonkey.com/r/VJNQYGC

You can select level of interest; add your name, email, zipcode and
country code so we get the geographical distribution; suggest some
topics for panels you might be interested in; and weigh in on whether
we should continue using a thread on this mailing list for future
discussion or continue things in separate emails, in case uninterested
parties don't want to keep seeing emails about this topic.

Thoughts?

Marshall

On Fri, Oct 25, 2019 at 8:28 PM Skip Tavakkolian
 wrote:
>
> what's the size of 9fans list now?
>
> i would guess, optimistically, somewhere between 40-70 people might attend 
> the hackathon.
>
> i will get estimates from a couple of places around here ("Lodges on Vashon", 
> Camp Sealth, etc). if anyone is
> interested in looking in their area for suitable options, please let me know.
>
>
>
> On Thu, Oct 24, 2019 at 9:30 PM Kurt H Maier  wrote:
>>
>> On Thu, Oct 24, 2019 at 09:21:04PM -0700, Skip Tavakkolian wrote:
>> > Hi Erik! Vashon might be ok depending on time of year due to limited
>> > lodging options. I plan to check the O Space for the workshop. lodging will
>> > be challenging unless we take over campgrounds and set up yurts :)
>> 
>> AYH could comfortably lodge every active Plan 9 user on earth and has
>> decent space for meetings.
>> 
>> khm
>
> 9fans / 9fans / see discussions + participants + delivery options Permalink



-- 
Have a good day,

Marshall Conover

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

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

[Marshall Conover]

I'd be happy to volunteer some hours setting things up. I'd love to hear a
talk on mycroftiv's grid, as well.

On Tue, Oct 22, 2019, 20:24 Sean Hinchee  wrote:

> I would be very happy to volunteer whatever time and resources I can.
> 
> It would be awesome to see this happen :)
> 
> Cheers,
> Sean

On Tue, Oct 22, 2019, 20:24 Sean Hinchee  wrote:

> I would be very happy to volunteer whatever time and resources I can.
> 
> It would be awesome to see this happen :)
> 
> Cheers,
> Sean

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T48814d0ac9ef812a-M082565888407980e1bb2346e
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] UI design | enhancements.

[Marshall Conover]

Thanks, Ori, that's badass. I'll have to struggle with laziness re:hooking
up to a monitor/rebooting my cpu server to give it a go, but it would be
good to get a feel of what I'm aiming for.

Mart - thanks for pointing out Microviche. I had considered whether zooming
and other features might be neat down the line, if panning felt natural, so
having something to look at for that is great.

As an aside, Lucio, I'd second Ethan in that it's probably worth taking a
look; I'd be surprised if there was more actual code to change than there
was just ramp-up time to understand what you need to change, and a
one-or-two hour excursion into the code would probably get you how much
ramp-up time you need, at which point you could probably make the final
call on whether to move forward.

Thanks!

Marshall

On Mon, Apr 15, 2019 at 5:10 PM Ori Bernstein  wrote:

> On Mon, 15 Apr 2019 16:59:12 -0400
> Marshall Conover  wrote:
>
> > For example, I feel super squished on a single screen, but I've come to
> > dislike the awkwardness of switching between multiple 'workspaces' or
> > working with tiling wms. So I'm playing around with rio at the moment to
> > see if adding a 'panning' effect, where you treat the desktop as an
> > infinitely-scrollable table and allow the user to 'pan' around the table,
> > could be a natural approach to feeling less squished. It may end up being
> > even more awkward and painful, but it may also end up being something I'm
> > left wanting for in modern DEs - that could be an attraction to 9.
>
> From man 3 vga:
>
>   panning mode
>Depending on whether mode is on or off, enable or dis-
>able panning in a virtual screen.  If panning is on and
>the screen's size is larger than its actualsize, the
>displayed portion of the screen will pan to follow the
>    mouse.  Setting the panning mode after the first attach
>of the #i driver has no effect.
>
> --
> Ori Bernstein 
>


-- 
Have a good day,

Marshall Conover

Re: [9fans] UI design | enhancements.

[Marshall Conover]

Hi Darren!

I can see how 9's current UI could be considered a 'roadblock' to the
average user due to its unfamiliarity, and making it closer to modern looks
may make plan 9 pass the smell test for users more often. Personally,
though, it seems like a bit of a slog; there's not much exciting going on
in changing a UI to look like 'every other' UI, and I'd also wonder about
maintenance - you might update it to look familiar now, but in three years
where will it be, especially with web frameworks changing things so
frequently and invading the desktop with elektron? That said, if it does
draw more users, upkeep might get easier (just having people prompting with
issue reports can be productive), and it's genuinely nice to have a more
active community.

But, I'd be really interested to see it taken a step further. Instead of
just a facelift, I'd love to see changes that show a reflection on modern
UIs and their problems, and attempts to fix them. That'd not just remove a
roadblock for new users, but create change that may actually draw them.

For example, I feel super squished on a single screen, but I've come to
dislike the awkwardness of switching between multiple 'workspaces' or
working with tiling wms. So I'm playing around with rio at the moment to
see if adding a 'panning' effect, where you treat the desktop as an
infinitely-scrollable table and allow the user to 'pan' around the table,
could be a natural approach to feeling less squished. It may end up being
even more awkward and painful, but it may also end up being something I'm
left wanting for in modern DEs - that could be an attraction to 9.

In something that I feel relates closer to the heart of 9, one problem I
see in modern UIs is the inability to easily interact between programs.
Each UI acts as an island, and the best generic interface for interaction
you can get between them is allowing programs to send screen clicks, with
the nightmare quickly following of figuring out how to know where to click.
Web APIs are somewhat en route to addressing that with their REST endpoints
and swagger API definitions, but it seems so much more simple to instead
use files and directories over 9p.

Getting really out there, I'd love to see a tightly coupled way of
representing the commands you can send to a program via its ctl file API in
9 and a visual representation of that program in rio. I'd love if the UIs I
was using in a program corresponded to their filesystem API so much as to
be almost a mapping, perhaps even letting you generate a UI from the
filesystem API and some simple mark(down|up). I think a shell that worked
off of this concept could be fascinating - not unlike a browser in some
ways, but in keeping close to the filesystem abstraction, perhaps allowing
for much better interaction with the small, text-stream focused programs
that the unix mentality prefers.

In sum, I'd be happy to see an increase in users from a facelift, but what
I'd love to see are new draws that fix modern problems.

On a more practical level, you may find it notable that the nuklear lib
 has been ported for plan 9. It
may be a good start to create a UI that users coming from current workflows
will be comfortable looking at and interacting with. If you want to chat
with the porter of the nuklear lib for 9, you'll find him in this plan
9-focused discord server: https://discord.gg/6daut5T. You may also find
it's a good place for discussion like this.

Thanks for starting the discussion, and good luck!

Marshall

Re: [9fans] The Case for Bind

[Marshall Conover]

Thanks, Giacomo. I have no illusions of being the smartest person in the
room or anything above mediocre, but I think there's a good chance the
people at Bell Labs were in that category. Hopefully, if I try to follow
their design ideas, I can at least play at being smart for a bit. And, if I
do as much as possible in user-space, Google's lack of openness hopefully
won't be too great an obstacle. This is the first thing I've been excited
about in a long time, I'm going to at least take a shot, even if working
hard at something doesn't necessarily mean it'll pan out.

(Besides, I already have a name for the project in my head: "gihnurshk." It
stands for "It's pronounced 'nurshk'.")

Thanks!
Marshall

Re: [9fans] The Case for Bind

[Marshall Conover]

BLS - thanks for the wise words. What you've said has inspired me to
consider moving my efforts into user-space, and trying to create the entire
environment I want instead of just a piece of that environment, so that I
can achieve the simplicity you describe - instead of mixing approaches with
the environment the fuchsia developers currently plan.

Giacomo - While thinking on your advice, I realized most of what I've done
so far is just a fix for a bug in their current exposed version of the
'bind' command. If I submit that fix and some tests for it, I should be
able to then create union mounts and full-featured binds myself, in
user-space, by creating an additional fileserver that is able to return
merged directory entries from multiple sources, creating an entry in that
fileserver when the user asks to bind or union mount directories or files,
and binding the paths in the fuchsia namespace to the entries in that
fileserver. It'll still be a bit clunky due to their restriction of
processes being unable to modify their own namespace - so, I'll have to
start a new process for the desired bind/mount operations to apply - but in
the mean time, it'll be better than nothing (and I may just keep a parallel
branch with the four-line hack I fudged together that removes that
restriction). And in the mean time, I'll be looking for things to
contribute to fuchsia unrelated to that pursuit.

Thanks again, all. I appreciate you all taking a moment to help straighten
this dunce out. :)

(even you, khm)

Marshall

On Fri, Sep 15, 2017 at 7:59 AM Marshall Conover 
wrote:

> > But you are not your contributions, and since you freely agreed to
> donate your time for free, they don't owe you anything.
>
> Yeah, I've gone into this fully knowing they have no obligation to respond
> - and to be honest, even if I were a team member, they'd still have no
> obligation; I'm not leadership. That's why I've been trying to figure out a
> compelling reason, but I think you have it right with:
>
> > If you want to contribute to Fuchsia (or any similarly leaded project),
> start by writing tests, reviewing code, fixing small bugs, implementing the
> interfaces they designed and so on... they will thanks you a lot for your
> free and (really) useful work.
>
> I'll start digging in to see what I can do. I think I jumped the gun by
> trying to contribute a feature, and you're right that they're bound to
> appreciate bug fixes, test implementations, etc.
>
> Thanks for the help.
>
> Marshall
>
> On Thu, Sep 14, 2017 at 10:01 PM Marshall Conover 
> wrote:
>
>> > Note that Fuschia is a microkernel. Does it provide a filesystem
>> interface?
>>
>> Hi dho! Yes, it does, and the code I've modified to introduce the ability
>> to perform bind is a modification of the rudimentary binding their
>> interface already provided (top-level directory binds only, previously,
>> with any bind attempting to go more than one directory deep breaking
>> things), which they had implemented only as a method of testing a few
>> namespace features. The code changes are pretty much entirely in the
>> kernel, and are pretty small.
>>
>> That said, taking the long view, my current approach only extended their
>> current method - I'm thinking I may have to instead change some more
>> fundamental things in order to get union mounts working, such as creating a
>> per-namespace unions directory that holds the file descriptors for
>> namespace union filesystem nodes point to - which is what I'd like their
>> input on. I have noticed, though, that in their github repo (previously I
>> had been grabbing straight from the google repo), they have a README that
>> says they're not currently accepting more than bug changes, which might
>> partially explain the majority radio silence. While that decision hasn't
>> been mentioned directly in response to me on IRC, I'm thinking I may just
>> have to maintain a branch until it's exclusively opened up for more
>> substantial user contributions, whenever that is. :/
>>
>> Thanks!
>>
>> Marshall
>>
>> On Thu, Sep 14, 2017 at 8:53 PM Marshall Conover 
>> wrote:
>>
>>> Aleksandar -
>>>
>>> > I have a honest feeling you will end up as roadkill with this sort of
>>> approach.
>>>
>>> This is my concern as well. Combined with the fact the OS only has an
>>> IRC channel (which I'm constantly concerned I'm wearing out my welcome in)
>>> and the tepid response so far, part of the reason I came to 9fans was help
>>> refining my approach.
>>>
>>> You

Re: [9fans] The Case for Bind

[Marshall Conover]

> But you are not your contributions, and since you freely agreed to donate
your time for free, they don't owe you anything.

Yeah, I've gone into this fully knowing they have no obligation to respond
- and to be honest, even if I were a team member, they'd still have no
obligation; I'm not leadership. That's why I've been trying to figure out a
compelling reason, but I think you have it right with:

> If you want to contribute to Fuchsia (or any similarly leaded project),
start by writing tests, reviewing code, fixing small bugs, implementing the
interfaces they designed and so on... they will thanks you a lot for your
free and (really) useful work.

I'll start digging in to see what I can do. I think I jumped the gun by
trying to contribute a feature, and you're right that they're bound to
appreciate bug fixes, test implementations, etc.

Thanks for the help.

Marshall

On Thu, Sep 14, 2017 at 10:01 PM Marshall Conover 
wrote:

> > Note that Fuschia is a microkernel. Does it provide a filesystem
> interface?
>
> Hi dho! Yes, it does, and the code I've modified to introduce the ability
> to perform bind is a modification of the rudimentary binding their
> interface already provided (top-level directory binds only, previously,
> with any bind attempting to go more than one directory deep breaking
> things), which they had implemented only as a method of testing a few
> namespace features. The code changes are pretty much entirely in the
> kernel, and are pretty small.
>
> That said, taking the long view, my current approach only extended their
> current method - I'm thinking I may have to instead change some more
> fundamental things in order to get union mounts working, such as creating a
> per-namespace unions directory that holds the file descriptors for
> namespace union filesystem nodes point to - which is what I'd like their
> input on. I have noticed, though, that in their github repo (previously I
> had been grabbing straight from the google repo), they have a README that
> says they're not currently accepting more than bug changes, which might
> partially explain the majority radio silence. While that decision hasn't
> been mentioned directly in response to me on IRC, I'm thinking I may just
> have to maintain a branch until it's exclusively opened up for more
> substantial user contributions, whenever that is. :/
>
> Thanks!
>
> Marshall
>
> On Thu, Sep 14, 2017 at 8:53 PM Marshall Conover 
> wrote:
>
>> Aleksandar -
>>
>> > I have a honest feeling you will end up as roadkill with this sort of
>> approach.
>>
>> This is my concern as well. Combined with the fact the OS only has an IRC
>> channel (which I'm constantly concerned I'm wearing out my welcome in) and
>> the tepid response so far, part of the reason I came to 9fans was help
>> refining my approach.
>>
>> Your paragraph is apt and inspiring to me, but I'm beginning to think
>> they may just not be interested in outside code or approaches at this point
>> in time - which is rough, because now seems like the time to make a
>> decision like employing binds and union mounts. To put it simply, I'm not
>> sure I have the leverage or opening to really put forth the idea -
>> especially considering this is, y'know, their job, and they've got shit to
>> do. But, I'll try and keep in mind that I should argue not just from
>> "here's some places it would make things simple," but "this is how things
>> should work. It is detrimental to not have this feature, and not having it,
>> in sum, will waste millions of man-hours for the people who use this
>> operating system, the same way it's wasted lifetimes not being in Mac or
>> Windows."
>>
>> I don't want to give up on this, though. I honestly do believe it's the
>> right thing to do - and I want them to see that as well. I'm just trying to
>> figure out how to make the pitch that's needed, and I appreciate your help.
>>
>> Micah -
>>
>> thanks for your use cases. I'll keep these in mind. I had thought about
>> bringing up getting rid of $PATH and the others, but I wasn't sure I could
>> make a clean argument for why union mounting the directories was better
>> than just having a path. This will be a big help in allowing me to argue
>> that this is the 'correct' way to handle having to source information from
>> multiple paths, when you may or may not want any individual folder in the
>> current set.
>>
>> Thanks again, all. I'm going to keep working on getting together a bigger
>

Re: [9fans] The Case for Bind

[Marshall Conover]

> Note that Fuschia is a microkernel. Does it provide a filesystem
interface?

Hi dho! Yes, it does, and the code I've modified to introduce the ability
to perform bind is a modification of the rudimentary binding their
interface already provided (top-level directory binds only, previously,
with any bind attempting to go more than one directory deep breaking
things), which they had implemented only as a method of testing a few
namespace features. The code changes are pretty much entirely in the
kernel, and are pretty small.

That said, taking the long view, my current approach only extended their
current method - I'm thinking I may have to instead change some more
fundamental things in order to get union mounts working, such as creating a
per-namespace unions directory that holds the file descriptors for
namespace union filesystem nodes point to - which is what I'd like their
input on. I have noticed, though, that in their github repo (previously I
had been grabbing straight from the google repo), they have a README that
says they're not currently accepting more than bug changes, which might
partially explain the majority radio silence. While that decision hasn't
been mentioned directly in response to me on IRC, I'm thinking I may just
have to maintain a branch until it's exclusively opened up for more
substantial user contributions, whenever that is. :/

Thanks!

Marshall

On Thu, Sep 14, 2017 at 8:53 PM Marshall Conover 
wrote:

> Aleksandar -
>
> > I have a honest feeling you will end up as roadkill with this sort of
> approach.
>
> This is my concern as well. Combined with the fact the OS only has an IRC
> channel (which I'm constantly concerned I'm wearing out my welcome in) and
> the tepid response so far, part of the reason I came to 9fans was help
> refining my approach.
>
> Your paragraph is apt and inspiring to me, but I'm beginning to think they
> may just not be interested in outside code or approaches at this point in
> time - which is rough, because now seems like the time to make a decision
> like employing binds and union mounts. To put it simply, I'm not sure I
> have the leverage or opening to really put forth the idea - especially
> considering this is, y'know, their job, and they've got shit to do. But,
> I'll try and keep in mind that I should argue not just from "here's some
> places it would make things simple," but "this is how things should work.
> It is detrimental to not have this feature, and not having it, in sum, will
> waste millions of man-hours for the people who use this operating system,
> the same way it's wasted lifetimes not being in Mac or Windows."
>
> I don't want to give up on this, though. I honestly do believe it's the
> right thing to do - and I want them to see that as well. I'm just trying to
> figure out how to make the pitch that's needed, and I appreciate your help.
>
> Micah -
>
> thanks for your use cases. I'll keep these in mind. I had thought about
> bringing up getting rid of $PATH and the others, but I wasn't sure I could
> make a clean argument for why union mounting the directories was better
> than just having a path. This will be a big help in allowing me to argue
> that this is the 'correct' way to handle having to source information from
> multiple paths, when you may or may not want any individual folder in the
> current set.
>
> Thanks again, all. I'm going to keep working on getting together a bigger
> set of changes, and maybe staking my claim on a pull request. I'm not sure
> there's any other way to really get an 'audience.'
>
> Thanks!
> Marshall
>
> On Thu, Sep 14, 2017 at 5:40 PM Marshall Conover 
> wrote:
>
>> Hmm... I had thought of parallel installs, but A/B testing in order to
>> maximize ad revenue is a brilliant application.
>>
>> I have also been thinking about the potential for seamless instillation
>> and startup of applications - updates to app can be installed in the
>> background to a bound /tmp directory, with that directories' location
>> journaled; meanwhile, the application continues running for the user. The
>> updated application then begins in the background - using the /tmp
>> directory - and loads everything the user is currently doing in the old.
>> Then, it prompts the user to 'restart' the application, during which it
>> plays an ad for the amount of time a user would usually expect a restart to
>> take - with the benefit of being able to use CPU-intensive eye-tracking
>> software to watch the user's interest in ads. The amount of time could also
>> be A/B tested per application. At some point when t

Re: [9fans] The Case for Bind

[Marshall Conover]

Aleksandar -

> I have a honest feeling you will end up as roadkill with this sort of
approach.

This is my concern as well. Combined with the fact the OS only has an IRC
channel (which I'm constantly concerned I'm wearing out my welcome in) and
the tepid response so far, part of the reason I came to 9fans was help
refining my approach.

Your paragraph is apt and inspiring to me, but I'm beginning to think they
may just not be interested in outside code or approaches at this point in
time - which is rough, because now seems like the time to make a decision
like employing binds and union mounts. To put it simply, I'm not sure I
have the leverage or opening to really put forth the idea - especially
considering this is, y'know, their job, and they've got shit to do. But,
I'll try and keep in mind that I should argue not just from "here's some
places it would make things simple," but "this is how things should work.
It is detrimental to not have this feature, and not having it, in sum, will
waste millions of man-hours for the people who use this operating system,
the same way it's wasted lifetimes not being in Mac or Windows."

I don't want to give up on this, though. I honestly do believe it's the
right thing to do - and I want them to see that as well. I'm just trying to
figure out how to make the pitch that's needed, and I appreciate your help.

Micah -

thanks for your use cases. I'll keep these in mind. I had thought about
bringing up getting rid of $PATH and the others, but I wasn't sure I could
make a clean argument for why union mounting the directories was better
than just having a path. This will be a big help in allowing me to argue
that this is the 'correct' way to handle having to source information from
multiple paths, when you may or may not want any individual folder in the
current set.

Thanks again, all. I'm going to keep working on getting together a bigger
set of changes, and maybe staking my claim on a pull request. I'm not sure
there's any other way to really get an 'audience.'

Thanks!
Marshall

On Thu, Sep 14, 2017 at 5:40 PM Marshall Conover 
wrote:

> Hmm... I had thought of parallel installs, but A/B testing in order to
> maximize ad revenue is a brilliant application.
>
> I have also been thinking about the potential for seamless instillation
> and startup of applications - updates to app can be installed in the
> background to a bound /tmp directory, with that directories' location
> journaled; meanwhile, the application continues running for the user. The
> updated application then begins in the background - using the /tmp
> directory - and loads everything the user is currently doing in the old.
> Then, it prompts the user to 'restart' the application, during which it
> plays an ad for the amount of time a user would usually expect a restart to
> take - with the benefit of being able to use CPU-intensive eye-tracking
> software to watch the user's interest in ads. The amount of time could also
> be A/B tested per application. At some point when the user is not using the
> application, the journaled /tmp location can be copied over to the correct
> install path. I'm not quite sure how to inconvenience the user further than
> they normally are with this method, however...
>
> Thanks for all the insightful advice!
>
> Marshall
>
> On Thu, Sep 14, 2017 at 3:55 PM Marshall Conover 
> wrote:
>
>> khm - Unfortunately, that would conflict with the browsing model I want
>> to propose once I've proven my worth - in which the user emails a daemon
>> with the site they want, which the daemon then wgets, forwards to them, and
>> opens up emacs.
>>
>> Thanks!
>>
>> Marshall
>>
>> On Thu, Sep 14, 2017 at 10:58 AM Marshall Conover 
>> wrote:
>>
>>> Hi All!
>>>
>>>I've been exploring the Fuchsia operating system, and while they have
>>> per-process namespaces, they don't have a utility like plan 9's bind, nor a
>>> method of supporting it by default in their system libraries. I've made
>>> some progress on adding it (https://imgur.com/HELWbrQ), but enthusiasm
>>> for the concept seems lukewarm, and I'm coming to the point where I feel
>>> I'm going to need to make a strong argument for why it should be a feature
>>> of their per-process namespace filesystem. As someone who's neither on
>>> their team nor an employee of google, I feel that I'm going to need to make
>>> a damn good argument - and I'd very much like to, as it really, *really* is
>>> something I'd like to have easily within reach in a modern OS, and it seems
>>&g

Re: [9fans] The Case for Bind

[Marshall Conover]

Hmm... I had thought of parallel installs, but A/B testing in order to
maximize ad revenue is a brilliant application.

I have also been thinking about the potential for seamless instillation and
startup of applications - updates to app can be installed in the background
to a bound /tmp directory, with that directories' location journaled;
meanwhile, the application continues running for the user. The updated
application then begins in the background - using the /tmp directory - and
loads everything the user is currently doing in the old. Then, it prompts
the user to 'restart' the application, during which it plays an ad for the
amount of time a user would usually expect a restart to take - with the
benefit of being able to use CPU-intensive eye-tracking software to watch
the user's interest in ads. The amount of time could also be A/B tested per
application. At some point when the user is not using the application, the
journaled /tmp location can be copied over to the correct install path. I'm
not quite sure how to inconvenience the user further than they normally are
with this method, however...

Thanks for all the insightful advice!

Marshall

On Thu, Sep 14, 2017 at 3:55 PM Marshall Conover 
wrote:

> khm - Unfortunately, that would conflict with the browsing model I want to
> propose once I've proven my worth - in which the user emails a daemon with
> the site they want, which the daemon then wgets, forwards to them, and
> opens up emacs.
>
> Thanks!
>
> Marshall
>
> On Thu, Sep 14, 2017 at 10:58 AM Marshall Conover 
> wrote:
>
>> Hi All!
>>
>>I've been exploring the Fuchsia operating system, and while they have
>> per-process namespaces, they don't have a utility like plan 9's bind, nor a
>> method of supporting it by default in their system libraries. I've made
>> some progress on adding it (https://imgur.com/HELWbrQ), but enthusiasm
>> for the concept seems lukewarm, and I'm coming to the point where I feel
>> I'm going to need to make a strong argument for why it should be a feature
>> of their per-process namespace filesystem. As someone who's neither on
>> their team nor an employee of google, I feel that I'm going to need to make
>> a damn good argument - and I'd very much like to, as it really, *really* is
>> something I'd like to have easily within reach in a modern OS, and it seems
>> like such a low-hanging fruit of a feature.
>>
>> I have two scenarios currently I feel make a strong argument for the
>> inclusion of bind: one is running tests on an install of a product while
>> still being able to do development on it, by using a bind to redirect the
>> development dll to the install's dll in the process I'm developing in; and
>> the other an example of when a bind would just be convenient, such as a
>> certain process needing python2 instead of python3 on a system which
>> defaults to python 3, and have scripts that reference #/bin/python.
>>
>> So, I'd like to hear the community's thoughts on other uses of bind. I
>> think they'd be useful both for making my case for bind, and in thinking
>> about my continuing implementation of the command. I also want to implement
>> union mounting in the future (which I can get very-close-to-being-free with
>> my changes for umount), but right now bind is my focus.
>>
>> Thanks for your time.
>>
>> Marshall
>>
>

Re: [9fans] The Case for Bind

[Marshall Conover]

khm - Unfortunately, that would conflict with the browsing model I want to
propose once I've proven my worth - in which the user emails a daemon with
the site they want, which the daemon then wgets, forwards to them, and
opens up emacs.

Thanks!

Marshall

On Thu, Sep 14, 2017 at 10:58 AM Marshall Conover 
wrote:

> Hi All!
>
>I've been exploring the Fuchsia operating system, and while they have
> per-process namespaces, they don't have a utility like plan 9's bind, nor a
> method of supporting it by default in their system libraries. I've made
> some progress on adding it (https://imgur.com/HELWbrQ), but enthusiasm
> for the concept seems lukewarm, and I'm coming to the point where I feel
> I'm going to need to make a strong argument for why it should be a feature
> of their per-process namespace filesystem. As someone who's neither on
> their team nor an employee of google, I feel that I'm going to need to make
> a damn good argument - and I'd very much like to, as it really, *really* is
> something I'd like to have easily within reach in a modern OS, and it seems
> like such a low-hanging fruit of a feature.
>
> I have two scenarios currently I feel make a strong argument for the
> inclusion of bind: one is running tests on an install of a product while
> still being able to do development on it, by using a bind to redirect the
> development dll to the install's dll in the process I'm developing in; and
> the other an example of when a bind would just be convenient, such as a
> certain process needing python2 instead of python3 on a system which
> defaults to python 3, and have scripts that reference #/bin/python.
>
> So, I'd like to hear the community's thoughts on other uses of bind. I
> think they'd be useful both for making my case for bind, and in thinking
> about my continuing implementation of the command. I also want to implement
> union mounting in the future (which I can get very-close-to-being-free with
> my changes for umount), but right now bind is my focus.
>
> Thanks for your time.
>
> Marshall
>

[9fans] The Case for Bind

[Marshall Conover]

Hi All!

   I've been exploring the Fuchsia operating system, and while they have
per-process namespaces, they don't have a utility like plan 9's bind, nor a
method of supporting it by default in their system libraries. I've made
some progress on adding it (https://imgur.com/HELWbrQ), but enthusiasm for
the concept seems lukewarm, and I'm coming to the point where I feel I'm
going to need to make a strong argument for why it should be a feature of
their per-process namespace filesystem. As someone who's neither on their
team nor an employee of google, I feel that I'm going to need to make a
damn good argument - and I'd very much like to, as it really, *really* is
something I'd like to have easily within reach in a modern OS, and it seems
like such a low-hanging fruit of a feature.

I have two scenarios currently I feel make a strong argument for the
inclusion of bind: one is running tests on an install of a product while
still being able to do development on it, by using a bind to redirect the
development dll to the install's dll in the process I'm developing in; and
the other an example of when a bind would just be convenient, such as a
certain process needing python2 instead of python3 on a system which
defaults to python 3, and have scripts that reference #/bin/python.

So, I'd like to hear the community's thoughts on other uses of bind. I
think they'd be useful both for making my case for bind, and in thinking
about my continuing implementation of the command. I also want to implement
union mounting in the future (which I can get very-close-to-being-free with
my changes for umount), but right now bind is my focus.

Thanks for your time.

Marshall

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

[Marshall Conover]

> 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

Awesome! Thanks for putting these up. I wasn't aware of 9legacy, I'll have
to go looking around.

Thanks!

Marshall

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

[Marshall Conover]

> An alternative to building a Go 1.4.3 bootstrap environment, is to build a
Go 1.7 bootstrap environment for Plan 9 in a mainstream environment ...

> If you want to build the current Go source from scratch on plan9/386,
you can just do...

The binary I built was specifically for arm (or more accurately, for the
raspi), on which I initially spent a chunk of time trying to get 1.4
building; eventually, as suggested here, cross-compiling on my Linux box
was how I ended up getting things working. However, that process wasn't
really intuitive, and felt a good chunk like wasted time.

I figured having a binary available would save people some hassle; there's
no real reason to make everyone cross-compile the binary, especially with
as small a target platform as the pi, and for people like myself who
weren't immediately aware of exactly what to do, it's more things to figure
out for no real reason. Bandwidth is cheap, the binary's small, so I
figured having it around would help other people who install plan 9 on
their Pi to check it out.

I'm already hosting it myself, but it seems like my link got me
spam-filtered. I'm more just wondering where to make it more obvious that
it's available, so noobies like myself can just grab it and play instead of
having to spin the same wheels I did.

Thanks!

mars

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

[Marshall Conover]

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] Questions on the browser as a platform if plan 9 had gained marketshare

[Marshall Conover]

> I was browsing of my old plan 9 mail and this conversation from 2000 made
me think of your thread here:  https://goo.gl/PO85oD

That conversation was interesting! It seemed Matt was a pretty prescient
guy. The "supports the latest standards...whose?" bit gave me a chuckle.

There wasn't too much in the way of directed conversation about what
different implementations of the web could've been, sadly, though there
were some - more just how feasible it'd be to implement the web as it was
on plan 9. I'm sure whatever Rob's intern was working has been lost to time.

Thanks for finding it!

[9fans] The correct way to do an incorrect thing

[Marshall Conover]

Hi all!

As an awful person, I hacked rio's data.c to support backgrounds. Because
the default code took a 1-by-1 pixel grey image and tiled it, I just shoved
a line in there to load an image file instead using readimage(). (Hacked
really is the appropriate word here.)

My question is, would the plan9 approach to this (assuming this were a plan
9 thing to do in the first place) be to add a command line argument to rio
that lets the user specify a file, or would it be to present some file
somewhere the user can write a background to? E.g., `cat
/usr/glenda/backgrounds/bg.bit > /rio/bg`.

If there are any papers or man pages that'd be good to read for this
question, I'd appreciate a finger in that direction.

Thanks!

mars

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

[Marshall Conover]

>  Ken and rob are currently working at google trying to
make sure it stays so - the idea being that if the stupid people that
control the real OS can't be made to learn at least they'll make
themselves an abstract environment that can hide the past and all the
pain, to then work on interesting, more challenging ideas on the
higher level (in the web) without distractions.

So, to make sure I understand correctly, the idea is to leave the actual OS
behind, and have all future development done entirely in the web, with the
browser as an application platform/web services being the OS, and finding a
way to make web services more composable? And this is being actively worked
on by Rob and Ken? I'm tempted to somehow work in the 9front release title
"Why not as a JS library?"

Is there any more information on this? I'd be interested in seeing what a
design like that would be like, and what challenges they're trying to
address. The browser as a platform and the technologies around it seem like
such a kludge after 20-some years of incremental, meandering progress, I'd
think there might be a lot of difficulty trying to base a simple, solid
system on them. Then again, I'm not a web dev, so I could be
misunderstanding what goes on in that domain entirely.

Thanks again!

mars

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

[Marshall Conover]

> I wonder if 9p could be implemented on an SoC.

It'd be neat for the whole 'internet of things' hullabaloo.

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

[Marshall Conover]

> 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.

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 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.

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.

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.

> This was however because I wanted to call a site "Troff the Crime
Blog."

I chortled.

I was wondering if maybe today a similar thing could be done with docker or
the rocket containers, but I'm not familiar enough with them; it seems like
they're somewhat baked images, not just namespaced folders with the
relevant things union-mounted inside them, so it might not be easy or fast
to just union mount the things you need for the web-app you're loading in a
new docker instance. Also, they have no UI support, thought it seems like
you can dynamically link an X socket into them to draw to an X session on
the parent machine with some extra work.

Let me know if this conversation is not really appropriate for this mailing
list at this point, by the way. I don't want to be a nuisance.

I appreciate the discussion so far - thanks!

mars

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

[Marshall Conover]

Thanks, Chris! That was a lot more detailed than I had thought into it.

> 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.

> Multimedia documents with both pictures and text are compiled into self
contained files kind of like PDF without hyperlinks and arbitrary code
expectation... This rich format is for longer and more focused reading
sessions: studying a topic, leisure reading.

I had originally been thinking along these lines, but the more I think
about it, the more I think there would have been a lot of demand for flashy
displays, and so I think something like a library for a flash-like language
that users would execute would've popped up. While I think users could've
gotten used to normal text (and it actually may have been more intuitive,
especially for older, non-technical people who are distracted by flashy
things), I think the people paying for development would've wanted more,
including graphics and animations.

>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.

This would've been amazing.

> 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.

This would be interesting, as well, when combined with network+union
filesystems, for being able to do something like run a website like reddit
with pointers to files hosted by users themselves. The possible advantage I
was thinking about is that a user could post comments as files stored on
their local accounts with group permissions they can specify, allowing them
to only have their friends see those files; the 'reddit' site would only
host the file pointers, and people would only be able to see those comments
on the reddit reader-app if they had the correct permissions. Usrers could
then delete their comments at will without worrying about the site holding
onto them in old DB backups or the like.

Thanks, also, Hiro!

> There is nothing wrong with the web having a limited scope of features.

Well, since everyone is trying to make the web the OS - see the chrome
boxes, for example - why not cut out the middleman and just have the OS
doing things? It seems like it's going to happen no matter what.

> If they are on par, then why waste time with the web part?

Well, that's the point, isn't it? You can access applications from
anywhere, and you don't need a browser to act as a platform to do it. You
also don't need to install them using some wizard and registry and all the
other BS.

> security and privacy in the web is hopeless. it plainly was never a real
goal.

Would plan9 have made it reasonable to become one?

> popular things tend to drive people. doesn't say anything about the
technical or even educational qualities though.

I think this is a good point. I was also thinking that ease-of-entry would
likely have developed more on the application side if more people had been
using it.

> Plan 9 technically is just one small collection of more consistent
alternative building blocks, but the web has ignored, reinvented or
misunderstood most others, too.

Yeah, this is sort of why I've been thinking about this. I've almost begun
getting frustrated when I see all the redundant design in the browser that,
at least it seems, could've just been done with the OS. Every time a friend
or intern pings me with a web problem, it seems more and more like the web
is just a series of kludges from trying to make the newspaper man be a
song-and-dance man who gives you live television.

Thanks for the thoughts!

mars

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

[Marshall Conover]

Hi all,

   For context, I am a plan 9 novice - I've played around just enough to
add jury-rigged background-image support for rio (for better or worse),
implore sl - if I remember correctly - to add the ^B option to 9front's rc
that brings the cursor to the current input place, and, for what it's
worth, create this: http://i.imgur.com/6iiF3zi.png.

   I've been wondering about how the web - specifically, the browser as a
platform for applications - would have been different had plan 9 become a
significant influence in operating systems in the early 90s. I've come to
the point where I thought a discussion here might be enjoyable and
enlightening, hopefully even to the point of dispelling the playful ribbing
that this mailing list may or may not be dead. If this conversation has
already occurred, my apologies.

  The improvement I think plan 9 could have brought to the early web is in
allowing the browser to have remained, as I understand it to have been,  a
medium for mark-up text and images, and have the OS act as the platform for
web applications.

The process I'm thinking of would be, with the example of a banking
application: the user opens the bank's web page in a plan 9 browser; the
user clicks a 'login' link; that link is sent to the plumber, which detects
it as a web application link and directs it to a service which:
- sandboxes it, perhaps by using a 'web' user or just modifying the
namespace to show the process a limited set of information;
- sets the namespace to prefer any libraries that are on the remote bank
machine, allowing the application to always run with the environment the
application developers intended;
- sets the namespace to include any files the application needs from the
remote sandbox, e.g. a directory with the user's banking files.

As a result of this, it seems that much of the hooplah around flash, webGL,
javascript, etc. could have been avoided, and that web applications from
yesteryear could still run today (for better or worse), since they could
control their environment. Web programming would have also have started off
with far greater ability, instead of having being limited by the abilities
of its browser platform and waiting years for even simple things to be
standardized. Web games, video-streaming applications, etc. on par with
local applications could have been launched as soon as the infrastructure
could support them, as the providers could just program the application to
do whatever the OS allowed.

It also seems it would avoid cookies and other privacy issues, since
applications would be sandboxed to only know about the things they have
available to them.

That said, having had discussions with friends in web development, they
have expressed concerns about ease-of-use and their initial interest in the
field - if I understand correctly, they feel that html's ease of
modification and immediate gratification was beneficial to getting them
into programming, which - while my understanding of this community is that
here it's not a highly valued thing - is, I think an important point to
address. They are application developers, and the web had aspects system
languages did not which attracted them.

Again, if these thoughts are obvious, my apologies, and if it's deeply
flawed, my apologies - but I'd be interested in hearing why.

Thanks for your time,

Mars