9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* [9fans] OAuth2 in factotum
@ 2021-08-16 11:15 Demetrius Iatrakis
  2021-08-17  3:48 ` Lucio De Re
                   ` (4 more replies)
  0 siblings, 5 replies; 85+ messages in thread
From: Demetrius Iatrakis @ 2021-08-16 11:15 UTC (permalink / raw)
  To: 9fans

This is a preview of OAuth2 support in factotum, as part of this year's GSoC:
https://github.com/Mitsos101/plan9front/pull/1

Installation, on 9front:

git/clone https://github.com/Mitsos101/plan9front plan9front-oauth
cd plan9front-oauth
git/branch oauth
bind sys/include /sys/include
@{cd sys/src/libauth && mk install}
@{cd sys/src/cmd/auth && mk install}
@{cd sys/src/cmd/webfs && mk install}

This will replace your factotum.

Usage:

You need to obtain OAuth credentials from your issuer first. See, for
example, Google's guide:
https://developers.google.com/identity/protocols/oauth2.

% echo 'key proto=oauth issuer=https://accounts.google.com scope=email
client_id=1234 !client_secret=5678' > /mnt/factotum/ctl
% auth/oauth 'client_id=1234'
go to https://google.com/device
your code is ABCD-EFGH
<after user consent is provided, the access token is printed>

auth_oauth is also available in libauth. Webfs uses it to implement
the preoauth command.

Bugs:

This code is specific to 9front, as libjson is required and Plan 9's
webfs doesn't support preoauth.

factotum uses the needkey RPC to display the verification URL and code
to the user. This means that, for now, the needkey file must not be
open so that fgui doesn't intercept it.

The module imports lots of code to support HTTP/1.0 so that the
refresh token doesn't leave factotum's address space.

Only the device and refresh flows are supported. There is an
implementation of the authorization code flow (tested on macOS) here:
https://github.com/Mitsos101/plan9port/pull/1. However, it is not
included in the module as there is no good browser to plumb the URL
to.

Refresh tokens are not saved to persistent storage when factotum
exits. The user must provide consent every time factotum is restarted.

-- 
Demetrius

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T6899bf3f0654295d-Mf96a66de0d3d224f967f3983
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] OAuth2 in factotum
  2021-08-16 11:15 [9fans] OAuth2 in factotum Demetrius Iatrakis
@ 2021-08-17  3:48 ` Lucio De Re
  2021-08-17  7:47   ` Keith Gibbs
  2021-08-17 15:25   ` ori
  2021-08-17  4:13 ` ori
                   ` (3 subsequent siblings)
  4 siblings, 2 replies; 85+ messages in thread
From: Lucio De Re @ 2021-08-17  3:48 UTC (permalink / raw)
  To: 9fans

On 8/16/21, Demetrius Iatrakis <demetrius.iatrakis@gmail.com> wrote:
> This is a preview of OAuth2 support in factotum, as part of this year's
> GSoC:
> https://github.com/Mitsos101/plan9front/pull/1
>
Sounds amazing, on many levels. So, thank you.

Having just been through an only partially successful hack of P9P
factotum and libauth to support the valiant "ssh-agent" facility, I am
rather keen to seek the help of other competent people to help me fill
the gaps my knowledge doesn't span and also to contribute to what I'm
keenly hoping will be a single factotum product before too long.

If I can help in any way, I can be contacted, most conveniently, on
whatsapp (+27 83 251 5824) or skype (luciodere), neither being much of
a favourite - Plan 9 does rather spoil one, albeit not for choices,
thankfully.

Lucio.

PS: This does rather sound like we ought to have a lobbying group to
propose and prepare updates for submission to the One Plan Nine (1P9)
that the Foundation is hopefully aiming towards. Of course, that would
also require an arbitration group within the P9F that responds to
requests in a timeous manner.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T6899bf3f0654295d-M821541b52cb471af9c9fe154
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] OAuth2 in factotum
  2021-08-16 11:15 [9fans] OAuth2 in factotum Demetrius Iatrakis
  2021-08-17  3:48 ` Lucio De Re
@ 2021-08-17  4:13 ` ori
  2021-08-17  5:43   ` Lucio De Re
  2021-08-19  3:52 ` Kurt H Maier
                   ` (2 subsequent siblings)
  4 siblings, 1 reply; 85+ messages in thread
From: ori @ 2021-08-17  4:13 UTC (permalink / raw)
  To: 9fans

[full disclosure, I've been involved in this as a gsoc
mentor; moving discussion to public list.]

These are the two main sticking points, IMO.

Quoth Demetrius Iatrakis <demetrius.iatrakis@gmail.com>:
> Only the device and refresh flows are supported. There is an
> implementation of the authorization code flow (tested on macOS) here:
> https://github.com/Mitsos101/plan9port/pull/1. However, it is not
> included in the module as there is no good browser to plumb the URL
> to.

First off, for those following along at home, device
flow is a browserless way of using oauth, but providers
appear to often limit it beyond the point usefulness, so
we'd need to find a way to make factotum communicate
with a browser in order to get the tokens in.

Sadly, even the netsurf port isn't enough browser to run
Google's oauth login page.

So, the question here becomes how to glue in a helper
program between factotum and oauth.

There are a few options -- using the plumber in both
directions will work, but it's a bit gross -- and
involves broadcasting the tokens.

The only real alternative I can imagine is having a
special file that factotum calls out to in the namespace,
something like:

        /rc/bin/oauth-helper:

                #!/bin/rc
                ssh user@unix invoke-browser-and-get-token-helper

> Refresh tokens are not saved to persistent storage when factotum
> exits. The user must provide consent every time factotum is restarted.

For this, the tokens should probably be persisted into
secstore -- but there are some security implications
in giving factotum long-lived access to the persistent key
store.



------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T6899bf3f0654295d-M4a39ddac185f3a4de8c91e0a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] OAuth2 in factotum
  2021-08-17  4:13 ` ori
@ 2021-08-17  5:43   ` Lucio De Re
  0 siblings, 0 replies; 85+ messages in thread
From: Lucio De Re @ 2021-08-17  5:43 UTC (permalink / raw)
  To: 9fans

On 8/17/21, ori@eigenstate.org <ori@eigenstate.org> wrote:
> [full disclosure, I've been involved in this as a gsoc
> mentor; moving discussion to public list.]
>
> These are the two main sticking points, IMO.
>
> Quoth Demetrius Iatrakis <demetrius.iatrakis@gmail.com>:
>> Only the device and refresh flows are supported. There is an
>> implementation of the authorization code flow (tested on macOS) here:
>> https://github.com/Mitsos101/plan9port/pull/1. However, it is not
>> included in the module as there is no good browser to plumb the URL
>> to.
>
> First off, for those following along at home, device
> flow is a browserless way of using oauth, but providers
> appear to often limit it beyond the point usefulness, so
> we'd need to find a way to make factotum communicate
> with a browser in order to get the tokens in.
>
> Sadly, even the netsurf port isn't enough browser to run
> Google's oauth login page.
>
> So, the question here becomes how to glue in a helper
> program between factotum and oauth.
>
> There are a few options -- using the plumber in both
> directions will work, but it's a bit gross -- and
> involves broadcasting the tokens.
>
> The only real alternative I can imagine is having a
> special file that factotum calls out to in the namespace,
> something like:
>
>         /rc/bin/oauth-helper:
>
>                 #!/bin/rc
>                 ssh user@unix invoke-browser-and-get-token-helper
>
>> Refresh tokens are not saved to persistent storage when factotum
>> exits. The user must provide consent every time factotum is restarted.
> 
> For this, the tokens should probably be persisted into
> secstore -- but there are some security implications
> in giving factotum long-lived access to the persistent key
> store.
> 


-- 
Lucio De Re
2 Piet Retief St
Kestell (Eastern Free State)
9860 South Africa

Ph.: +27 58 653 1433
Cell: +27 83 251 5824

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T6899bf3f0654295d-Ma225d00818d7370c67285bcf
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] OAuth2 in factotum
  2021-08-17  3:48 ` Lucio De Re
@ 2021-08-17  7:47   ` Keith Gibbs
  2021-08-18  3:55     ` Lucio De Re
  2021-08-17 15:25   ` ori
  1 sibling, 1 reply; 85+ messages in thread
From: Keith Gibbs @ 2021-08-17  7:47 UTC (permalink / raw)
  To: 9fans

One Plan Nine? 

Sure, we have the historical version of the Bell Labs/Lucient codebase, preserved as 9legacy, but yeah we have one currently developed branch of Plan 9 called 9front. Are you proposing that to be called “Plan 9 from Bell Labs 5th edition”?

To be serious though, when has monolithic code bases ever benefited things in an Open Source community? I mean the only reason would be to control who can/cannot make decisions on what goes in the stone soup. There are multiple BSDs. There are multiple Linuxes. Using 9legacy as more than historical baseline means that we will be stuck with decisions put in place 20-30 years ago rather than iterating and moving things forward. The purpose of P9F is to “promote and support” not to regulate.

I would love to imagine a time when we have a resurgence of multiple Plan 9s. I would love to see Akaros and 9atom have a shot in the arm [although much of what the latter had seems to be swallowed up by 9front and 9legacy and the project dead]. I would love to see NIX get a little more traction, as it seems it is just a standalone experiment [albeit a cool one in terms of goals]. I think it would be really healthy for Jeanne and Harvey to be more closer to “family” in the community rather than third cousins. Once we have a plurality of opinions, of perspectives, of visions, then we can better broker standards and overall trajectories. 

Best, 

-pixelhersy

> 
> PS: This does rather sound like we ought to have a lobbying group to
> propose and prepare updates for submission to the One Plan Nine (1P9)
> that the Foundation is hopefully aiming towards. Of course, that would
> also require an arbitration group within the P9F that responds to
> requests in a timeous manner.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T6899bf3f0654295d-M028436730443a261d224355a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] OAuth2 in factotum
  2021-08-17  3:48 ` Lucio De Re
  2021-08-17  7:47   ` Keith Gibbs
@ 2021-08-17 15:25   ` ori
  2021-08-18  3:59     ` Lucio De Re
  1 sibling, 1 reply; 85+ messages in thread
From: ori @ 2021-08-17 15:25 UTC (permalink / raw)
  To: 9fans

Quoth Lucio De Re <lucio.dere@gmail.com>:
> PS: This does rather sound like we ought to have a lobbying group

You realize that this *is* the lobbying, right?

Someone did the work, posted a patch, and is
asking for review and possibly commits.

Stop derailing the discussion.


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T6899bf3f0654295d-Me3ca960fe7afab764f5d4394
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] OAuth2 in factotum
  2021-08-17  7:47   ` Keith Gibbs
@ 2021-08-18  3:55     ` Lucio De Re
  2021-08-18  7:02       ` [9fans] Software philosophy Skip Tavakkolian
  2021-08-18  9:18       ` [9fans] OAuth2 in factotum Keith Gibbs
  0 siblings, 2 replies; 85+ messages in thread
From: Lucio De Re @ 2021-08-18  3:55 UTC (permalink / raw)
  To: 9fans

On 8/17/21, Keith Gibbs <k@pixelheresy.com> wrote:
> One Plan Nine?
>
> Sure, we have the historical version of the Bell Labs/Lucient codebase,
> preserved as 9legacy, but yeah we have one currently developed branch of
> Plan 9 called 9front. Are you proposing that to be called “Plan 9 from Bell
> Labs 5th edition”?
>
I bet you think I don't; you wouldn't ask, otherwise.

> To be serious though, when has monolithic code bases ever benefited things
> in an Open Source community?

You bought the "exceptionalism" Kool-Aid, lock, stock and barrel,
haven't you? It's a question of size: a small code base should remain
small, then it is not weaponisable or monetisable. So we raise the bar
higher and higher and shake off whatever can't stick hard enough. A
human natural instinct (more!, gimme more! features! bugs! anything so
I can have bigger, faster!) bent to the interest of elites (here in
Africa we know it as the Big Man Syndrome).

> I mean the only reason would be to control who
> can/cannot make decisions on what goes in the stone soup.
Do you have incontrovertible evidence? In my caffeine-deprived state,
I feel you're just following the sheep gospel, no offence intended. In
my opinion, the trap is always there, ready to be deployed. And the
masses are always ready to fall into it. Occasionally a Christ figure
comes along to warn us, but only the elite can understand the message
and of course they then distort it in the direction that suits them
best. And the masses are none the wiser, not this time, not the next
time, not any other time, because the elite can be swapped out
entirely and the new elite becomes them, ad nauseam.

> There are multiple
> BSDs. There are multiple Linuxes. Using 9legacy as more than historical
> baseline means that we will be stuck with decisions put in place 20-30 years
> ago rather than iterating and moving things forward. The purpose of P9F is
> to “promote and support” not to regulate.
>
Sure, and an infinite variety of vehicles with wheels at the four
corners and seats that just occupy space and consume carbon-based
fuels. Even EVs where each wheel could be both motor and power
generator have retained that ridiculous formula. But they look
different (sort of, there's greater difference in time than there in
style). Oh, let's not ignore that autos also sit idle (my estimate)
95% of their life: is that what they are designed for? And the AI in
my phone, is that also sitting idle? I had a couple of instances
recently where in the middle of the night my password locked Samsung
J5 decided to continue reading me the SF short story collection I
turned off before going to sleep.

But Android is Open Source, isn't it? I can look under the bonned, can't I?

Well, the P9F is what it is. It will also become what it is naturally
attracted to unless some boundaries - Trump's fence? - are put in
place.

> I would love to imagine a time when we have a resurgence of multiple Plan
> 9s. I would love to see Akaros and 9atom have a shot in the arm [although
> much of what the latter had seems to be swallowed up by 9front and 9legacy
> and the project dead]. I would love to see NIX get a little more traction,
> as it seems it is just a standalone experiment [albeit a cool one in terms
> of goals]. I think it would be really healthy for Jeanne and Harvey to be
> more closer to “family” in the community rather than third cousins. Once we
> have a plurality of opinions, of perspectives, of visions, then we can
> better broker standards and overall trajectories.
>
I'm going to leave this here, with a comment to the effect that I
totally disagree with the sentiments. There is room, need is not a
strong enough word for what I'm thinking, for creativity, but software
is not a primordial soup out of which complex organisms will rise to
take over the Universe and consume it out of existence, its and
theirs.

More likely, we'll teach - by example, not intentionally, no - our AI
products to weaponise the tools we are no longer sufficiently
naturally intelligent to understand and control (tell me there's a
difference) and turn us into slaves because, like the human elite,
they will measure their worth in what they can accumulate (human
slaves sounds like a neat currency to me, I could use some, it's
worked in all of human history - ask Epstein), just like their
creators did.

Nothing to do with Plan 9, of course, because it really is just a drop
of accidental sanity in an ocean of greed and competition. But, to
complete the imagery, I'd rather be plankton in a drop of Plan 9 than
a shark in the Linux Ocean. And I am, to the extent that I support and
most of all appreciate what makes my ecosystem continue to tick.
Including any contributions by like-minded or antagonistically natured
geniuses.

Lucio.

PS: I have a lot of time to think and unfortunately not the means to
study beyond a rather narrow subject matter. So my opinions are much
more the result of introspection than of universal knowledge. Take it
for what it is.

PPS: There is always an elite, its job is to defeat by all means
available a middle class whose "elite nouveau" continually attempts to
replace it, by any means available to it. Everything revolves around
who owns the masses. That's Western Civilisation in a nutshell.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T6899bf3f0654295d-M52ee3c3eec22dd0009406d54
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] OAuth2 in factotum
  2021-08-17 15:25   ` ori
@ 2021-08-18  3:59     ` Lucio De Re
  2021-08-18  4:20       ` ori
  0 siblings, 1 reply; 85+ messages in thread
From: Lucio De Re @ 2021-08-18  3:59 UTC (permalink / raw)
  To: 9fans

On 8/17/21, ori@eigenstate.org <ori@eigenstate.org> wrote:
> Quoth Lucio De Re <lucio.dere@gmail.com>:
>> PS: This does rather sound like we ought to have a lobbying group
>
> You realize that this *is* the lobbying, right?
>
Does it work?

> Someone did the work, posted a patch, and is
> asking for review and possibly commits.
>
I wasn't aware I inhibited that in any way. But clearly your response
suggests I did.

> Stop derailing the discussion.
>
I accept the reprimand, it is valid. My nature is to be part of a
bigger whole rather than a shining light and I tend to look for
opportunities to confirm my beliefs. I'll try to hold back some.

Lucio.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T6899bf3f0654295d-Mc796911b62abdc1ebb146b30
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] OAuth2 in factotum
  2021-08-18  3:59     ` Lucio De Re
@ 2021-08-18  4:20       ` ori
  2021-08-18  4:42         ` Eli Cohen
  2021-08-18  5:06         ` Lucio De Re
  0 siblings, 2 replies; 85+ messages in thread
From: ori @ 2021-08-18  4:20 UTC (permalink / raw)
  To: 9fans

Quoth Lucio De Re <lucio.dere@gmail.com>:
> Does it work?

Have you tried it? What bugs do you
have to report?


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T6899bf3f0654295d-Mc8c90fc9b9a041f8af54503f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] OAuth2 in factotum
  2021-08-18  4:20       ` ori
@ 2021-08-18  4:42         ` Eli Cohen
  2021-08-18  5:06         ` Lucio De Re
  1 sibling, 0 replies; 85+ messages in thread
From: Eli Cohen @ 2021-08-18  4:42 UTC (permalink / raw)
  To: 9fans

"Why am I so affected by her death? The deaths of countless others
have never elicited such an emotional response in me." - Data
"If we knew the answer to that... human history might be a lot less
bloody." - Riker

On Tue, Aug 17, 2021 at 9:22 PM <ori@eigenstate.org> wrote:
>
> Quoth Lucio De Re <lucio.dere@gmail.com>:
> > Does it work?
> 
> Have you tried it? What bugs do you
> have to report?
> 

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T6899bf3f0654295d-M7983db2521327a11491d43dc
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] OAuth2 in factotum
  2021-08-18  4:20       ` ori
  2021-08-18  4:42         ` Eli Cohen
@ 2021-08-18  5:06         ` Lucio De Re
  1 sibling, 0 replies; 85+ messages in thread
From: Lucio De Re @ 2021-08-18  5:06 UTC (permalink / raw)
  To: 9fans

On 8/18/21, ori@eigenstate.org <ori@eigenstate.org> wrote:
> Quoth Lucio De Re <lucio.dere@gmail.com>:
>> Does it work?
>
> Have you tried it? What bugs do you
> have to report?
>
No. I have neither the 9front platform, nor the Oauth2 requirements
that would motivate an outsider to try something like that out.

Had I offered my services - or been asked by someone who knows that I
have an interest in reducing factotum to a single service, nicely
wrapped as I believe it can be for use across architectures, or my
past, brief investigation of Oauth2 - I would feel obliged to do so
and would do my best to deliver accordingly.

Lobbyists have the greatest vested interest in providing their
services. Not everyone can be expected to be driven by the quest for
fame and glory. Maybe, like me, they like to adjust the mindset knobs
a bit to make the context nicer to work in. Or, also like me, to
encourage those who have greater skills and knowledge toward an
objective they share.

I don't expect miracles and I don't feel much pain when others revolt
violently against what I attempt to formulate as suggestions rather
than mandates. You may want to save your barbs for more sensitive
targets.

Lucio.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T6899bf3f0654295d-M5a895ccfabca569acf13f32e
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* [9fans] Software philosophy
  2021-08-18  3:55     ` Lucio De Re
@ 2021-08-18  7:02       ` Skip Tavakkolian
  2021-08-18  7:19         ` hiro
                           ` (3 more replies)
  2021-08-18  9:18       ` [9fans] OAuth2 in factotum Keith Gibbs
  1 sibling, 4 replies; 85+ messages in thread
From: Skip Tavakkolian @ 2021-08-18  7:02 UTC (permalink / raw)
  To: 9fans

I changed the Subject line to better reflect the discussion. Please do go on.

On Tue, Aug 17, 2021 at 8:57 PM Lucio De Re <lucio.dere@gmail.com> wrote:
>
> On 8/17/21, Keith Gibbs <k@pixelheresy.com> wrote:
> > One Plan Nine?
> >
> > Sure, we have the historical version of the Bell Labs/Lucient codebase,
> > preserved as 9legacy, but yeah we have one currently developed branch of
> > Plan 9 called 9front. Are you proposing that to be called “Plan 9 from Bell
> > Labs 5th edition”?
> >
> I bet you think I don't; you wouldn't ask, otherwise.
>
> > To be serious though, when has monolithic code bases ever benefited things
> > in an Open Source community?
>
> You bought the "exceptionalism" Kool-Aid, lock, stock and barrel,
> haven't you? It's a question of size: a small code base should remain
> small, then it is not weaponisable or monetisable. So we raise the bar
> higher and higher and shake off whatever can't stick hard enough. A
> human natural instinct (more!, gimme more! features! bugs! anything so
> I can have bigger, faster!) bent to the interest of elites (here in
> Africa we know it as the Big Man Syndrome).
>
> > I mean the only reason would be to control who
> > can/cannot make decisions on what goes in the stone soup.
> Do you have incontrovertible evidence? In my caffeine-deprived state,
> I feel you're just following the sheep gospel, no offence intended. In
> my opinion, the trap is always there, ready to be deployed. And the
> masses are always ready to fall into it. Occasionally a Christ figure
> comes along to warn us, but only the elite can understand the message
> and of course they then distort it in the direction that suits them
> best. And the masses are none the wiser, not this time, not the next
> time, not any other time, because the elite can be swapped out
> entirely and the new elite becomes them, ad nauseam.
>
> > There are multiple
> > BSDs. There are multiple Linuxes. Using 9legacy as more than historical
> > baseline means that we will be stuck with decisions put in place 20-30 years
> > ago rather than iterating and moving things forward. The purpose of P9F is
> > to “promote and support” not to regulate.
> >
> Sure, and an infinite variety of vehicles with wheels at the four
> corners and seats that just occupy space and consume carbon-based
> fuels. Even EVs where each wheel could be both motor and power
> generator have retained that ridiculous formula. But they look
> different (sort of, there's greater difference in time than there in
> style). Oh, let's not ignore that autos also sit idle (my estimate)
> 95% of their life: is that what they are designed for? And the AI in
> my phone, is that also sitting idle? I had a couple of instances
> recently where in the middle of the night my password locked Samsung
> J5 decided to continue reading me the SF short story collection I
> turned off before going to sleep.
>
> But Android is Open Source, isn't it? I can look under the bonned, can't I?
>
> Well, the P9F is what it is. It will also become what it is naturally
> attracted to unless some boundaries - Trump's fence? - are put in
> place.
>
> > I would love to imagine a time when we have a resurgence of multiple Plan
> > 9s. I would love to see Akaros and 9atom have a shot in the arm [although
> > much of what the latter had seems to be swallowed up by 9front and 9legacy
> > and the project dead]. I would love to see NIX get a little more traction,
> > as it seems it is just a standalone experiment [albeit a cool one in terms
> > of goals]. I think it would be really healthy for Jeanne and Harvey to be
> > more closer to “family” in the community rather than third cousins. Once we
> > have a plurality of opinions, of perspectives, of visions, then we can
> > better broker standards and overall trajectories.
> >
> I'm going to leave this here, with a comment to the effect that I
> totally disagree with the sentiments. There is room, need is not a
> strong enough word for what I'm thinking, for creativity, but software
> is not a primordial soup out of which complex organisms will rise to
> take over the Universe and consume it out of existence, its and
> theirs.
> 
> More likely, we'll teach - by example, not intentionally, no - our AI
> products to weaponise the tools we are no longer sufficiently
> naturally intelligent to understand and control (tell me there's a
> difference) and turn us into slaves because, like the human elite,
> they will measure their worth in what they can accumulate (human
> slaves sounds like a neat currency to me, I could use some, it's
> worked in all of human history - ask Epstein), just like their
> creators did.
> 
> Nothing to do with Plan 9, of course, because it really is just a drop
> of accidental sanity in an ocean of greed and competition. But, to
> complete the imagery, I'd rather be plankton in a drop of Plan 9 than
> a shark in the Linux Ocean. And I am, to the extent that I support and
> most of all appreciate what makes my ecosystem continue to tick.
> Including any contributions by like-minded or antagonistically natured
> geniuses.
> 
> Lucio.
> 
> PS: I have a lot of time to think and unfortunately not the means to
> study beyond a rather narrow subject matter. So my opinions are much
> more the result of introspection than of universal knowledge. Take it
> for what it is.
> 
> PPS: There is always an elite, its job is to defeat by all means
> available a middle class whose "elite nouveau" continually attempts to
> replace it, by any means available to it. Everything revolves around
> who owns the masses. That's Western Civilisation in a nutshell.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T9ef6430f3025e731-M0f059aee3b4cec23537306e8
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] Software philosophy
  2021-08-18  7:02       ` [9fans] Software philosophy Skip Tavakkolian
@ 2021-08-18  7:19         ` hiro
  2021-08-18 10:15           ` Lucio De Re
  2021-08-18  9:46         ` Keith Gibbs
                           ` (2 subsequent siblings)
  3 siblings, 1 reply; 85+ messages in thread
From: hiro @ 2021-08-18  7:19 UTC (permalink / raw)
  To: 9fans

is that my cue, are you calling in my services?!

On 8/18/21, Skip Tavakkolian <skip.tavakkolian@gmail.com> wrote:
> I changed the Subject line to better reflect the discussion. Please do go
> on.
>
> On Tue, Aug 17, 2021 at 8:57 PM Lucio De Re <lucio.dere@gmail.com> wrote:
>>
>> On 8/17/21, Keith Gibbs <k@pixelheresy.com> wrote:
>> > One Plan Nine?
>> >
>> > Sure, we have the historical version of the Bell Labs/Lucient codebase,
>> > preserved as 9legacy, but yeah we have one currently developed branch
>> > of
>> > Plan 9 called 9front. Are you proposing that to be called “Plan 9 from
>> > Bell
>> > Labs 5th edition”?
>> >
>> I bet you think I don't; you wouldn't ask, otherwise.
>>
>> > To be serious though, when has monolithic code bases ever benefited
>> > things
>> > in an Open Source community?
>>
>> You bought the "exceptionalism" Kool-Aid, lock, stock and barrel,
>> haven't you? It's a question of size: a small code base should remain
>> small, then it is not weaponisable or monetisable. So we raise the bar
>> higher and higher and shake off whatever can't stick hard enough. A
>> human natural instinct (more!, gimme more! features! bugs! anything so
>> I can have bigger, faster!) bent to the interest of elites (here in
>> Africa we know it as the Big Man Syndrome).
>>
>> > I mean the only reason would be to control who
>> > can/cannot make decisions on what goes in the stone soup.
>> Do you have incontrovertible evidence? In my caffeine-deprived state,
>> I feel you're just following the sheep gospel, no offence intended. In
>> my opinion, the trap is always there, ready to be deployed. And the
>> masses are always ready to fall into it. Occasionally a Christ figure
>> comes along to warn us, but only the elite can understand the message
>> and of course they then distort it in the direction that suits them
>> best. And the masses are none the wiser, not this time, not the next
>> time, not any other time, because the elite can be swapped out
>> entirely and the new elite becomes them, ad nauseam.
>>
>> > There are multiple
>> > BSDs. There are multiple Linuxes. Using 9legacy as more than historical
>> > baseline means that we will be stuck with decisions put in place 20-30
>> > years
>> > ago rather than iterating and moving things forward. The purpose of P9F
>> > is
>> > to “promote and support” not to regulate.
>> >
>> Sure, and an infinite variety of vehicles with wheels at the four
>> corners and seats that just occupy space and consume carbon-based
>> fuels. Even EVs where each wheel could be both motor and power
>> generator have retained that ridiculous formula. But they look
>> different (sort of, there's greater difference in time than there in
>> style). Oh, let's not ignore that autos also sit idle (my estimate)
>> 95% of their life: is that what they are designed for? And the AI in
>> my phone, is that also sitting idle? I had a couple of instances
>> recently where in the middle of the night my password locked Samsung
>> J5 decided to continue reading me the SF short story collection I
>> turned off before going to sleep.
>>
>> But Android is Open Source, isn't it? I can look under the bonned, can't
>> I?
>>
>> Well, the P9F is what it is. It will also become what it is naturally
>> attracted to unless some boundaries - Trump's fence? - are put in
>> place.
>>
>> > I would love to imagine a time when we have a resurgence of multiple
>> > Plan
>> > 9s. I would love to see Akaros and 9atom have a shot in the arm
>> > [although
>> > much of what the latter had seems to be swallowed up by 9front and
>> > 9legacy
>> > and the project dead]. I would love to see NIX get a little more
>> > traction,
>> > as it seems it is just a standalone experiment [albeit a cool one in
>> > terms
>> > of goals]. I think it would be really healthy for Jeanne and Harvey to
>> > be
>> > more closer to “family” in the community rather than third cousins. Once
>> > we
>> > have a plurality of opinions, of perspectives, of visions, then we can
>> > better broker standards and overall trajectories.
>> >
>> I'm going to leave this here, with a comment to the effect that I
>> totally disagree with the sentiments. There is room, need is not a
>> strong enough word for what I'm thinking, for creativity, but software
>> is not a primordial soup out of which complex organisms will rise to
>> take over the Universe and consume it out of existence, its and
>> theirs.
>>
>> More likely, we'll teach - by example, not intentionally, no - our AI
>> products to weaponise the tools we are no longer sufficiently
>> naturally intelligent to understand and control (tell me there's a
>> difference) and turn us into slaves because, like the human elite,
>> they will measure their worth in what they can accumulate (human
>> slaves sounds like a neat currency to me, I could use some, it's
>> worked in all of human history - ask Epstein), just like their
>> creators did.
>>
>> Nothing to do with Plan 9, of course, because it really is just a drop
>> of accidental sanity in an ocean of greed and competition. But, to
>> complete the imagery, I'd rather be plankton in a drop of Plan 9 than
>> a shark in the Linux Ocean. And I am, to the extent that I support and
>> most of all appreciate what makes my ecosystem continue to tick.
>> Including any contributions by like-minded or antagonistically natured
>> geniuses.
>>
>> Lucio.
>>
>> PS: I have a lot of time to think and unfortunately not the means to
>> study beyond a rather narrow subject matter. So my opinions are much
>> more the result of introspection than of universal knowledge. Take it
>> for what it is.
>>
>> PPS: There is always an elite, its job is to defeat by all means
>> available a middle class whose "elite nouveau" continually attempts to
>> replace it, by any means available to it. Everything revolves around
>> who owns the masses. That's Western Civilisation in a nutshell.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T9ef6430f3025e731-Mf3f14e2f3b04e34487a920b3
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] OAuth2 in factotum
  2021-08-18  3:55     ` Lucio De Re
  2021-08-18  7:02       ` [9fans] Software philosophy Skip Tavakkolian
@ 2021-08-18  9:18       ` Keith Gibbs
  2021-08-18 12:10         ` Ethan Gardener
  2021-08-18 15:23         ` Stuart Morrow
  1 sibling, 2 replies; 85+ messages in thread
From: Keith Gibbs @ 2021-08-18  9:18 UTC (permalink / raw)
  To: 9fans

[-- Attachment #1: Type: text/plain, Size: 13620 bytes --]

Lucio, man, you are a comic genius. 

> On 18. Aug 2021, at 6.55, Lucio De Re <lucio.dere@gmail.com> wrote:
> 
> You bought the "exceptionalism" Kool-Aid, lock, stock and barrel,
> haven't you? It's a question of size: a small code base should remain
> small, then it is not weaponisable or monetisable. So we raise the bar
> higher and higher and shake off whatever can't stick hard enough. A
> human natural instinct (more!, gimme more! features! bugs! anything so
> I can have bigger, faster!) bent to the interest of elites (here in
> Africa we know it as the Big Man Syndrome).

No. Instead, I argue (being involved in OSS and communities for nearly 25 years at this point), diversity builds strength. New tools are always good, especially when well made and optional. Drop in replacements to standard ones are amazing and push toward innovation. Overhauls of core functionality or extending even the kernel [although tricky at times] can lead to massive leaps in the usefulness of the system. How is Plan 9 different, now that it is open source and developed entirely by volunteers?

Linux is easy to point to for examples… Having mulitiple configuration/boot managers (init, systemd, uselessd, etc.) allows individual distributions (as well as users) make choices about ease vs. cleanliness, kitchen sink vs. sharp tool. It also puts accountability for the bigger one [systemd] not be as much of a bloated mess as it was a few years back, since more users = more distros = more people demanding it not to be an inefficient Rube Goldberg machine.

And tools die or are replaced over time.  8 1⁄2 was the standard in Plan 9, but due to it’s limitations and quirks, a new one was written from scratch. Now we, 30 years later, are arguing that every line of code handed down from our honoured and sainted forebears is gospel truth? Really? 

Even if we are looking at minimalism, we can have evolution, variety and change over time. Even beyond suckless.org <http://suckless.org/> “suckless” tools there are quite a few derivatives that operate on similar principals. There is a dmenu replacement (rofi) that is a little fatter than the base compile, but is actually a cleaner, tighter implementation if you typically run various patches and adding to dmenu. Is it better? Maybe. Its is less minimalist? Not if you frequently add other search patches to dmenu. Is it a choice? Sure. Will over time one win out over the other? Who knows. 

I think what you are confusing is that since I (and many others, whether on the 9front side or no) want to see Plan 9 evolve and grow, that somehow that will ruin *your* Plan 9. That is the same argument political conservatives make about all sorts of things about society. They fear change and fear that any growth, modification, or democratisation of these things will lead to corruption or degeneration [often seen as “degeneracy” in political/societal contexts]. Instead, I argue that you keep 9legacy or 9miller or whatever you *personally* feel is “pure” and godly enough and let people build this. Even in the thread you seem to articulate a tension between liking Demetrius’ cool work [or insistence on other people porting patches for 9legacy for you^H^H^Hthe community in the past] and wanting a definitive body for absolute blessing of features/code changes/etc. 

If Demetrius releases the Oath tool in it’s finished form in the near feature and it is awesome, need it being included in the default install of any Plan 9? Could be it a standalone package or patch for some and built into others? Also, what would it *mean* to have an approving body for One Plan 9. Does that mean that people like cinap, ori, or sigrid [who frequently contribute to 9front as well as releasing independent tools and software] are beholden to some committee decision? Do you understand how Open Source works?

Accusations of “exceptionalism” are completely unfounded, since I like the idea of people having preferences and different workflows. acme exists, so should we delete sam? No, cos sam is better for some things and for some people. Should someone rework sam to not have the annoying double snarf buffer thing [because, as I recall, Rob Pike wanted to hack around potential lag between the term and a remote sam instance and never went back to it]? I think probably. The only bias I have is toward newer code, to be honest. Not new features, but new takes. New fixes. New implementations that allow for flexibility of use that were most likely never conceived of initially. The Plan 9 team at Bell Labs (or Lucient) never had a problem monkeying with the guts of the OS [still sticking to their guns regarding minimalist design sensibilities], but now, for whatever reason, that needs to be tamped down or highly controlled?

Hell, there are cool things I wish were 9front [unless they were snuck in], like some of sigrid's keyboard system tweaks and theming hacks. Or mycroftiv’s extra namespace aliasing stuff from ANTS. 

> Do you have incontrovertible evidence? In my caffeine-deprived state,
> I feel you're just following the sheep gospel, no offence intended. In
> my opinion, the trap is always there, ready to be deployed. And the
> masses are always ready to fall into it. Occasionally a Christ figure
> comes along to warn us, but only the elite can understand the message
> and of course they then distort it in the direction that suits them
> best. And the masses are none the wiser, not this time, not the next
> time, not any other time, because the elite can be swapped out
> entirely and the new elite becomes them, ad nauseam.

Sheep gospel? As opposed to the goats being flung into Hell? Likely this phrase is more endemic to your lexical community, but as a native English speaker, it’s not clear, so I will first extrapolate what I *think* you mean by “sheep gospel” and refute.

It seems what you are critiquing [taking into consideration the prior paragraph you wrote] is that you are critical of my position because you feel that me (or others), in some sort of cargo cult mentality, are imposing some sort of outside hegemony of values [bigger, better, more corporate, more “user-friendly”, more commoditatizable]. This is opposed to the small purity of message of the insular community that exists for this clearly not mainstream, commodity OS. 

Ok. Weird. 

But then the idea is that I or others are putting ourselves as some elite? What? Not that you know or care, butI’m an anarcho-syndicalist, man. If me saying I want everyone to having their own power and everyone to have a voice and that divergent software is “voted upon” by use (rather than mandate by a person or a single committee) is somehow elitist and crypotfascist, well, I don’t know what to say. 

> Sure, and an infinite variety of vehicles with wheels at the four
> corners and seats that just occupy space and consume carbon-based
> fuels. Even EVs where each wheel could be both motor and power
> generator have retained that ridiculous formula. But they look
> different (sort of, there's greater difference in time than there in
> style). Oh, let's not ignore that autos also sit idle (my estimate)
> 95% of their life: is that what they are designed for? And the AI in
> my phone, is that also sitting idle? I had a couple of instances
> recently where in the middle of the night my password locked Samsung
> J5 decided to continue reading me the SF short story collection I
> turned off before going to sleep.

I am clearly lost here. Yes. There are cars. 

Not sure what your point is, Lucio, but I will use this as a teaching opportunity. 

Cars basically have to just replace horse-drawn wagons. Move people. Move stuff. Ride on roads. Over the years [excepting for government imposing certain health or safety regulations], the adaptations of the cars have been mostly to optimise performance, although a fair bit has also gone to luxury. Standardization between brands have been by convention/convenience/etc. not by a committee deciding things. Since it is a physical good, there are certain constraints less applicable than software and since they are commodity items, made for profit, they are other pressures. But in the end, it was not in the interest of anyone to have one standard. And standards that exist [fuel types, belt sizes, oil weights, ranges of tire sizes, etc.] are more like rough agreements to optimise variety with manufacturing costs. Too few options would railroad designs and applications, too many it would not be viable to manufacture.

Even when standards are set, but everyone is open to manufacture, use dictates success. Take the A cell battery. Or the B cell. You can probably source specialised ones somewhere, but AA and AAA were more useful for smaller devices and C & D for larger handheld devices that didn’t need high output [like a lantern battery].

Funny enough, cars *are* optimised for being idle. It takes a long time for a battery to go flat from being idle. The outside paint, trim, etc. is designed to last relatively well in a variety of climates so that they don’t always need to be garaged or in a car port. Defrosters/defoggers are there because it is understood the damn thing may be cold with a breathing person in it or be frozen over. It kicks on the AC as well, to pull moisture out of the air, even if it is warmed immediately after.

> But Android is Open Source, isn't it? I can look under the bonned, can't I?

Open Source and Android is debatable. Also Open Source depends on license. Android’s OS license is not a free license. Even Lucient’s license was pretty damn free and now it is MIT for Plan 9. We are at this point comparing apples to oranges.

> Well, the P9F is what it is. It will also become what it is naturally
> attracted to unless some boundaries - Trump's fence? - are put in
> place.

I argue that from their charter and description, they are there to promote the technology rather than impose a roadmap or gatekeep.

If more people discover Plan 9 and find X and Y distributions more useful than Z, then cool. 

I think part of that mission would be promoting diversity of multiple “Plan 9” OSes and derivatives. 

> I'm going to leave this here, with a comment to the effect that I
> totally disagree with the sentiments. There is room, need is not a
> strong enough word for what I'm thinking, for creativity, but software
> is not a primordial soup out of which complex organisms will rise to
> take over the Universe and consume it out of existence, its and
> theirs.

Yeah, it pretty much is, except you have humans with cool ideas directing it. And with that you promote the humans to do cool stuff with it as they please. Plan 9 has always been a playground for creating new things and questioning how we can do computing in better ways.

> More likely, we'll teach - by example, not intentionally, no - our AI
> products to weaponise the tools we are no longer sufficiently
> naturally intelligent to understand and control (tell me there's a
> difference) and turn us into slaves because, like the human elite,
> they will measure their worth in what they can accumulate (human
> slaves sounds like a neat currency to me, I could use some, it's
> worked in all of human history - ask Epstein), just like their
> creators did.

What?! How did you get here?! Epstein? Human slaves? 

> Nothing to do with Plan 9, of course, because it really is just a drop
> of accidental sanity in an ocean of greed and competition. But, to
> complete the imagery, I'd rather be plankton in a drop of Plan 9 than
> a shark in the Linux Ocean. And I am, to the extent that I support and
> most of all appreciate what makes my ecosystem continue to tick.
> Including any contributions by like-minded or antagonistically natured
> geniuses.

I instead see Plan 9 as something that can grow to be a mainline development platform for more users. Not for the masse, per se. 

It does have some promise for modern grid/distributed computing. Hell, much of what is in the Linux space in that regard was modelled after it [although implemented more hamfistedly]. 

I’m not some dumb kid. I am in my 40s and have been in software dev my entire adult life [and admittedly before that as well]. Even though Plan 9 as a legacy artefact handed down from Bell and Lucent is outdated, it has so much value [albeit it may be in limited scope compared to Linux, for example] that can be recovered. I think may of the people who are excited about it see the same thing. And for me, and may other peers here, railroading into a singular “official” manifestation will do more to stifle growth, experimentation and creativity than to enrich it.

Cheers,

-pixelheresy


> Lucio.
> 
> PS: I have a lot of time to think and unfortunately not the means to
> study beyond a rather narrow subject matter. So my opinions are much
> more the result of introspection than of universal knowledge. Take it
> for what it is.
> 
> PPS: There is always an elite, its job is to defeat by all means
> available a middle class whose "elite nouveau" continually attempts to
> replace it, by any means available to it. Everything revolves around
> who owns the masses. That's Western Civilisation in a nutshell.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T6899bf3f0654295d-M916eb14bfc08b38e33e93158
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 18001 bytes --]

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] Software philosophy
  2021-08-18  7:02       ` [9fans] Software philosophy Skip Tavakkolian
  2021-08-18  7:19         ` hiro
@ 2021-08-18  9:46         ` Keith Gibbs
  2021-08-18 10:13         ` vic.thacker
  2021-08-18 11:28         ` Lucio De Re
  3 siblings, 0 replies; 85+ messages in thread
From: Keith Gibbs @ 2021-08-18  9:46 UTC (permalink / raw)
  To: 9fans

Sorry for posting the other to the original title. Was authoring it prior to your subject change and sent it after. 

Will happily reply to this thread if it continues. 

But in the meantime, you can lock me in the stocks and throw fruit ;). 

-pixelheresy 

> On 18 Aug 2021, at 10:04, Skip Tavakkolian <skip.tavakkolian@gmail.com> wrote:
> 
> I changed the Subject line to better reflect the discussion. Please do go on.
> 
>> On Tue, Aug 17, 2021 at 8:57 PM Lucio De Re <lucio.dere@gmail.com> wrote:
>> 
>>> On 8/17/21, Keith Gibbs <k@pixelheresy.com> wrote:
>>> One Plan Nine?
>>> 
>>> Sure, we have the historical version of the Bell Labs/Lucient codebase,
>>> preserved as 9legacy, but yeah we have one currently developed branch of
>>> Plan 9 called 9front. Are you proposing that to be called “Plan 9 from Bell
>>> Labs 5th edition”?
>>> 
>> I bet you think I don't; you wouldn't ask, otherwise.
>> 
>>> To be serious though, when has monolithic code bases ever benefited things
>>> in an Open Source community?
>> 
>> You bought the "exceptionalism" Kool-Aid, lock, stock and barrel,
>> haven't you? It's a question of size: a small code base should remain
>> small, then it is not weaponisable or monetisable. So we raise the bar
>> higher and higher and shake off whatever can't stick hard enough. A
>> human natural instinct (more!, gimme more! features! bugs! anything so
>> I can have bigger, faster!) bent to the interest of elites (here in
>> Africa we know it as the Big Man Syndrome).
>> 
>>> I mean the only reason would be to control who
>>> can/cannot make decisions on what goes in the stone soup.
>> Do you have incontrovertible evidence? In my caffeine-deprived state,
>> I feel you're just following the sheep gospel, no offence intended. In
>> my opinion, the trap is always there, ready to be deployed. And the
>> masses are always ready to fall into it. Occasionally a Christ figure
>> comes along to warn us, but only the elite can understand the message
>> and of course they then distort it in the direction that suits them
>> best. And the masses are none the wiser, not this time, not the next
>> time, not any other time, because the elite can be swapped out
>> entirely and the new elite becomes them, ad nauseam.
>> 
>>> There are multiple
>>> BSDs. There are multiple Linuxes. Using 9legacy as more than historical
>>> baseline means that we will be stuck with decisions put in place 20-30 years
>>> ago rather than iterating and moving things forward. The purpose of P9F is
>>> to “promote and support” not to regulate.
>>> 
>> Sure, and an infinite variety of vehicles with wheels at the four
>> corners and seats that just occupy space and consume carbon-based
>> fuels. Even EVs where each wheel could be both motor and power
>> generator have retained that ridiculous formula. But they look
>> different (sort of, there's greater difference in time than there in
>> style). Oh, let's not ignore that autos also sit idle (my estimate)
>> 95% of their life: is that what they are designed for? And the AI in
>> my phone, is that also sitting idle? I had a couple of instances
>> recently where in the middle of the night my password locked Samsung
>> J5 decided to continue reading me the SF short story collection I
>> turned off before going to sleep.
>> 
>> But Android is Open Source, isn't it? I can look under the bonned, can't I?
>> 
>> Well, the P9F is what it is. It will also become what it is naturally
>> attracted to unless some boundaries - Trump's fence? - are put in
>> place.
>> 
>>> I would love to imagine a time when we have a resurgence of multiple Plan
>>> 9s. I would love to see Akaros and 9atom have a shot in the arm [although
>>> much of what the latter had seems to be swallowed up by 9front and 9legacy
>>> and the project dead]. I would love to see NIX get a little more traction,
>>> as it seems it is just a standalone experiment [albeit a cool one in terms
>>> of goals]. I think it would be really healthy for Jeanne and Harvey to be
>>> more closer to “family” in the community rather than third cousins. Once we
>>> have a plurality of opinions, of perspectives, of visions, then we can
>>> better broker standards and overall trajectories.
>>> 
>> I'm going to leave this here, with a comment to the effect that I
>> totally disagree with the sentiments. There is room, need is not a
>> strong enough word for what I'm thinking, for creativity, but software
>> is not a primordial soup out of which complex organisms will rise to
>> take over the Universe and consume it out of existence, its and
>> theirs.
>> 
>> More likely, we'll teach - by example, not intentionally, no - our AI
>> products to weaponise the tools we are no longer sufficiently
>> naturally intelligent to understand and control (tell me there's a
>> difference) and turn us into slaves because, like the human elite,
>> they will measure their worth in what they can accumulate (human
>> slaves sounds like a neat currency to me, I could use some, it's
>> worked in all of human history - ask Epstein), just like their
>> creators did.
>> 
>> Nothing to do with Plan 9, of course, because it really is just a drop
>> of accidental sanity in an ocean of greed and competition. But, to
>> complete the imagery, I'd rather be plankton in a drop of Plan 9 than
>> a shark in the Linux Ocean. And I am, to the extent that I support and
>> most of all appreciate what makes my ecosystem continue to tick.
>> Including any contributions by like-minded or antagonistically natured
>> geniuses.
>> 
>> Lucio.
>> 
>> PS: I have a lot of time to think and unfortunately not the means to
>> study beyond a rather narrow subject matter. So my opinions are much
>> more the result of introspection than of universal knowledge. Take it
>> for what it is.
>> 
>> PPS: There is always an elite, its job is to defeat by all means
>> available a middle class whose "elite nouveau" continually attempts to
>> replace it, by any means available to it. Everything revolves around
>> who owns the masses. That's Western Civilisation in a nutshell.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T9ef6430f3025e731-M4a968597111c3e59460aab42
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] Software philosophy
  2021-08-18  7:02       ` [9fans] Software philosophy Skip Tavakkolian
  2021-08-18  7:19         ` hiro
  2021-08-18  9:46         ` Keith Gibbs
@ 2021-08-18 10:13         ` vic.thacker
  2021-08-18 11:34           ` Keith Gibbs
  2021-08-18 11:34           ` [9fans] Software philosophy Lucio De Re
  2021-08-18 11:28         ` Lucio De Re
  3 siblings, 2 replies; 85+ messages in thread
From: vic.thacker @ 2021-08-18 10:13 UTC (permalink / raw)
  To: leimy2k via 9fans

Starting from a false premise does not help. 9front is not a development branch of Plan 9. Plan 9 is Plan 9. 9front is 9front. 9front is an open-source fork or derivation of Plan 9.  

Trying to make 9front the new and official Plan 9 does seem absurd. I'm not sure why there is a strong need for validation. 9front does not need official recognition. Let 9front be what it is. It can exist independent of the Plan 9 name. 

Sincerely,
Vester 

On Wed, Aug 18, 2021, at 16:02, Skip Tavakkolian wrote:
> I changed the Subject line to better reflect the discussion. Please do go on.
> 
> On Tue, Aug 17, 2021 at 8:57 PM Lucio De Re <lucio.dere@gmail.com> wrote:
> >
> > On 8/17/21, Keith Gibbs <k@pixelheresy.com> wrote:
> > > One Plan Nine?
> > >
> > > Sure, we have the historical version of the Bell Labs/Lucient codebase,
> > > preserved as 9legacy, but yeah we have one currently developed branch of
> > > Plan 9 called 9front. Are you proposing that to be called “Plan 9 from Bell
> > > Labs 5th edition”?
> > >
> > I bet you think I don't; you wouldn't ask, otherwise.
> >
> > > To be serious though, when has monolithic code bases ever benefited things
> > > in an Open Source community?
> >
> > You bought the "exceptionalism" Kool-Aid, lock, stock and barrel,
> > haven't you? It's a question of size: a small code base should remain
> > small, then it is not weaponisable or monetisable. So we raise the bar
> > higher and higher and shake off whatever can't stick hard enough. A
> > human natural instinct (more!, gimme more! features! bugs! anything so
> > I can have bigger, faster!) bent to the interest of elites (here in
> > Africa we know it as the Big Man Syndrome).
> >
> > > I mean the only reason would be to control who
> > > can/cannot make decisions on what goes in the stone soup.
> > Do you have incontrovertible evidence? In my caffeine-deprived state,
> > I feel you're just following the sheep gospel, no offence intended. In
> > my opinion, the trap is always there, ready to be deployed. And the
> > masses are always ready to fall into it. Occasionally a Christ figure
> > comes along to warn us, but only the elite can understand the message
> > and of course they then distort it in the direction that suits them
> > best. And the masses are none the wiser, not this time, not the next
> > time, not any other time, because the elite can be swapped out
> > entirely and the new elite becomes them, ad nauseam.
> >
> > > There are multiple
> > > BSDs. There are multiple Linuxes. Using 9legacy as more than historical
> > > baseline means that we will be stuck with decisions put in place 20-30 years
> > > ago rather than iterating and moving things forward. The purpose of P9F is
> > > to “promote and support” not to regulate.
> > >
> > Sure, and an infinite variety of vehicles with wheels at the four
> > corners and seats that just occupy space and consume carbon-based
> > fuels. Even EVs where each wheel could be both motor and power
> > generator have retained that ridiculous formula. But they look
> > different (sort of, there's greater difference in time than there in
> > style). Oh, let's not ignore that autos also sit idle (my estimate)
> > 95% of their life: is that what they are designed for? And the AI in
> > my phone, is that also sitting idle? I had a couple of instances
> > recently where in the middle of the night my password locked Samsung
> > J5 decided to continue reading me the SF short story collection I
> > turned off before going to sleep.
> >
> > But Android is Open Source, isn't it? I can look under the bonned, can't I?
> >
> > Well, the P9F is what it is. It will also become what it is naturally
> > attracted to unless some boundaries - Trump's fence? - are put in
> > place.
> >
> > > I would love to imagine a time when we have a resurgence of multiple Plan
> > > 9s. I would love to see Akaros and 9atom have a shot in the arm [although
> > > much of what the latter had seems to be swallowed up by 9front and 9legacy
> > > and the project dead]. I would love to see NIX get a little more traction,
> > > as it seems it is just a standalone experiment [albeit a cool one in terms
> > > of goals]. I think it would be really healthy for Jeanne and Harvey to be
> > > more closer to “family” in the community rather than third cousins. Once we
> > > have a plurality of opinions, of perspectives, of visions, then we can
> > > better broker standards and overall trajectories.
> > >
> > I'm going to leave this here, with a comment to the effect that I
> > totally disagree with the sentiments. There is room, need is not a
> > strong enough word for what I'm thinking, for creativity, but software
> > is not a primordial soup out of which complex organisms will rise to
> > take over the Universe and consume it out of existence, its and
> > theirs.
> > 
> > More likely, we'll teach - by example, not intentionally, no - our AI
> > products to weaponise the tools we are no longer sufficiently
> > naturally intelligent to understand and control (tell me there's a
> > difference) and turn us into slaves because, like the human elite,
> > they will measure their worth in what they can accumulate (human
> > slaves sounds like a neat currency to me, I could use some, it's
> > worked in all of human history - ask Epstein), just like their
> > creators did.
> > 
> > Nothing to do with Plan 9, of course, because it really is just a drop
> > of accidental sanity in an ocean of greed and competition. But, to
> > complete the imagery, I'd rather be plankton in a drop of Plan 9 than
> > a shark in the Linux Ocean. And I am, to the extent that I support and
> > most of all appreciate what makes my ecosystem continue to tick.
> > Including any contributions by like-minded or antagonistically natured
> > geniuses.
> > 
> > Lucio.
> > 
> > PS: I have a lot of time to think and unfortunately not the means to
> > study beyond a rather narrow subject matter. So my opinions are much
> > more the result of introspection than of universal knowledge. Take it
> > for what it is.
> > 
> > PPS: There is always an elite, its job is to defeat by all means
> > available a middle class whose "elite nouveau" continually attempts to
> > replace it, by any means available to it. Everything revolves around
> > who owns the masses. That's Western Civilisation in a nutshell.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T9ef6430f3025e731-M0ab0b4da1ef4a6a22a8dabd5
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] Software philosophy
  2021-08-18  7:19         ` hiro
@ 2021-08-18 10:15           ` Lucio De Re
  0 siblings, 0 replies; 85+ messages in thread
From: Lucio De Re @ 2021-08-18 10:15 UTC (permalink / raw)
  To: 9fans

On 8/18/21, hiro <23hiro@gmail.com> wrote:
> is that my cue, are you calling in my services?!
>
If you have any actual understanding of factotum, *I* could easily
gain from consulting such knowledge to scratch some of my immediate
itches, as I'm no expert and factotum is only slowly revealing its
secrets to me. Unfortunately, I have neither the time nor the money to
"call in your services".

If this is aimed at the P9F, I cannot possibly speak for them, I can
only hope that they share at least some of my own aims.

Lucio.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T9ef6430f3025e731-M655b399ffe88b07e7eeba62a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] Software philosophy
  2021-08-18  7:02       ` [9fans] Software philosophy Skip Tavakkolian
                           ` (2 preceding siblings ...)
  2021-08-18 10:13         ` vic.thacker
@ 2021-08-18 11:28         ` Lucio De Re
  2021-08-18 12:02           ` Keith Gibbs
  3 siblings, 1 reply; 85+ messages in thread
From: Lucio De Re @ 2021-08-18 11:28 UTC (permalink / raw)
  To: 9fans

On 8/18/21, Skip Tavakkolian <skip.tavakkolian@gmail.com> wrote:
> I changed the Subject line to better reflect the discussion. Please do go
> on.
>
Let me put it this way: German and Italian motorcycle manufacturers
eventually figured that the gear shift should be on the same side as
Japanese manufacturers preferred.

What I am proposing is that where some code will run on one flavour of
Plan 9 and not on another, which is annoying, that somebody be
entrusted with the common sense to suggest which of two
implementations should be favoured and for what reasons.

It seems to me that the paranoid individualist assumes malice behind
such an obvious proposal.

Lucio.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T9ef6430f3025e731-M23c61c84f53dede4954ace32
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] Software philosophy
  2021-08-18 10:13         ` vic.thacker
@ 2021-08-18 11:34           ` Keith Gibbs
  2021-08-18 11:47             ` Lucio De Re
  2021-08-18 23:44             ` hiro
  2021-08-18 11:34           ` [9fans] Software philosophy Lucio De Re
  1 sibling, 2 replies; 85+ messages in thread
From: Keith Gibbs @ 2021-08-18 11:34 UTC (permalink / raw)
  To: 9fans

[-- Attachment #1: Type: text/plain, Size: 3775 bytes --]

Come, come, Vester. Please don’t introduce false premises under the guise of calling them out. I never said that. 9front as the official Plan 9 would be pretty absurd.

I never said it was *the* development branch. It is *a* development branch. I could even imagine that it may in fact be the most popular and active for those wishing to develop new software on (with 9miller being very popular as well). 

If fact, I noted other projects... other Plan 9s as well in my initial and my response to Lucio. I was merely pointing out that Lucio in the past and in the OAuth thread keeps introducing the idea that the P9F should impose order and wall off everything but 9legacy [which he implies is the official one], even to the point of arguing in the past that 9front developers should port changes that are “good for the community” or some such to the “actual” Plan 9. 

Instea the charter for P9F's language was written to be inclusive. Why? Because historically this mailing list/community has been host to discussion for 9legacy, 9atom, 9front, p9p, etc. Even Inferno or Harvey come up semi-regularly. As such, it is not outside the general understanding of “Plan 9” as encompassing a wider berth. Although many of the P9F folk are contributors to 9legacy, I think they know that the community is broader and want all of it to be “Plan 9”.

So in the end, I apologise if it was unclear or confusing that I suggested to Lucio that 9front was to be "Plan 9 from Bell Labs Version 5”. It was a joke and everything I wrote following that should have made that very clear that I was arguing *specifically* for a plurality of Plan 9s rather than a single one [which Lucio was advocating for]. Lucio seems to hate 9front specifically for some reason, so the initial statement was intended as tongue in cheek.

Both 9legacy and 9front serve important niche functions within Plan 9 space, but neither *are* Plan 9. There is only one “official” Plan 9 and that was last updated January 2015. 9legacy positions itself as patch set on top of V4, but wants to maintain it in such a way that V4 will always function as V4. 9legacy maintains that it is not a fork. 9front says explicitly that it is a fork of V4 and a continuation based on it’s core principles. Both have fed into each other’s ecosystems. Hell, 9legacy’s site even says to run Plan 9 from Bell Labs rather than 9legacy if possible, which is kind of funny. And NIX is still active, last I heard, but currently has a closed community, not to mention Harvey and Jeanne.

So my main point was that we have a plurality and we *should* continue to have a plurality. Much like Lucio would find 9front as being blessed as “the official one true Plan 9” repugnant, so too would others re: 9legacy. A fair swathe of the Plan 9 enthusiast community want to build and evolve and a fair swathe want to preserve and maintain, with some incremental quality of life tweaks added in, and *both are totally valid*.

-pixelheresy

> On 18. Aug 2021, at 13.13, vic.thacker@fastmail.fm wrote:
> 
> Starting from a false premise does not help. 9front is not a development branch of Plan 9. Plan 9 is Plan 9. 9front is 9front. 9front is an open-source fork or derivation of Plan 9.  
> 
> Trying to make 9front the new and official Plan 9 does seem absurd. I'm not sure why there is a strong need for validation. 9front does not need official recognition. Let 9front be what it is. It can exist independent of the Plan 9 name. 
> 
> Sincerely,
> Vester 
> 

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T9ef6430f3025e731-M381a2c5d54ec68175eb453d4
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 9096 bytes --]

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] Software philosophy
  2021-08-18 10:13         ` vic.thacker
  2021-08-18 11:34           ` Keith Gibbs
@ 2021-08-18 11:34           ` Lucio De Re
  1 sibling, 0 replies; 85+ messages in thread
From: Lucio De Re @ 2021-08-18 11:34 UTC (permalink / raw)
  To: 9fans

On 8/18/21, vic.thacker@fastmail.fm <vic.thacker@fastmail.fm> wrote:
> Trying to make 9front the new and official Plan 9 does seem absurd. I'm not
> sure why there is a strong need for validation. 9front does not need
> official recognition. Let 9front be what it is. It can exist independent of
> the Plan 9 name.
>
The exact phrasing may not be my choice, but broadly I agree with that
sentiment. Where incompatibilities exist, they can be worked around,
but only if cooperation and not competition is the approach.

And if cooperation is the approach, then minimising incompatibilities
will be one common objective.

Lucio.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T9ef6430f3025e731-M27deaa7047f5187005d97c77
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] Software philosophy
  2021-08-18 11:34           ` Keith Gibbs
@ 2021-08-18 11:47             ` Lucio De Re
  2021-08-18 23:44             ` hiro
  1 sibling, 0 replies; 85+ messages in thread
From: Lucio De Re @ 2021-08-18 11:47 UTC (permalink / raw)
  To: 9fans

Yoh!

What can I say?

I kind of cherish being so wildly misrepresented. At least I'm taken
seriously, even if totally misunderstood.

Lucio.

On 8/18/21, Keith Gibbs <k@pixelheresy.com> wrote:
> Come, come, Vester. Please don’t introduce false premises under the guise of
> calling them out. I never said that. 9front as the official Plan 9 would be
> pretty absurd.
>
> I never said it was *the* development branch. It is *a* development branch.
> I could even imagine that it may in fact be the most popular and active for
> those wishing to develop new software on (with 9miller being very popular as
> well).
>
> If fact, I noted other projects... other Plan 9s as well in my initial and
> my response to Lucio. I was merely pointing out that Lucio in the past and
> in the OAuth thread keeps introducing the idea that the P9F should impose
> order and wall off everything but 9legacy [which he implies is the official
> one], even to the point of arguing in the past that 9front developers should
> port changes that are “good for the community” or some such to the “actual”
> Plan 9.
>
> Instea the charter for P9F's language was written to be inclusive. Why?
> Because historically this mailing list/community has been host to discussion
> for 9legacy, 9atom, 9front, p9p, etc. Even Inferno or Harvey come up
> semi-regularly. As such, it is not outside the general understanding of
> “Plan 9” as encompassing a wider berth. Although many of the P9F folk are
> contributors to 9legacy, I think they know that the community is broader and
> want all of it to be “Plan 9”.
>
> So in the end, I apologise if it was unclear or confusing that I suggested
> to Lucio that 9front was to be "Plan 9 from Bell Labs Version 5”. It was a
> joke and everything I wrote following that should have made that very clear
> that I was arguing *specifically* for a plurality of Plan 9s rather than a
> single one [which Lucio was advocating for]. Lucio seems to hate 9front
> specifically for some reason, so the initial statement was intended as
> tongue in cheek.
>
> Both 9legacy and 9front serve important niche functions within Plan 9 space,
> but neither *are* Plan 9. There is only one “official” Plan 9 and that was
> last updated January 2015. 9legacy positions itself as patch set on top of
> V4, but wants to maintain it in such a way that V4 will always function as
> V4. 9legacy maintains that it is not a fork. 9front says explicitly that it
> is a fork of V4 and a continuation based on it’s core principles. Both have
> fed into each other’s ecosystems. Hell, 9legacy’s site even says to run Plan
> 9 from Bell Labs rather than 9legacy if possible, which is kind of funny.
> And NIX is still active, last I heard, but currently has a closed community,
> not to mention Harvey and Jeanne.
>
> So my main point was that we have a plurality and we *should* continue to
> have a plurality. Much like Lucio would find 9front as being blessed as “the
> official one true Plan 9” repugnant, so too would others re: 9legacy. A fair
> swathe of the Plan 9 enthusiast community want to build and evolve and a
> fair swathe want to preserve and maintain, with some incremental quality of
> life tweaks added in, and *both are totally valid*.
>
> -pixelheresy
>
>> On 18. Aug 2021, at 13.13, vic.thacker@fastmail.fm wrote:
>>
>> Starting from a false premise does not help. 9front is not a development
>> branch of Plan 9. Plan 9 is Plan 9. 9front is 9front. 9front is an
>> open-source fork or derivation of Plan 9.
>>
>> Trying to make 9front the new and official Plan 9 does seem absurd. I'm
>> not sure why there is a strong need for validation. 9front does not need
>> official recognition. Let 9front be what it is. It can exist independent
>> of the Plan 9 name.
>>
>> Sincerely,
>> Vester
>>


-- 
Lucio De Re
2 Piet Retief St
Kestell (Eastern Free State)
9860 South Africa

Ph.: +27 58 653 1433
Cell: +27 83 251 5824

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T9ef6430f3025e731-M0953d9d310af6d87fb35fcff
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] Software philosophy
  2021-08-18 11:28         ` Lucio De Re
@ 2021-08-18 12:02           ` Keith Gibbs
  2021-08-18 19:33             ` leimy2k via 9fans
  0 siblings, 1 reply; 85+ messages in thread
From: Keith Gibbs @ 2021-08-18 12:02 UTC (permalink / raw)
  To: 9fans



> On 18. Aug 2021, at 14.28, Lucio De Re <lucio.dere@gmail.com> wrote:
> Let me put it this way: German and Italian motorcycle manufacturers
> eventually figured that the gear shift should be on the same side as
> Japanese manufacturers preferred.

This is my point exactly in one sense. In your example, there were alternate designs, and the German and Italian manufacturers conformed to the Japanese ones not by the Motorcycle Gearshift Foundation (MGF) sounding off on it or imposing a design for a “One Motorcycle Gearshift” [1MG] initiative. Instead, the experience of users and/or the better ergonomics of the design and/or functional logic dictated it was easier to just make them the same. 

Thought exercise: Fast forward 5 years from now… the NIX project delivers on a new version of the Plan 9 kernel that is brilliantly optimised for multicore/multinode distributed computing. Within a few weeks, 9front says, “this is the dopest thing ever” and folds it into their fork, along with some monkeying they have done to the kernel. Both get a shot in popularity and draw additional people into the Plan 9 community space. People develop software with this set of features in mind.

Let’s even say that the P9F takes leave of their senses and dictates a new Plan 9 from Bell Labs V5, which is basically 9legacy with standard patches and a version number. Great. Would “official” Plan 9 want to take in the cool addition to be more compatible with closely related peers or would people balk about the other distress “not contributing to common cross-compatibility” and come up with it’s own thing and stick to their own thing. I would venture the former would happen for the same reason in your motorcycle example. 

> What I am proposing is that where some code will run on one flavour of
> Plan 9 and not on another, which is annoying, that somebody be
> entrusted with the common sense to suggest which of two
> implementations should be favoured and for what reasons.

In the case of plurality, you have a push and pull, where people may intentionally make a departure from compatibility for the sake of bettering things. That is a risk, sure, but that is where you get growth. And if it is the best, since it is free and open source, the better code can be worked into sister projects. It’s like when there is a win, everyone can win. And mind you, most software is more about different tastes, workflows, etc. and don’t affect capital C “Compatibility”.

Similarly, a breaking change could be a problem and could even harm a project in the long term. That is where the risk comes in. 

> It seems to me that the paranoid individualist assumes malice behind
> such an obvious proposal.

I’m not sure malice is the right word. It is “motive”. It is clear you don’t like 9front as a distribution. That is your choice. But this isn’t the first time you have either directly or indirectly brought up the desire to propose that there should be a single Plan 9 and that what is official is dictated by editorial decision by a governing body. 

We obviously have very different views on top down vs bottom up development. However, most OSS development comes from a volunteer putting out a pull request that he or she things would make things better or a little standalone tool that people could find useful. The absense of authority, even in your motorcycle example, is not chaos. We have a community with some very smart and talented people. 

-pixelheresy

> Lucio.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T9ef6430f3025e731-Mdec4678ae5d02a14e4d6de91
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] OAuth2 in factotum
  2021-08-18  9:18       ` [9fans] OAuth2 in factotum Keith Gibbs
@ 2021-08-18 12:10         ` Ethan Gardener
  2021-08-18 15:23         ` Stuart Morrow
  1 sibling, 0 replies; 85+ messages in thread
From: Ethan Gardener @ 2021-08-18 12:10 UTC (permalink / raw)
  To: 9fans

[-- Attachment #1: Type: text/plain, Size: 2648 bytes --]

On Wed, Aug 18, 2021, at 10:18 AM, Keith Gibbs wrote:
> 
> And tools die or are replaced over time.  8 1⁄2 was the standard in Plan 9, but due to it’s limitations and quirks, a new one was written from scratch. Now we, 30 years later, are arguing that every line of code handed down from our honoured and sainted forebears is gospel truth? Really? 

Oh dear! This old argument is getting heated again? I don't miss the old flame wars.  But I think the old wars had a somewhat different motive.  Some people argued furiously for the "One True Plan 9" and against forks, but as soon as the last Plan 9 maintainer left the remains of Bell Labs, most of them just stopped posting.  (So did some nicer people.)  They were evidently arguing for a maintained system, but they also seemed to be opposed to almost all change.  Perhaps they were opposed to all change which didn't suit themselves, but the more I recall, the less rational these people seem to be.  Sometimes, they'd even be furious with someone for doing the very thing they'd told him to do.  "If you want it, do it yourself," so the person would put a lot of effort in to do it, and then they'd be furious with him.  The earliest such incident I know of goes back to the very people who developed Plan 9.  With this history, I don't particularly want to honor the original Plan 9 and would hate to see the wars rekindled.

All the same, there is a surprising practical consideration:

> I think what you are confusing is that since I (and many others, whether on the 9front side or no) want to see Plan 9 evolve and grow, that somehow that will ruin *your* Plan 9.

Unfortunately, this is a more difficult issue than you might think.  If someone is reliant on a particular fork and doesn't have the time, energy, or skills to make alterations as needed, they can be hurt by changes, even surprisingly small changes.  Changing Rio's scrolling behaviour might be trivial, but at a time when I was heavily dependent on a particular scrolling behaviour, 9front changed it and I had no free time or energy to even think about how to change it back.  I switched to an older version of Rio, but then I missed a different fix 9front had made.

The more I think about it, the more I think I'd like 9legacy's approach of patches over a relatively static system, but I haven't actually tried it and I certainly wouldn't want to limit anyone else's choices.
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T6899bf3f0654295d-M284a39c35a7dc1abec2c8cb8
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 4045 bytes --]

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] OAuth2 in factotum
  2021-08-18  9:18       ` [9fans] OAuth2 in factotum Keith Gibbs
  2021-08-18 12:10         ` Ethan Gardener
@ 2021-08-18 15:23         ` Stuart Morrow
  2021-08-18 16:58           ` Stuart Morrow
  1 sibling, 1 reply; 85+ messages in thread
From: Stuart Morrow @ 2021-08-18 15:23 UTC (permalink / raw)
  To: 9fans

On 18/08/2021, Keith Gibbs <k@pixelheresy.com> wrote:
> Hell, there are cool things I wish were 9front [unless they were snuck in],
> like some of sigrid's keyboard system tweaks and theming hacks.

No. The base system would then have two completely different ways to set font.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T6899bf3f0654295d-M202bed62fdeef4425950107f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] OAuth2 in factotum
  2021-08-18 15:23         ` Stuart Morrow
@ 2021-08-18 16:58           ` Stuart Morrow
  2021-08-18 17:06             ` Sigrid Solveig Haflínudóttir
  0 siblings, 1 reply; 85+ messages in thread
From: Stuart Morrow @ 2021-08-18 16:58 UTC (permalink / raw)
  To: 9fans

> No. The base system would then have two completely different ways to set font.

Although looking up the font is pretty centralised (in initdraw) so
who actually cares what the specific mechanism is.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T6899bf3f0654295d-Me6ad8e3db1270a4b24e18f72
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] OAuth2 in factotum
  2021-08-18 16:58           ` Stuart Morrow
@ 2021-08-18 17:06             ` Sigrid Solveig Haflínudóttir
  0 siblings, 0 replies; 85+ messages in thread
From: Sigrid Solveig Haflínudóttir @ 2021-08-18 17:06 UTC (permalink / raw)
  To: 9fans

Quoth Stuart Morrow <morrow.stuart@gmail.com>:
> > No. The base system would then have two completely different ways to set font.
> 
> Although looking up the font is pretty centralised (in initdraw) so
> who actually cares what the specific mechanism is.

My theming hacks do nothing about fonts.  VGA is the only official
font officially approved by the official 9front foundation, anyway.


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T6899bf3f0654295d-M4a168306129f9c950ec27764
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] Software philosophy
  2021-08-18 12:02           ` Keith Gibbs
@ 2021-08-18 19:33             ` leimy2k via 9fans
  2021-08-18 20:09               ` David du Colombier
  0 siblings, 1 reply; 85+ messages in thread
From: leimy2k via 9fans @ 2021-08-18 19:33 UTC (permalink / raw)
  To: 9fans

[-- Attachment #1: Type: text/plain, Size: 880 bytes --]


I don’t think the basic philosophy of Plan 9 and 9front really differ that much or in any deeply meaningful ways. I find 9front more usable for my needs. Sshnet works well, as does sshfs, and the smaller changes to the behaviors of Sam, rio RC shell windows etc (ctrl-b especially) seem to make a rather big difference to usability. Should there be an “upstream” relationship here? I honestly can’t tell.

The confluence of the forks isn’t clear, and flow depends on where one stands it seems.

The only negative outcome of forking is if we get to the point we can no longer share I think. Some investment in compatibility seems wise.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T9ef6430f3025e731-Mdf57cc50805611bffb0c569b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 1478 bytes --]

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] Software philosophy
  2021-08-18 19:33             ` leimy2k via 9fans
@ 2021-08-18 20:09               ` David du Colombier
  2021-08-18 22:00                 ` Eli Cohen
  0 siblings, 1 reply; 85+ messages in thread
From: David du Colombier @ 2021-08-18 20:09 UTC (permalink / raw)
  To: 9fans

Here are some clarifications.

9legacy used to be a an experimental patch queue for
Plan 9 from Bell Labs, providing patches that were not
yet accepted into the mainline distribution. That's why
we didn't recommend to use 9legacy, unless you had
specific needs.

However, this isn't really the case since 2015, because
Plan 9 from Bell Labs is not maintained anymore
(last release was 2015-01-10).

Today, 9legacy is more of a continuation of Plan 9 from Bell Labs.
There are still experimental patches, but also a lot of fixes and
improvements that would probably be part of Plan 9 from Bell Labs
if it was still maintained.

Also, NIX is not maintained anymore. However, there are
some other variants of 9k (the 64-bit Plan 9 kernel), including
the one available as part of 9legacy, that are still in progress.

-- 
David du Colombier

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T9ef6430f3025e731-Mc9a3f2e566a1033cb9d790de
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] Software philosophy
  2021-08-18 20:09               ` David du Colombier
@ 2021-08-18 22:00                 ` Eli Cohen
  2021-08-19  7:08                   ` Keith Gibbs
  2021-08-22  2:46                   ` kokamoto
  0 siblings, 2 replies; 85+ messages in thread
From: Eli Cohen @ 2021-08-18 22:00 UTC (permalink / raw)
  To: 9fans

what is all the friction actually about here?? the most important
philosophical question always ends up the same, how can we figure out
a good formula for not being jerks?

I have ended up using 9front more and more, obviously. 9front was
started specifically to address the fact that Plan 9 from Bell Labs
didn't run on most computers... If I have any feeling at all about it,
it's that there's room for another fork that is an even simpler
research platform. in other discussions people say, why do we have
things that aren't relevant? We all love catclock, email... some users
may only want plan 9 for that... some people also discussed even
removing compiled binaries as much as possible. mostly, I like the
idea of plan 9 that runs on the computer I have... but I understand
that for a lot of reasons other people don't necessarily feel the same
way.

we wouldn't be here if we didn't agree Plan 9 is the best OS design.
and they're all free software. 9front has some very interesting things
that 9legacy can (and does) use as patches. it's just actually
difficult to write software, for some value of difficulty.

there's a lot of shit going on in the world today... we all gathered
here to agree Plan 9 is great software, then just be rude to each
other because...? I really don't understand, I'm not exaggerating.
what is the actual disagreement here?

On Wed, Aug 18, 2021 at 1:12 PM David du Colombier <0intro@gmail.com> wrote:
> 
> Here are some clarifications.
> 
> 9legacy used to be a an experimental patch queue for
> Plan 9 from Bell Labs, providing patches that were not
> yet accepted into the mainline distribution. That's why
> we didn't recommend to use 9legacy, unless you had
> specific needs.
> 
> However, this isn't really the case since 2015, because
> Plan 9 from Bell Labs is not maintained anymore
> (last release was 2015-01-10).
> 
> Today, 9legacy is more of a continuation of Plan 9 from Bell Labs.
> There are still experimental patches, but also a lot of fixes and
> improvements that would probably be part of Plan 9 from Bell Labs
> if it was still maintained.
> 
> Also, NIX is not maintained anymore. However, there are
> some other variants of 9k (the 64-bit Plan 9 kernel), including
> the one available as part of 9legacy, that are still in progress.
> 
> --
> David du Colombier

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T9ef6430f3025e731-Me55ae2eef0de0a39ecd205ad
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] Software philosophy
  2021-08-18 11:34           ` Keith Gibbs
  2021-08-18 11:47             ` Lucio De Re
@ 2021-08-18 23:44             ` hiro
  2021-08-19  4:34               ` Lucio De Re
  1 sibling, 1 reply; 85+ messages in thread
From: hiro @ 2021-08-18 23:44 UTC (permalink / raw)
  To: 9fans

> I never said it was *the* development branch.

lol

but it is.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T9ef6430f3025e731-Mf113b7df339ddd9e3ca6e523
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] OAuth2 in factotum
  2021-08-16 11:15 [9fans] OAuth2 in factotum Demetrius Iatrakis
  2021-08-17  3:48 ` Lucio De Re
  2021-08-17  4:13 ` ori
@ 2021-08-19  3:52 ` Kurt H Maier
  2021-08-19  5:38 ` ori
  2021-08-22 20:16 ` ori
  4 siblings, 0 replies; 85+ messages in thread
From: Kurt H Maier @ 2021-08-19  3:52 UTC (permalink / raw)
  To: 9fans

On Mon, Aug 16, 2021 at 02:15:00PM +0300, Demetrius Iatrakis wrote:
> This is a preview of OAuth2 support in factotum, as part of this year's GSoC:
> https://github.com/Mitsos101/plan9front/pull/1
> 
> Installation, on 9front:
> 
> git/clone https://github.com/Mitsos101/plan9front plan9front-oauth
> cd plan9front-oauth
> git/branch oauth
> bind sys/include /sys/include
> @{cd sys/src/libauth && mk install}
> @{cd sys/src/cmd/auth && mk install}
> @{cd sys/src/cmd/webfs && mk install}

Works on my machine!  Have you been using it in the wild at all?  I'm
just testing it against a local set of toy programs, but it's working.

Thanks for working on this!

khm

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T6899bf3f0654295d-Mf49b1642e0de517409cc600b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] Software philosophy
  2021-08-18 23:44             ` hiro
@ 2021-08-19  4:34               ` Lucio De Re
  2021-08-19 10:44                 ` Keith Gibbs
  2021-08-19 18:53                 ` Git & Conventional Browsers (Was Re: [9fans] Software philosophy) unobe
  0 siblings, 2 replies; 85+ messages in thread
From: Lucio De Re @ 2021-08-19  4:34 UTC (permalink / raw)
  To: 9fans

On 8/19/21, hiro <23hiro@gmail.com> wrote:
>> I never said it was *the* development branch.
>
> lol
>
> but it is.
>
Correct. On two fronts, to coin a phrase. It is active and it is well supported.

It is the pragmatic end of the Plan 9 spectrum, courtesy of Cinap who
clearly would be a Torvalds if Plan 9 had gained the traction of
Linux.

We are all lucky, in a somewhat masochistic sense, that Cinap is not
Torvalds and Plan 9 came a little late on the scene and was "licenced
to kill" itself. Wrong generation, that was, but for those who want
everything and the kitchen sink, Linux is by far more convenient: I am
typing this into Gmail's "basic HTML" in an obsolete and unsupported
version of 32-bit Chromium under Linux Mint. I guess it IS my
preference, even though I greatly regret that there aren't enough
seconds left in my universe to migrate everything I can to my Plan 9
network.

Which, given that this is a "philosophy" thread and both Rob and Russ
are on board at least occasionally, may entitle me to ask: my
understanding is that both R&R use P9P under a version of MacOS "du
jour". I rely on P9P to relieve some of my frustrations with Linux
(and there are hundreds, some go back to my NetBSD days) and in some
crazy way I would tolerate logging in to Rio and I am totally sold on
acme as my editor from my remote workstation to a suitably tweaked
development server 300km away (ssh -fX...). Hell, this saved my bacon
recently after a serious outage: "ssh -fX devbox acme -l acme.dump".
How do I reward R&R for their efforts? And what have they neglected to
contribute to the mental health of suffering people like me in the
last few years :-) ?

In any case, the point is not where I am, but where I come from and
where I wish to be.

I don't run Windows on my premises in any size or shape. I'll probably
regret dropping it from my (cheap, non-plan 9-compatible) HP laptop on
my most recent Linux Mint upgrade, but I have learnt what I can do
with GPT and it doesn't bug me in the least to run Windows on a USB-3
connection to my drive (haven't needed to do that, yet, I may have to
eat these words).

I don't want to run Linux, either, in principle. Now that I have to
think about it, I might not mind using Linux as a hypervisor and
everything else under KVM, but for now the only hardware I own that
supports Qemu-KVM is what I use for the Fossil/CPU server. If I can't
see Linux, I can deal with it. One way or another, though, Linux has
the ability to remind one frequently that it is in charge, in a manner
neither NetBSD nor Plan 9 do.

I don't see how I can create the seamless environment I seek by
glueing together divergent systems such as 9front, 9legacy (my kernel
I label 9miller, a version configured for my server and workstation,
32-bit X86 even though the server is the most advanced platform in my
network, short of my Samsung phone), P9P under NetBSD
(acme-over-remote-X works fine there, too) if these extremely
preferable platforms (and I excluded P9P under Linux, but in fact that
remains the main option, like right now, it's just the least
preferable) continue to diverge, nay, are encouraged to diverge.

And of course, the scarier possibility is that one or more of my
essential ingredients will slip beyond my equipment's ability to run
it. Already, Linux Mint 20.2 with Skype and Chrome is too much for
2GiB of memory in my laptop and I don't have the income that allows me
to keep up with hardware advances.

In summary, I am entirely contrary in attitude to Keith, because my
interest lies in smaller, not bigger (I keep hoping I can afford a
recent rPi model, but I can't entirely justify that, yet).

Another way to get my point across may be to point out that I have no
issue with improvements to Plan 9. Its philosophy is sound and
palatable, much more so than the monstrosities of Windows and Linux
that no sane individual should willingly enslave oneself to. Windows
is still extremely insecure and not even slightly open to a security
audit, although I bet the NSA has no qualms exploiting what the see as
security "features" from the comfort of a source licence paid for by
the U.S.'s subjects; Linux is bloated beyond comprehension and I'm
also not impressed with the OSS's approach to software quality.

But divergence is in no manner "improvement", it needs to be
negotiated back into the "core values". I appreciate that there are
various costs associated with such "upstreaming" and that is why I'm
suggesting that the P9F should take it on, identify the costs and also
arbitrate, from a position of common wisdom, what is "core" and what
is tangential. Note that "core" then becomes a future entity, not a
past one, in this case.

Note: 9fronters may well believe that outsiders refuse to grant them
an identity they feel they have worked hard at earning. What they seem
to miss that even though there may actually be an "inside", the
outside is not the homogenous enemy they paint us as. Interestingly,
what made 9front the success story it is - and Plan 9 the orphan OS -
is precisely that "inside". I see the same happening here in South
Africa with factionalism and in the U.S. with the various nationalist
movements. It is clearly a very powerful human emotion.

A transparent history of decisions in this matter would prevent losing
any interesting proposals - yes, we need better than Git, but Git is
painfully "enough" to start with, even if as I get more familiar with
Git I'm starting to believe, hopefully wrongly, that Plan 9 may have
to bend towards supporting symbolic links to deal with it if it is
going to be a long run - and will raise a chuckle or two when future
archeologists come across it. I doubt they'll be able to do any more
than raise eyebrows when they try that with Linux.

One last, not quite related matter: Plan 9 seems limited never to
provide a conventional browsing experience for its audience. What does
that actually say about Plan 9's future?

That incidentally, must be qualified by the reality that NetBSD
doesn't fare much better: I have certainly not had the stomach to
migrate my workstation  from Linux to NetBSD - even less so my laptop
- precisely because even Chromium isn't "du jour" enough for the real
world.

Lucio.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T9ef6430f3025e731-Mb4d30b419265a251efc01435
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] OAuth2 in factotum
  2021-08-16 11:15 [9fans] OAuth2 in factotum Demetrius Iatrakis
                   ` (2 preceding siblings ...)
  2021-08-19  3:52 ` Kurt H Maier
@ 2021-08-19  5:38 ` ori
  2021-08-22 20:16 ` ori
  4 siblings, 0 replies; 85+ messages in thread
From: ori @ 2021-08-19  5:38 UTC (permalink / raw)
  To: 9fans

Quoth Demetrius Iatrakis <demetrius.iatrakis@gmail.com>:
> Only the device and refresh flows are supported. There is an
> implementation of the authorization code flow (tested on macOS) here:
> https://github.com/Mitsos101/plan9port/pull/1. However, it is not
> included in the module as there is no good browser to plumb the URL
> to.

Thinking about this a bit more, maybe the right option
is to just push this *all* the way to the unix side,
rather than trying to awkwardly straddle the gap:

        ssh ori@unix oauth-login client_id=1234 | ipso -r

and then just relying on the refresh flow on plan9.

If unix is going to be involved one way or the other,
it seems like it may be best to follow that to the
logical conclusion, and leave all of the initial
token fetch live there, then let the refresh happen
within plan 9.

Also, I'm currently working on a upas/fs patch that
uses this work. I hope to have something this weekend.


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T6899bf3f0654295d-M61de2eb3c44020e589f16480
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] Software philosophy
  2021-08-18 22:00                 ` Eli Cohen
@ 2021-08-19  7:08                   ` Keith Gibbs
  2021-08-19  7:59                     ` sirjofri
  2021-08-19  9:19                     ` hiro
  2021-08-22  2:46                   ` kokamoto
  1 sibling, 2 replies; 85+ messages in thread
From: Keith Gibbs @ 2021-08-19  7:08 UTC (permalink / raw)
  To: 9fans

[-- Attachment #1: Type: text/plain, Size: 7442 bytes --]

Hej Eli,

I think, philosophically, there is a disconnect re: the status of 9front vs 9legacy by 9legacy folks. Even David suggested that 9legacy is “real” Plan 9, rather than a fork. Fundamentally this is semantics, but it leads to seeing them as fundamentally different things, when they really aren’t.

The true disconnect is what position within each hold in regards to each other. Historically, forks (after a point) stay forks and no longer contribute “upstream” to their parent for love and cookies. They become cooperative peers [in good cases] or competition [in not so good cases]. Even *if* 9legacy is the “true" torchbearer, the fork happened ages ago. Some in the 9legacy camp see 9front as a downstream project that should [be forced] to make patches for the “true” Plan 9. Most 9front devs and users see them as peer projects and feel that pointing to the source code and letting 9legacy folks make their own patch the reasonable answer. Most 9front people have no vested interest in porting anything to 9legacy, since it is not the one they use. To them, it is like Ubuntu being expected to upstream cherry picked features and bug changes hand selected by Debian developers who don’t want to do it. Pretty absurd.

Insofar as what David du Colombier said that 9legacy is a “continuation” of Plan 9 from Bell Labs, sure. However, cinap or hiro or Ori or a bunch of other people here can make that same argument with 9front. 9front came about because people were slow to fix things or reticent to change things. In this way, *both* are continuations. 

But in the end, looking at the project as a peer vs project as a subordinate offshoot frames how further dialog and cooperation is done. In the former, we can point at code, debate healthy re: what level of compatibility is worth it [i.e. what Plan 9 from Bell Labs version 2 software are you really wanting to run and not just update a few lines of code…], what provisional changes can be made to fix issues but maintain old interfaces while everyone catch up, bugs in the legacy code that can be fixed, how can we collectively showcase software tools [non-OS code] made by the collective community, etc. In the latter, it will typically degrade to finger wagging for doing something that steps over some invisible line or demanding that specific changes be ported to the “real” one… i.e. 9front contributors have the bulk of the emotional and physical labor supporting a version they will never use.

hiro made a bit of a tongue in cheek, shit talking quip re: “lol but it is” since 9front, for good or for bad, probably commits orders of magnitude more code than other 9family projects. And from the 9front ml and code discussions, the community does keep pretty high standards in not just committing crap, cruft, or flights of fancy into the repo. Design wise, both 9legacy and 9front stick to simplicity and cleanliness present in the software culture of the Bell Labs team. It isn’t like one is crazy bloat and the other is elegant… more that one is less adverse to pulling the out the whole engine to fix the car and the other is more adverse. One is less interested in backwards compatibility with versions from 20 years ago for backwards compatibility sake and one wants to not have anything not run that V4 can. Both are different strategies and have different benefits...

So not to belabour things further, I think we kind of need to come to somewhat of a consensus re: how these two project relate. I honestly think that imposing a “One Plan 9” or reframing 9legacy as the authoritative parent project will in fact harm 9legacy more the 9front, as the latter is more comfortable doing its own thing and honestly, 9front works better on more hardware and is more actively updated and supported. Agreeing that both projects are sister projects allows more dialog and actual sharing to happen.

My intention was not to spark some sort of holy war and I get the feeling most people in this community see the two are peer projects. When people float the idea of the P9F imposing a “One Plan 9” by dictum rather than the actual codebases, community members, etc. deciding how things should work, well, that needs to be called out…

-pixelheresy

> On 19. Aug 2021, at 1.00, Eli Cohen <echoline@gmail.com> wrote:
> 
> what is all the friction actually about here?? the most important
> philosophical question always ends up the same, how can we figure out
> a good formula for not being jerks?
> 
> I have ended up using 9front more and more, obviously. 9front was
> started specifically to address the fact that Plan 9 from Bell Labs
> didn't run on most computers... If I have any feeling at all about it,
> it's that there's room for another fork that is an even simpler
> research platform. in other discussions people say, why do we have
> things that aren't relevant? We all love catclock, email... some users
> may only want plan 9 for that... some people also discussed even
> removing compiled binaries as much as possible. mostly, I like the
> idea of plan 9 that runs on the computer I have... but I understand
> that for a lot of reasons other people don't necessarily feel the same
> way.
> 
> we wouldn't be here if we didn't agree Plan 9 is the best OS design.
> and they're all free software. 9front has some very interesting things
> that 9legacy can (and does) use as patches. it's just actually
> difficult to write software, for some value of difficulty.
> 
> there's a lot of shit going on in the world today... we all gathered
> here to agree Plan 9 is great software, then just be rude to each
> other because...? I really don't understand, I'm not exaggerating.
> what is the actual disagreement here?
> 
> On Wed, Aug 18, 2021 at 1:12 PM David du Colombier <0intro@gmail.com <mailto:0intro@gmail.com>> wrote:
>> 
>> Here are some clarifications.
>> 
>> 9legacy used to be a an experimental patch queue for
>> Plan 9 from Bell Labs, providing patches that were not
>> yet accepted into the mainline distribution. That's why
>> we didn't recommend to use 9legacy, unless you had
>> specific needs.
>> 
>> However, this isn't really the case since 2015, because
>> Plan 9 from Bell Labs is not maintained anymore
>> (last release was 2015-01-10).
>> 
>> Today, 9legacy is more of a continuation of Plan 9 from Bell Labs.
>> There are still experimental patches, but also a lot of fixes and
>> improvements that would probably be part of Plan 9 from Bell Labs
>> if it was still maintained.
>> 
>> Also, NIX is not maintained anymore. However, there are
>> some other variants of 9k (the 64-bit Plan 9 kernel), including
>> the one available as part of 9legacy, that are still in progress.
>> 
>> --
>> David du Colombier
> 
> ------------------------------------------
> 9fans: 9fans
> Permalink: https://9fans.topicbox.com/groups/9fans/T9ef6430f3025e731-Me55ae2eef0de0a39ecd205ad <https://9fans.topicbox.com/groups/9fans/T9ef6430f3025e731-Me55ae2eef0de0a39ecd205ad>
> Delivery options: https://9fans.topicbox.com/groups/9fans/subscription <https://9fans.topicbox.com/groups/9fans/subscription>

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T9ef6430f3025e731-M51f0a671128e643ab96b6b11
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 31822 bytes --]

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] Software philosophy
  2021-08-19  7:08                   ` Keith Gibbs
@ 2021-08-19  7:59                     ` sirjofri
  2021-08-19  9:27                       ` Lucio De Re
  2021-08-19  9:29                       ` hiro
  2021-08-19  9:19                     ` hiro
  1 sibling, 2 replies; 85+ messages in thread
From: sirjofri @ 2021-08-19  7:59 UTC (permalink / raw)
  To: 9fans

Hello dear community,

I've read through many things in this thread and just want to add some 
two cents in a list format:

1) p9f (to my knowledge) never said anything about The One Plan 9. This 
was afaik the idea of some other community member, and I never heard any 
statement by p9f about that.

2) In fact, p9f is pretty silent, not only these days. This could be a 
good sign, as they let community be what they are, only occasionally 
taking part in it.

3) the p9f website promotes links to the Plan 9 archive software (V1-V4), 
9legacy as "Plan 9 with many useful patches", the RPi version and other 
Plan 9 resources. 9front is _never_ mentioned at all. It seems like they 
don't consider 9front as a Plan 9 system at all.

I don't know why, it's possible they just don't want it to exist or they 
don't know how to see it. It just hurts me personally as a community 
person who uses 9front and not the original Plan 9. And it's confusing. 
Am I even a Plan 9 user? The core OS principles are the same and most 
"shell" concepts also.

4) The split between original Plan9/9legacy and the 9front fork is 
reflected in a split between communities. David and the 9front core devs 
already showed that they are generally willing to share and accept 
patches and I never noticed any bad tone in their discussion, however the 
community is split up. And I don't think that we are so big that we _had_ 
to split up, there are other reasons, maybe historical reasons I don't 
know as a "fresh" community member with only ~5 years.

5) I really wished p9f would tell us more about their plans. It really 
seems like it's what we (9gridchan chat) feared in the beginning: a 
secret society. p9f is very silent, currently only seems to manage GSoC 
and nothing more. They told us they needed time to organize GSoC and 
themselves, but that was in january/february!

It's fine if they want to be silent, but it would be nice to see what we 
can expect from them. Currently it seems like they just want to share 
links to 9legacy and the archive and organize GSoC and hide the fact that 
9front exists.

6) p9f had a page about their purpose. It was like, they want to promote 
all Plan 9 systems and related technologies: 9atom, 9legacy, ... missing 
the (apparently) most obvious one: 9front. I couldn't find the page 
anymore. Other dubious sources can be found on the 9front /who/ site 
about p9f, where they apparently stole resources from 9front/cat-v pages. 
Very suspicious somehow.

7) To clarify: I don't want to see p9f as bad. I want to see them as a 
nice organization which is open for community efforts that need some 
official site. I want to see other community members/devs there, maybe 
one 9front contributor. I want to see them mentioning 9front like they 
mention other Plan 9 projects. I want to see p9f members open their 
mouths sometimes (which does happen) and take part in the community.

These are my wishes and notes, everything from my perspective.

sirjofri

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T9ef6430f3025e731-Mc7a4815c52acb2ee56b20f23
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] Software philosophy
  2021-08-19  7:08                   ` Keith Gibbs
  2021-08-19  7:59                     ` sirjofri
@ 2021-08-19  9:19                     ` hiro
  1 sibling, 0 replies; 85+ messages in thread
From: hiro @ 2021-08-19  9:19 UTC (permalink / raw)
  To: 9fans

> more that one is less adverse to pulling the out the whole engine to fix the car and the other is more adverse

i think the better comparison is that with our volkswagen we can actually drive.
i know the bell-labs car radio won't even boot bec. you're using the
wrong IDE port.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T9ef6430f3025e731-Mbe7983b17b5ba71467f89381
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] Software philosophy
  2021-08-19  7:59                     ` sirjofri
@ 2021-08-19  9:27                       ` Lucio De Re
  2021-08-19  9:45                         ` hiro
                                           ` (3 more replies)
  2021-08-19  9:29                       ` hiro
  1 sibling, 4 replies; 85+ messages in thread
From: Lucio De Re @ 2021-08-19  9:27 UTC (permalink / raw)
  To: 9fans

On 8/19/21, sirjofri <sirjofri+ml-9fans@sirjofri.de> wrote:
> Hello dear community,
>
> I've read through many things in this thread and just want to add some
> two cents in a list format:
>
> 1) p9f (to my knowledge) never said anything about The One Plan 9. This
> was afaik the idea of some other community member, and I never heard any
> statement by p9f about that.
>
Indeed correct. My suggestion started with a lobbying idea for useful
concepts such as the addition of Oauth2 to factotum so that there
could be some momentum rather than spurious hope for interest to
incorporate "core" changes into whatever P9F consider their target OS.

I am not a member of P9F, when I checked the membership I assumed that
my participation as more than a spectator would not be welcome -
personal reasons.

So instead i thought that as a lobbyist within a framework, I could
expect to have a less subjectively negative value, period.

> 2) In fact, p9f is pretty silent, not only these days. This could be a
> good sign, as they let community be what they are, only occasionally
> taking part in it.
>
P9F owes no one anything. Some resources seem to have moved under
their umbrella, contributed voluntarily. The licence change has been
an important step forward. Again, approaching P9F in a public forum
may or may not have a more positive impact. Like it or not, the
foundation is operated by humans and historically active Plan 9 "fans"
have behaved controversially. Not all, but a lot.

> 3) the p9f website promotes links to the Plan 9 archive software (V1-V4),
> 9legacy as "Plan 9 with many useful patches", the RPi version and other
> Plan 9 resources. 9front is _never_ mentioned at all. It seems like they
> don't consider 9front as a Plan 9 system at all.
>
That is true and only P9F can address that issue. Which does rather
throw a spanner in Keith's complaints about me, because his claim is
that P9F want to assimilate and dominate 9front, based on a very thin
claim from me that I would be happier in a 1P9 universe. But let's not
ad hominem unnecessarily.

Incidentally, all contributions to 9legacy and/or mentioned as P9F
resources are either inherited from Nokia (have I got that right?) or
from individual members of P9F. As an afterthought, is it not obvious
that 9front may be able to get a seat at the table if they contributed
in a similar way? Is that possible? Has such an approach already been
turned down? What do we know?

> I don't know why, it's possible they just don't want it to exist or they
> don't know how to see it. It just hurts me personally as a community
> person who uses 9front and not the original Plan 9. And it's confusing.
> Am I even a Plan 9 user? The core OS principles are the same and most
> "shell" concepts also.
>
Totally. No one labels you a Plan 9 user, you do that yourself. There
are subtle semantic issues with the original "9front" nomenclature and
remote history. We've all grown up a lot since then, but part of
growing up includes owning errors of judgement. We can, presumably,
find our way forward without that baggage, maybe not. Opinions seem to
vary (my own personal conflicts included) in this forum.

> 4) The split between original Plan9/9legacy and the 9front fork is
> reflected in a split between communities. David and the 9front core devs
> already showed that they are generally willing to share and accept
> patches and I never noticed any bad tone in their discussion, however the
> community is split up. And I don't think that we are so big that we _had_
> to split up, there are other reasons, maybe historical reasons I don't
> know as a "fresh" community member with only ~5 years.
>
As I mentioned elsewhere, there is what seems to me a well defined
"9front inside circle", which basically seems to include, by default
or by choice, everyone that uses 9front as their primary (Plan 9)
platform. Vocal defenders of 9front all appear to carry virtual
membership cards to this circle. And in case I am once again
misunderstood, I think that is a very important and positive aspect of
the 9front community.

As a pale-skinned South African (European descent), I am also deemed
to carry a membership card to some kind of circle, so I'm not
incompetent to address this aspect.

What seems to be harped upon by the vocal defenders of 9front,
however, is this fictional idea that there is another community, let's
call them "9legacy", that is attempting to subvert 9front's efforts to
gain some kind of recognition in the bigger picture. I know no one
whose preference, like mine, is to stick closer to the 9legacy release
of Plan 9, who in some way wants to reduce the value of 9front. Just
as OP points out, cooperation between David and Cinap and colleagues
has been cordial, if occasionally confrontational, for many, many
years. So Hiro and Kurt and others can be scratchy and no doubt so can
I, I don't think any of us have done any permanent damage to the 9fans
or the narrower 9front community.

Hmm, there has been some damage, quite a way back, now that I think
about it, but that goes back a long, long way, when discord was more
fierce and emotional and 9front hadn't yet found its own identity.

So what I'm saying is that 9fans exists, it IS a community; 9front
(the OS) has its own community that overlaps in part with 9fans;
9legacy (the code) has users, individuals, mostly, who may ignore
9front, but cannot possibly be accused in any real sense of
participating in a counter-9front conspiracy. If there is any evidence
to the contrary, I'd like to see it.

I'll refrain from elaborating on motives and other unprovable details.

> 5) I really wished p9f would tell us more about their plans. It really
> seems like it's what we (9gridchan chat) feared in the beginning: a
> secret society. p9f is very silent, currently only seems to manage GSoC
> and nothing more. They told us they needed time to organize GSoC and
> themselves, but that was in january/february!
>
I think P9F has performed the most important duties they set
themselves: they are providing a useful umbrella to protect Plan
9-related resources from becoming extinct and have modernised the Plan
9 software licence to protect Plan 9 from being hi-jacked by hostile
groups. Do you think anything else is required of them?

As for the issue of Plan 9's "name", I agree with Keith that 9front
may take exception at being left out of the Plan 9 nomenclature and I
think it is up to the 9front community to approach P9F to negotiate
what should be the final outcome. I have no idea what it means for
9front to be or not to be a "Plan 9" and, off-hand, I bet no one else
in this forum has considered this a relevant issue. But maybe it
should be and whereas "Plan 9" is some kind of intellectual property
owned by P9F, 9front may be welcome to use it.

In fact, there is some thin ice there, so 9front may well want to
investigate this and approach P9F for clarification, before P9F makes
a decision that may not go down well with everyone.

> It's fine if they want to be silent, but it would be nice to see what we
> can expect from them. Currently it seems like they just want to share
> links to 9legacy and the archive and organize GSoC and hide the fact that
> 9front exists.
>
How do you "hide a fact"? Are you also infected with that conspiracy
theory? And what would P9F possibly gain from such an absurd stance?
9front appears 11 times (5 or so distinct entries) in the Plan 9
wikipedia page. I guess the "authors" may be able to remove these
references, but would it not be better if the 9front community chose
to create a wikipedia entry for themselves? That said, if there was a
conspiracy, would the conspirators not have already wiped out 9front
from a wikipedia page over which they presumably have some level of
authority?

> 6) p9f had a page about their purpose. It was like, they want to promote
> all Plan 9 systems and related technologies: 9atom, 9legacy, ... missing
> the (apparently) most obvious one: 9front. I couldn't find the page
> anymore. Other dubious sources can be found on the 9front /who/ site
> about p9f, where they apparently stole resources from 9front/cat-v pages.
> Very suspicious somehow.
>
Skip is a P9F member. Perhaps he'd care to comment? If accusations of
intellectual property "theft" have any validity (or none), this may
well be a great place to air them.

> 7) To clarify: I don't want to see p9f as bad. I want to see them as a
> nice organization which is open for community efforts that need some
> official site. I want to see other community members/devs there, maybe
> one 9front contributor. I want to see them mentioning 9front like they
> mention other Plan 9 projects. I want to see p9f members open their
> mouths sometimes (which does happen) and take part in the community.
>
You get to see in the P9F what you contributed to, no more, nor less
than anyone else. I won't bore anyone with a rant.

> These are my wishes and notes, everything from my perspective.
>
> sirjofri
>
Thank you for raising them. As I said up front, I am not a P9F member
of any kind. But I know that its intentions are far less nefarious
than of those who wittingly ascribe nefarious intentions to them.
Again, 9front has an "inside", get it to address with P9F their and
your reservations. If they don't respond, then you and other 9fronters
can bring evidence of ill intentions to this forum.

Lucio.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T9ef6430f3025e731-Mc60bc784bcca5bb5b657185a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] Software philosophy
  2021-08-19  7:59                     ` sirjofri
  2021-08-19  9:27                       ` Lucio De Re
@ 2021-08-19  9:29                       ` hiro
  2021-08-19  9:44                         ` sirjofri
  1 sibling, 1 reply; 85+ messages in thread
From: hiro @ 2021-08-19  9:29 UTC (permalink / raw)
  To: 9fans

> anymore. Other dubious sources can be found on the 9front /who/ site
> about p9f, where they apparently stole resources from 9front/cat-v pages.
> Very suspicious somehow.

that's because they lost the bell-labs server. else they could have
"stolen" it from their own machines.
we mirrored all the documents in fear that the data on that web server
would get lost some day, and it seems we were right.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T9ef6430f3025e731-M04dee619eb28a80a33ec48cc
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] Software philosophy
  2021-08-19  9:29                       ` hiro
@ 2021-08-19  9:44                         ` sirjofri
  0 siblings, 0 replies; 85+ messages in thread
From: sirjofri @ 2021-08-19  9:44 UTC (permalink / raw)
  To: 9fans


19.08.2021 11:29:29 hiro <23hiro@gmail.com>:

>> anymore. Other dubious sources can be found on the 9front /who/ site
>> about p9f, where they apparently stole resources from 9front/cat-v 
>> pages.
>> Very suspicious somehow.
>
> that's because they lost the bell-labs server. else they could have
> "stolen" it from their own machines.
> we mirrored all the documents in fear that the data on that web server
> would get lost some day, and it seems we were right.

I want to excuse myself here for the word "stole". I should have written 
it differently or at least put it in quotes.

The mentioned resources were original Plan 9 resources afaik (or even 
obviously). I'm glad cat-v/9front was able to keep them stored for future 
generations. It's just not a good light having documents on a website 
with the title of cat-v/9front origin while not mentioning that part of 
the community at all.

sirjofri

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T9ef6430f3025e731-Mffbb6faea607aae13c39db35
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] Software philosophy
  2021-08-19  9:27                       ` Lucio De Re
@ 2021-08-19  9:45                         ` hiro
  2021-08-19  9:51                         ` hiro
                                           ` (2 subsequent siblings)
  3 siblings, 0 replies; 85+ messages in thread
From: hiro @ 2021-08-19  9:45 UTC (permalink / raw)
  To: 9fans

...

> would it not be better if the 9front community chose
> to create a wikipedia entry for themselves? That said, if there was a
> conspiracy, would the conspirators not have already wiped out 9front
> from a wikipedia page over which they presumably have some level of
> authority?

the groups that are able to hold "power" over a wikipedia page are not
easy to define, there's no traditional form of authority there.

for example my IP is banned from editing wikipedia.

it's impossible for the 9front community to play the necessary
political games to maintain our own wikipedia website. it's much
easier to just delete the 9front wikipedia entry and instead point to
our own more authoritative non-wikipedia wiki. such efforts regularly
get sabotaged by (well-meaning?) non-9front-related wikipedians.

Their COC is probably not compatible to our COQ either ;)

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T9ef6430f3025e731-Maad596a97d7cd0fcd83f2410
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] Software philosophy
  2021-08-19  9:27                       ` Lucio De Re
  2021-08-19  9:45                         ` hiro
@ 2021-08-19  9:51                         ` hiro
  2021-08-19 10:10                           ` sirjofri
  2021-08-19 10:38                         ` Keith Gibbs
  2021-08-19 10:56                         ` kvik
  3 siblings, 1 reply; 85+ messages in thread
From: hiro @ 2021-08-19  9:51 UTC (permalink / raw)
  To: 9fans

> Thank you for raising them. As I said up front, I am not a P9F member
> of any kind. But I know that its intentions are far less nefarious
> than of those who wittingly ascribe nefarious intentions to them.

Can you prove that? what makes you competent to know without being a p9f member?

> Again, 9front has an "inside", get it to address with P9F their and
> your reservations. If they don't respond, then you and other 9fronters
> can bring evidence of ill intentions to this forum.

Sadly that's not how it works. Until they specifically admit it, they
have every right to claim they just had no time to act on behalf of
unimportant pet projects.

Of course over a longer time, such a claim becomes less and less believable...

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T9ef6430f3025e731-M60bf55a5133002d55d4643db
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] Software philosophy
  2021-08-19  9:51                         ` hiro
@ 2021-08-19 10:10                           ` sirjofri
  0 siblings, 0 replies; 85+ messages in thread
From: sirjofri @ 2021-08-19 10:10 UTC (permalink / raw)
  To: 9fans


19.08.2021 11:51:48 hiro <23hiro@gmail.com>:

>> Thank you for raising them. As I said up front, I am not a P9F member
>> of any kind. But I know that its intentions are far less nefarious
>> than of those who wittingly ascribe nefarious intentions to them.
>
> Can you prove that? what makes you competent to know without being a 
> p9f member?
>
>> Again, 9front has an "inside", get it to address with P9F their and
>> your reservations. If they don't respond, then you and other 9fronters
>> can bring evidence of ill intentions to this forum.
>
> Sadly that's not how it works. Until they specifically admit it, they
> have every right to claim they just had no time to act on behalf of
> unimportant pet projects.
>
> Of course over a longer time, such a claim becomes less and less 
> believable...

If their website source was available online I would happily send them a 
patch.

... and that says me, who always needs to figure put how to create and 
apply patches.

sirjofri

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T9ef6430f3025e731-M54f582a8419e4702524b90f3
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] Software philosophy
  2021-08-19  9:27                       ` Lucio De Re
  2021-08-19  9:45                         ` hiro
  2021-08-19  9:51                         ` hiro
@ 2021-08-19 10:38                         ` Keith Gibbs
  2021-08-19 11:45                           ` hiro
  2021-08-19 10:56                         ` kvik
  3 siblings, 1 reply; 85+ messages in thread
From: Keith Gibbs @ 2021-08-19 10:38 UTC (permalink / raw)
  To: 9fans



>> 3) the p9f website promotes links to the Plan 9 archive software (V1-V4),
>> 9legacy as "Plan 9 with many useful patches", the RPi version and other
>> Plan 9 resources. 9front is _never_ mentioned at all. It seems like they
>> don't consider 9front as a Plan 9 system at all.
>> 
> That is true and only P9F can address that issue. Which does rather
> throw a spanner in Keith's complaints about me, because his claim is
> that P9F want to assimilate and dominate 9front, based on a very thin
> claim from me that I would be happier in a 1P9 universe. But let's not
> ad hominem unnecessarily.

Oh Lucio… I didn’t say that. You are either skimming to make arguments against what you *think* I said, or just being disingenuous to muddle my position. 

I didn’t say P9F was planning on it. You suggested it in your original response to Demitrius. I joked about blessing 9front as official, to point out how divisive and absurd it would be for a non-elected governing body to impose anything on an Open Source community and *then* pointed out how the P9F’s mission materials is about promoting and not regulating. 

I never said the P9F specifically wanted to reign in 9front as a recalcitrant child, rather that some community members here [you included, but a few other vocal ones] seem insistent that “good” features and fixes in 9front be demanded as patches from 9front devs to a project they do not participate in. Cinap and others have in fact made patches this here and there, but the idea the tribute is demanded for audience is absurd. Much like your motorcycle metaphor, there are ways to build in consistency and compatibility besides appeals to authority.

> What seems to be harped upon by the vocal defenders of 9front,
> however, is this fictional idea that there is another community, let's
> call them "9legacy", that is attempting to subvert 9front's efforts to
> gain some kind of recognition in the bigger picture. I know no one
> whose preference, like mine, is to stick closer to the 9legacy release
> of Plan 9, who in some way wants to reduce the value of 9front. Just
> as OP points out, cooperation between David and Cinap and colleagues
> has been cordial, if occasionally confrontational, for many, many
> years. So Hiro and Kurt and others can be scratchy and no doubt so can
> I, I don't think any of us have done any permanent damage to the 9fans
> or the narrower 9front community.

I think this may be a bit of a straw man argument, at least in terms of myself, peers I have spoken to in the 9front community, 9gridchan folks, etc. It is less 9front vs 9legacy. My position is more 9front & 9legacy coexisting vs a vocal minority who actively pepper messages with with rhetoric supporting a theoretical [forced] merger or culling of 9front in favor of a more authentic/pure version. As I said in my email to Eli, it is less a dichotomy between factions as a position where people in both 9front and 9legacy [and p9p users, etc. etc.] would happily see a positive mutual community of peers all congregating in 9fans living in cooperation and harmony vs. those who demand that there be some authority to legitimize one thing and force others to come to heel or leave. 

Making “P.S.” call outs to garner support for 1P9 (especially by means of appeal to external authority) forces me to speak up. Simple as that. The 9fans community knows me a bit less [since I mostly ready and enjoy discussions], but 9front/9grid/other OSS communities kind of know me as a positive, easy going, get along with everyone kind of guy. Call it “Papa Bear” instincts as a dad, or because I have been in the midst of other OSS drama over the years [and occasionally have seen what were tantamount to hostile, undemocratic takeovers of software projects], I kind of feel like I need to protect everyone’s little garden.

> So what I'm saying is that 9fans exists, it IS a community; 9front
> (the OS) has its own community that overlaps in part with 9fans;
> 9legacy (the code) has users, individuals, mostly, who may ignore
> 9front, but cannot possibly be accused in any real sense of
> participating in a counter-9front conspiracy. If there is any evidence
> to the contrary, I'd like to see it.

I am not seeing it as a conspiracy [as I said in the prior, not as malice either]. You and several others seem to feel that “Plan 9” as an OS becomes stronger through editorialization by means of a single vision [whether person or committee]. Since P9F has been announced, some people are expressing a “need” for a single, definitive Plan 9 [post V4 in January, 2015]. You probably think that is the best. You and others advocating for it are the heroes of your story… of your vision.

Conversely, quite a lot of people [not ironically including most 9front devs] don’t want authority. They kind of like having the Plan 9 flavor they use. I mean Jeanne is cool [I like 9front better] and kind of like the switch to markdown and some minor unix-isms included in the OS. Some people will probably consider that their jam. For a lot of us, if any official body would come to being to be a feature/compatibility steering group, it needs to be one that is elected, rather than just some group doing the community a favor by holding some rights. 

In this way, us on the other side of the fence are basically just saying, “yeah, no 1P9, especially dictated down from P9F is a bad idea for our robust and diverse community”.

>> 5) I really wished p9f would tell us more about their plans. It really
>> seems like it's what we (9gridchan chat) feared in the beginning: a
>> secret society. p9f is very silent, currently only seems to manage GSoC
>> and nothing more. They told us they needed time to organize GSoC and
>> themselves, but that was in january/february!
>> 
> I think P9F has performed the most important duties they set
> themselves: they are providing a useful umbrella to protect Plan
> 9-related resources from becoming extinct and have modernised the Plan
> 9 software licence to protect Plan 9 from being hi-jacked by hostile
> groups. Do you think anything else is required of them?
> 
> As for the issue of Plan 9's "name", I agree with Keith that 9front
> may take exception at being left out of the Plan 9 nomenclature and I
> think it is up to the 9front community to approach P9F to negotiate
> what should be the final outcome. I have no idea what it means for
> 9front to be or not to be a "Plan 9" and, off-hand, I bet no one else
> in this forum has considered this a relevant issue. But maybe it
> should be and whereas "Plan 9" is some kind of intellectual property
> owned by P9F, 9front may be welcome to use it.
> 
> In fact, there is some thin ice there, so 9front may well want to
> investigate this and approach P9F for clarification, before P9F makes
> a decision that may not go down well with everyone.

Actually, I remember discussing this with sirjofri and others at the beginning of the year. It’s cool that they got the rights from Nokia, so it can be relicensed as a fully free license. Cool that there is a sponsorship org for GoS requirements [even if the decision-making process was a bit opaque]. But what are the P9F doing otherwise? Back in the day, we knew the community had Lucient’s support for what we were doing. As with Nokia. There was a relationship of sorts. Whereas the P9F (as an org) as been kind of silent.

I think most of us know better to conflate the individuals [most of which are here] with P9F or their word as the word of that body, so we don’t. But either regard, we have been given little detail.

Similarly, there were at least 2-3 rounds of calls to include 9front in the roll of projects. Sure, part is that some of the pages are copypasta from old websites, but really. HTML isn’t hard. It is either laziness or political. 

>> It's fine if they want to be silent, but it would be nice to see what we
>> can expect from them. Currently it seems like they just want to share
>> links to 9legacy and the archive and organize GSoC and hide the fact that
>> 9front exists.
>> 
> How do you "hide a fact"? Are you also infected with that conspiracy
> theory? And what would P9F possibly gain from such an absurd stance?
> 9front appears 11 times (5 or so distinct entries) in the Plan 9
> wikipedia page. I guess the "authors" may be able to remove these
> references, but would it not be better if the 9front community chose
> to create a wikipedia entry for themselves? That said, if there was a
> conspiracy, would the conspirators not have already wiped out 9front
> from a wikipedia page over which they presumably have some level of
> authority?

This is a disingenuous argument.

If someone looks for Plan 9 and finds the Official Plan 9 Foundation, they only have links to 9legacy, p9p, and Inferno. If you know nothing else, you think that is all that exists of the Plan 9 community. 

Between 9front and Harvey (and others), you are missing a fair portion of the development community in Plan 9 space, and arguably quite active.

Again, I am not sure you understand what conspiracy means. It’s either intent or neglect. 

> Thank you for raising them. As I said up front, I am not a P9F member
> of any kind. But I know that its intentions are far less nefarious
> than of those who wittingly ascribe nefarious intentions to them.
> Again, 9front has an "inside", get it to address with P9F their and
> your reservations. If they don't respond, then you and other 9fronters
> can bring evidence of ill intentions to this forum.

Dude. We aren’t after the heads of P9F. Settle down.

The general problems 9front folks have with P9F so far mostly boils down to the lack of representation. That’s it.

I cannot find anywhere were the P9F or any member speaking on behalf of the org said that we should have One Plan 9. 

We have beef with the One Plan 9 idea. Or at least the all people I have talked to about this topic.

Sirjofri’s email (which you responded to bit by bit, but you may have lost the context) is to respond to the fact that the P9F never said boo about 1P9, that is likely implies they don’t want it… but… needs to be a bit more actively supportive of other communities within the greater Plan 9 fold… That’s it. He nor I are blaming 9PF for your terrible idea.

-pixelheresy


> Lucio.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T9ef6430f3025e731-M5ea6ebbac4132fe10f1ddf6c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] Software philosophy
  2021-08-19  4:34               ` Lucio De Re
@ 2021-08-19 10:44                 ` Keith Gibbs
  2021-08-19 18:53                 ` Git & Conventional Browsers (Was Re: [9fans] Software philosophy) unobe
  1 sibling, 0 replies; 85+ messages in thread
From: Keith Gibbs @ 2021-08-19 10:44 UTC (permalink / raw)
  To: 9fans

> On Aug 19, 2021, at 7:34 AM, Lucio De Re <lucio.dere@gmail.com> wrote:
> 
> It is the pragmatic end of the Plan 9 spectrum, courtesy of Cinap who
> clearly would be a Torvalds if Plan 9 had gained the traction of
> Linux.
> 

Oh please. You think Cinap is some sort of charismatic demogogue of 9front? 

Yeah… he’s not like that. In fact, 9front development is highly decentralized in authority and everyone seems to spot, review, critique, and gatekeep each other, rather than any person having a single final say.

Perhaps I haven’t been with the community long enough to have seen any drag-out, knock-down fights that require a code-daddy [if any of those ever took place, I don’t know], but no, you really have a strange vision of what is going on at 9front.

-pixelheresy


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T9ef6430f3025e731-Md9eb7bfcec9641d61110a0e1
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] Software philosophy
  2021-08-19  9:27                       ` Lucio De Re
                                           ` (2 preceding siblings ...)
  2021-08-19 10:38                         ` Keith Gibbs
@ 2021-08-19 10:56                         ` kvik
  2021-08-19 11:33                           ` sirjofri
  2021-08-19 20:44                           ` ori
  3 siblings, 2 replies; 85+ messages in thread
From: kvik @ 2021-08-19 10:56 UTC (permalink / raw)
  To: 9fans

Quoth Lucio De Re <lucio.dere@gmail.com>:
> What seems to be harped upon by the vocal defenders of 9front,
> however, is this fictional idea that there is another community, let's
> call them "9legacy", that is attempting to subvert 9front's efforts to
> gain some kind of recognition in the bigger picture.

The core 9front contributors and most everyone else who commented
on this situation in 9front's super secret inner circles simply find
it socially awkward that 9front isn't mentioned. Some may read more
of the signal.

Otherwise 9front folks couldn't care less about being recognized by a
website.  Nothing would change or improve if that happened.  The only
ones who objectively suffer in the current situation is newcomers who
aren't properly informed by a website on the options they have if they
want to run a "Plan 9".


I personally don't see an issue with 9front and 9legacy continuing to
be their own things.  Different people have different ideas for what
they want to make out of their Plan 9 and sometimes their ideas are
simply incompatible.

I'd like to see people communicate and exchange ideas and/or code more
effectively but this will always remain in the hands of individuals
who decide how to socialise and what to work on.


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T9ef6430f3025e731-Mc4e94b26abc53ada87addb87
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] Software philosophy
  2021-08-19 10:56                         ` kvik
@ 2021-08-19 11:33                           ` sirjofri
  2021-08-19 20:44                           ` ori
  1 sibling, 0 replies; 85+ messages in thread
From: sirjofri @ 2021-08-19 11:33 UTC (permalink / raw)
  To: 9fans


19.08.2021 12:56:02 kvik@a-b.xyz:

> Quoth Lucio De Re <lucio.dere@gmail.com>:
>> What seems to be harped upon by the vocal defenders of 9front,
>> however, is this fictional idea that there is another community, let's
>> call them "9legacy", that is attempting to subvert 9front's efforts to
>> gain some kind of recognition in the bigger picture.
>
> The core 9front contributors and most everyone else who commented
> on this situation in 9front's super secret inner circles simply find
> it socially awkward that 9front isn't mentioned. Some may read more
> of the signal.
>
> Otherwise 9front folks couldn't care less about being recognized by a
> website.  Nothing would change or improve if that happened.  The only
> ones who objectively suffer in the current situation is newcomers who
> aren't properly informed by a website on the options they have if they
> want to run a "Plan 9".

Basically this. P9f just doesn't mention 9front, and that should change 
imo, to better reflect the whole Plan 9 ecosystem. The same way p9p 
should be mentioned (or is it?)

> I personally don't see an issue with 9front and 9legacy continuing to
> be their own things.  Different people have different ideas for what
> they want to make out of their Plan 9 and sometimes their ideas are
> simply incompatible.
>
> I'd like to see people communicate and exchange ideas and/or code more
> effectively but this will always remain in the hands of individuals
> who decide how to socialise and what to work on.

100% my opinion. Don't make a canonical 1P9, just let people explore 
their ideas. Like, even 9gridchan had it's own "fork", if you want to 
call it like that.

sirjofri

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T9ef6430f3025e731-Md35909f62414b2dc634f2a8f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] Software philosophy
  2021-08-19 10:38                         ` Keith Gibbs
@ 2021-08-19 11:45                           ` hiro
  2021-08-19 12:43                             ` Eli Cohen
  0 siblings, 1 reply; 85+ messages in thread
From: hiro @ 2021-08-19 11:45 UTC (permalink / raw)
  To: 9fans

> We have beef with the One Plan 9 idea. Or at least the all people I have
> talked to about this topic.

personally i have no beef with it. i'd be happy for everybody to
upgrade to 9front.
it's all open-source for a reason, would be a shame if nobody believes
in their own fork...

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T9ef6430f3025e731-Mc29ad0e3a0dda2fc348d6dde
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] Software philosophy
  2021-08-19 11:45                           ` hiro
@ 2021-08-19 12:43                             ` Eli Cohen
  2021-08-19 19:58                               ` Aram Hăvărneanu
  0 siblings, 1 reply; 85+ messages in thread
From: Eli Cohen @ 2021-08-19 12:43 UTC (permalink / raw)
  To: 9fans

[-- Attachment #1: Type: text/plain, Size: 1342 bytes --]

some of it for me is just nostalgia. there was always someone talking about
"the world these days" though, I have to admit. ignorance sucks too but
noticing anything is excruciatingly painful! I also had a vested interest
in submitting patches "upstream" to see what I could learn from trying to
do it. I didn't get very far with it and started to feel like I was just
making a mess. I often feel that way with my coding.

if anyone understood my feelings of being misunderstood, not that I ever
put any effort into knowing who any of you are, it did seem boomers made
all this. I'm on the fence about the moon thing though, I don't see any
particular reason we should believe in any lights in the night sky or other
ridiculousness.

On Thu, Aug 19, 2021, 4:47 AM hiro <23hiro@gmail.com> wrote:

> > We have beef with the One Plan 9 idea. Or at least the all people I have
> > talked to about this topic.
> 
> personally i have no beef with it. i'd be happy for everybody to
> upgrade to 9front.
> it's all open-source for a reason, would be a shame if nobody believes
> in their own fork...

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T9ef6430f3025e731-Me9f5351c0353c26fe7ae4eea
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 2648 bytes --]

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Git & Conventional Browsers (Was Re: [9fans] Software philosophy)
  2021-08-19  4:34               ` Lucio De Re
  2021-08-19 10:44                 ` Keith Gibbs
@ 2021-08-19 18:53                 ` unobe
  2021-08-19 19:00                   ` ori
  1 sibling, 1 reply; 85+ messages in thread
From: unobe @ 2021-08-19 18:53 UTC (permalink / raw)
  To: 9fans

Quoth Lucio De Re <lucio.dere@gmail.com>:
> A transparent history of decisions in this matter would prevent losing
> any interesting proposals - yes, we need better than Git, but Git is
> painfully "enough" to start with, even if as I get more familiar with
> Git I'm starting to believe, hopefully wrongly, that Plan 9 may have
> to bend towards supporting symbolic links to deal with it if it is
> going to be a long run - and will raise a chuckle or two when future
> archeologists come across it. I doubt they'll be able to do any more
> than raise eyebrows when they try that with Linux.

Ori has developed git9--which I think is compatible with 9legacy when
a certain patch is applied (I think it's related to rc).  I don't
understand what you mean by it would require supporting symbolic links
in order to deal with it (git).  Do you mean working on git repos that
use symbolic links, not the many git repos that already exist for Plan
9-ish software?

> One last, not quite related matter: Plan 9 seems limited never to
> provide a conventional browsing experience for its audience. What does
> that actually say about Plan 9's future?

Opossum and netsurf are two browsers on Plan 9 that can provide a
conventional browsing experience, from what I've seen. They're not nearly as far along and polished as Chrome/Firefox, but it's a start.



------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T4f2bf7206a55a388-Mded82ec1613ca89af7a5598b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Git & Conventional Browsers (Was Re: [9fans] Software philosophy)
  2021-08-19 18:53                 ` Git & Conventional Browsers (Was Re: [9fans] Software philosophy) unobe
@ 2021-08-19 19:00                   ` ori
  0 siblings, 0 replies; 85+ messages in thread
From: ori @ 2021-08-19 19:00 UTC (permalink / raw)
  To: 9fans

Quoth unobe@cpan.org:
> Do you mean working on git repos that
> use symbolic links

Those also work on git9, though modifying
the symlinks is not allowed. Symlinks are
treated as copies.

See the netsurf port for an example of this
in practice.


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T4f2bf7206a55a388-M804b00fa5d8931c6401a65b9
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] Software philosophy
  2021-08-19 12:43                             ` Eli Cohen
@ 2021-08-19 19:58                               ` Aram Hăvărneanu
  0 siblings, 0 replies; 85+ messages in thread
From: Aram Hăvărneanu @ 2021-08-19 19:58 UTC (permalink / raw)
  To: 9fans

My e-mail client decided to mark this thread as read. I am glad it did.

-- 
Aram Hăvărneanu

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T9ef6430f3025e731-M19d5cd1a3c6215f93b235b39
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] Software philosophy
  2021-08-19 10:56                         ` kvik
  2021-08-19 11:33                           ` sirjofri
@ 2021-08-19 20:44                           ` ori
  1 sibling, 0 replies; 85+ messages in thread
From: ori @ 2021-08-19 20:44 UTC (permalink / raw)
  To: 9fans

Quoth kvik@a-b.xyz:
> 
> I'd like to see people communicate and exchange ideas and/or code more
> effectively but this will always remain in the hands of individuals
> who decide how to socialise and what to work on.
> 

I try to keep an eye open, and integrate patches
that make sense. I've also committed patches when
others did the same (eg, plan9front acme has gotten
many of the changes from plan9port, though not all)


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T9ef6430f3025e731-M5f5900afb2db59d9e19a9294
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] Software philosophy
  2021-08-18 22:00                 ` Eli Cohen
  2021-08-19  7:08                   ` Keith Gibbs
@ 2021-08-22  2:46                   ` kokamoto
  2021-08-22  3:16                     ` Eli Cohen
  1 sibling, 1 reply; 85+ messages in thread
From: kokamoto @ 2021-08-22  2:46 UTC (permalink / raw)
  To: 9fans

> I have ended up using 9front more and more, obviously. 9front was
> started specifically to address the fact that Plan 9 from Bell Labs
> didn't run on most computers... 

me, too.

9front have many kinds of device drivers.   If we live on other OSs than plan9, 
we cannot do anything other than those device drivers.

However, if we consider it more deep, we don't need not so much
kinds of running terminals.  We need only one cpu/auth/file server machine
and many of drawterms, or as Russ is doing plan9port.

If we consider it like this, we should discuss what kinds of computer work
we want.   I want to run deep learning on plan9...  If so, we need 64 bit
kernel for cpu server, and python....

Kenji


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T9ef6430f3025e731-M7f5dc23b2cc11ed09b8c3102
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] Software philosophy
  2021-08-22  2:46                   ` kokamoto
@ 2021-08-22  3:16                     ` Eli Cohen
  2021-08-22  7:07                       ` [9fans] Drawterm GPU (was: Software philosophy) sirjofri
  0 siblings, 1 reply; 85+ messages in thread
From: Eli Cohen @ 2021-08-22  3:16 UTC (permalink / raw)
  To: 9fans

hey Kenji,

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!

python is used a lot for some of the available things... tensorflow is
a really nice approach for custom networks, even making custom layers,
etc. I haven't seen any examples but it would be interesting to think
about that in C. it might end up being easier to write something like
that in C than port everything for something like tensorflow... I did
port a somewhat outdated C library: https://github.com/echoline/fann
it isn't nearly as customizable as tensorflow though.

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

- Eli

On Sat, Aug 21, 2021 at 7:48 PM <kokamoto@hera.eonet.ne.jp> wrote:
> > I have ended up using 9front more and more, obviously. 9front was
> > started specifically to address the fact that Plan 9 from Bell Labs
> > didn't run on most computers...
> 
> me, too.
> 
> 9front have many kinds of device drivers.   If we live on other OSs than plan9,
> we cannot do anything other than those device drivers.
> 
> However, if we consider it more deep, we don't need not so much
> kinds of running terminals.  We need only one cpu/auth/file server machine
> and many of drawterms, or as Russ is doing plan9port.
> 
> If we consider it like this, we should discuss what kinds of computer work
> we want.   I want to run deep learning on plan9...  If so, we need 64 bit
> kernel for cpu server, and python....
> 
> Kenji
> 

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T9ef6430f3025e731-Mdf830ebc446636d4ca37b479
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] Drawterm GPU (was: Software philosophy)
  2021-08-22  3:16                     ` Eli Cohen
@ 2021-08-22  7:07                       ` sirjofri
  2021-08-22 10:04                         ` Frank D. Engel, Jr.
  0 siblings, 1 reply; 85+ messages in thread
From: sirjofri @ 2021-08-22  7:07 UTC (permalink / raw)
  To: 9fans


22.08.2021 05:16:42 Eli Cohen <echoline@gmail.com>:
> 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-Mf41fbd4cbe7a7366feb7901a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] Drawterm GPU (was: Software philosophy)
  2021-08-22  7:07                       ` [9fans] Drawterm GPU (was: Software philosophy) sirjofri
@ 2021-08-22 10:04                         ` Frank D. Engel, Jr.
  2021-08-22 11:49                           ` sirjofri
  0 siblings, 1 reply; 85+ messages in thread
From: Frank D. Engel, Jr. @ 2021-08-22 10:04 UTC (permalink / raw)
  To: 9fans

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 <echoline@gmail.com>:
>> 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-Ma12c6e769699f5c3b561fbf2
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] Drawterm GPU (was: Software philosophy)
  2021-08-22 10:04                         ` Frank D. Engel, Jr.
@ 2021-08-22 11:49                           ` sirjofri
  2021-08-22 12:24                             ` Chris McGee
  0 siblings, 1 reply; 85+ messages in thread
From: sirjofri @ 2021-08-22 11:49 UTC (permalink / raw)
  To: 9fans

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. <fde101@fjrhome.net>:

> 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 <echoline@gmail.com>:
>>> 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-M5c847fafe65a91d8e47e9b63
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] Drawterm GPU (was: Software philosophy)
  2021-08-22 11:49                           ` sirjofri
@ 2021-08-22 12:24                             ` Chris McGee
  0 siblings, 0 replies; 85+ messages in thread
From: Chris McGee @ 2021-08-22 12:24 UTC (permalink / raw)
  To: 9fans

[-- Attachment #1: Type: text/plain, Size: 3893 bytes --]

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 <sirjofri+ml-9fans@sirjofri.de>
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. <fde101@fjrhome.net>:
>
> > 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 <echoline@gmail.com>:
> >>> 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

[-- Attachment #2: Type: text/html, Size: 5793 bytes --]

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] OAuth2 in factotum
  2021-08-16 11:15 [9fans] OAuth2 in factotum Demetrius Iatrakis
                   ` (3 preceding siblings ...)
  2021-08-19  5:38 ` ori
@ 2021-08-22 20:16 ` ori
  2021-08-22 20:32   ` Demetrius Iatrakis
  2021-08-22 20:36   ` ori
  4 siblings, 2 replies; 85+ messages in thread
From: ori @ 2021-08-22 20:16 UTC (permalink / raw)
  To: 9fans, 9front

[-- Attachment #1: Type: text/plain, Size: 3933 bytes --]

Quoth Demetrius Iatrakis <demetrius.iatrakis@gmail.com>:
> This is a preview of OAuth2 support in factotum, as part of this year's GSoC:
> https://github.com/Mitsos101/plan9front/pull/1
> 
> Installation, on 9front:
> 
> git/clone https://github.com/Mitsos101/plan9front plan9front-oauth
> cd plan9front-oauth
> git/branch oauth
> bind sys/include /sys/include
> @{cd sys/src/libauth && mk install}
> @{cd sys/src/cmd/auth && mk install}
> @{cd sys/src/cmd/webfs && mk install}
> 
> This will replace your factotum.
> 
> Usage:
> 
> You need to obtain OAuth credentials from your issuer first. See, for
> example, Google's guide:
> https://developers.google.com/identity/protocols/oauth2.
> 
> % echo 'key proto=oauth issuer=https://accounts.google.com scope=email
> client_id=1234 !client_secret=5678' > /mnt/factotum/ctl
> % auth/oauth 'client_id=1234'
> go to https://google.com/device
> your code is ABCD-EFGH
> <after user consent is provided, the access token is printed>
> 
> auth_oauth is also available in libauth. Webfs uses it to implement
> the preoauth command.
> 
> Bugs:
> 
> This code is specific to 9front, as libjson is required and Plan 9's
> webfs doesn't support preoauth.
> 
> factotum uses the needkey RPC to display the verification URL and code
> to the user. This means that, for now, the needkey file must not be
> open so that fgui doesn't intercept it.
> 
> The module imports lots of code to support HTTP/1.0 so that the
> refresh token doesn't leave factotum's address space.
> 
> Only the device and refresh flows are supported. There is an
> implementation of the authorization code flow (tested on macOS) here:
> https://github.com/Mitsos101/plan9port/pull/1. However, it is not
> included in the module as there is no good browser to plumb the URL
> to.
> 
> Refresh tokens are not saved to persistent storage when factotum
> exits. The user must provide consent every time factotum is restarted.
> 

And, now that we have something working, I wrote
some code to use it. I wrote a patch to add oauth
support to upas/fs -- see attached:

To use the patch, I followed this kind of clunky
process:

	https://developers.google.com/identity/protocols/oauth2

I went to the 'credentials' section on the sidebar
and I created a key for a 'desktop application'; Then
I went to the 'oauth consent screen' and added my work
email account as a 'test user'.

I grabbed the keys, and on my unix box, went to
the patched oauth:

	% cd $HOME/src/plan9port/src/cmd/oauth

and generated a key using the full, browser based
auth flow:

	% python httpd.py
	% ./oauth https://accounts.google.com https://mail.google.com/ $clientkey $clientsecret
	key proto=oauth issuer=https://accounts.google.com client_id=72...

then edited the resulting output to include the appropriate
attributes, adding the attributes in >>...<< for upas/fs:

	key proto=oauth
		>>service=imap server=imap.gmail.com user=ori@pingthings.io<<
		issuer=https://accounts.google.com client_id=<id> 
		token_type=Bearer exptime=1629662303 scope=...

and then added that to factotum:

	echo key=... >/mnt/factotum/ctl

With that, upas/fs just worked with my work email:

	upas/fs -f /imaps/imap.gmail.com/ori@pingthings.io


Bugs: there are way too many steps. Unfortunately, the most
annoying one is generating and adding an oauth client key/secret,
and short of shipping a pregenerated one (is that a good idea?),
I don't think there's a solution.

Beyond that, 2 small bits of polish which I think we
can do:

	- Adding a '-t' flag to oauth (the way auth/rsa does)
	  to add type information to auth/oauth login would
	  make it more convenient to use: the output could
	  be stored directly rather than needing editing.
	- Adding a script that allows spawning a browser and
	  http listener on unix (or redirecting thigns through
	  to plan 9) would make it easier to drive the auth
	  process from plan 9.

Thanks for doing this work, Demetrius!

[-- Attachment #2: Type: text/plain, Size: 2726 bytes --]

diff bcfee7b54757eb64cade34e476cf0dba672832f6 uncommitted
--- a/sys/src/cmd/upas/fs/imap.c
+++ b/sys/src/cmd/upas/fs/imap.c
@@ -24,6 +24,7 @@
        Cnolog  = 1<<0,
        Ccram   = 1<<1,
        Cntlm   = 1<<2,
+       Coauth  = 1<<3,
 
        /* flags */
        Fssl    = 1<<0,
@@ -151,7 +152,7 @@
 static void
 imap4cmd(Imap *imap, char *fmt, ...)
 {
-       char buf[256], *p;
+       char buf[1024], *p;
        va_list va;
 
        va_start(va, fmt);
@@ -430,6 +431,8 @@
                                imap->cap |= Ccram;
                        if(strcmp(p, "ntlm") == 0)
                                imap->cap |= Cntlm;
+                       if(strcmp(p, "xoauth2") == 0)
+                               imap->cap |= Coauth;
                }else if(strcmp(t[i], "logindisabled") == 0)
                        imap->cap |= Cnolog;
        }
@@ -733,6 +736,38 @@
 }
 
 static char*
+imap4oauth(Imap *imap)
+{
+       char *s, *auth, *enc;
+       int n;
+       OAuth *oa;
+
+       if(imap->user == nil)
+               return "user required for oauth";
+       oa = auth_getoauth(auth_getkey, "proto=oauth service=imap server=%q user=%q", imap->host, imap->user);
+       if(oa == nil)
+               return "cannot find IMAP oauth token";
+
+       imap->tag = 1;
+       if((auth = smprint("user=%s\x01auth=Bearer %s\x01\x01", imap->user, oa->access_token)) == nil)
+               sysfatal("smprint: %r");
+       if((enc = smprint("%[", auth) == nil)
+               sysfatal("smprint: %r");
+       imap4cmd(imap, "authenticate xoauth2 %s", enc);
+       free(auth);
+       free(enc);
+       free(oa);
+       s = imap4resp(imap);
+       if(isokay(s))
+               return nil;
+       imap4cmd(imap, "");
+       s = imap4resp(imap);
+       if(isokay(s))
+               return nil;
+       return s;
+}
+
+static char*
 imap4passwd(Imap *imap)
 {
        char *s;
@@ -762,6 +797,8 @@
                e = imap4cram(imap);
        else if(imap->cap & Cntlm)
                e = imap4ntlm(imap);
+       else if(imap->cap & Coauth)
+               e = imap4oauth(imap);
        else
                e = imap4passwd(imap);
        if(e)
@@ -1165,6 +1202,7 @@
        imap->host = f[2];
        if(strstr(imap->host, "gmail.com"))
                imap->flags |= Fgmail;
+       imap->flags |= Fdebug;
        imap->refreshtime = 60;
        if(nf < 4)
                imap->user = nil;
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T6899bf3f0654295d-M539f47f30599e6cfecb3adb9
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] OAuth2 in factotum
  2021-08-22 20:16 ` ori
@ 2021-08-22 20:32   ` Demetrius Iatrakis
  2021-08-22 20:38     ` ori
  2021-08-22 20:36   ` ori
  1 sibling, 1 reply; 85+ messages in thread
From: Demetrius Iatrakis @ 2021-08-22 20:32 UTC (permalink / raw)
  To: 9fans; +Cc: 9front

Thank you for your work.

Don't forget to add

type is text
dst is oauth
plumb to oauth

to your plumber's rules file to create the oauth port.

I have also added the authorization code flow to the factotum module
(can be enabled by adding `flow=auth` to the key), but it requires the
user to import the plan9port plumber into factotum's namespace. I am
unsure what the best way to do this is. Plan9port provides import(4)
which relies on SSH, but 9front does not provide an SSH server.

-- 
Demetrius

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T6899bf3f0654295d-M0301c221a9c86a5cd726882d
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] OAuth2 in factotum
  2021-08-22 20:16 ` ori
  2021-08-22 20:32   ` Demetrius Iatrakis
@ 2021-08-22 20:36   ` ori
  1 sibling, 0 replies; 85+ messages in thread
From: ori @ 2021-08-22 20:36 UTC (permalink / raw)
  To: 9fans, 9front

[-- Attachment #1: Type: text/plain, Size: 4372 bytes --]

Quoth ori@eigenstate.org:
> Quoth Demetrius Iatrakis <demetrius.iatrakis@gmail.com>:
> > This is a preview of OAuth2 support in factotum, as part of this year's GSoC:
> > https://github.com/Mitsos101/plan9front/pull/1
> > 
> > Installation, on 9front:
> > 
> > git/clone https://github.com/Mitsos101/plan9front plan9front-oauth
> > cd plan9front-oauth
> > git/branch oauth
> > bind sys/include /sys/include
> > @{cd sys/src/libauth && mk install}
> > @{cd sys/src/cmd/auth && mk install}
> > @{cd sys/src/cmd/webfs && mk install}
> > 
> > This will replace your factotum.
> > 
> > Usage:
> > 
> > You need to obtain OAuth credentials from your issuer first. See, for
> > example, Google's guide:
> > https://developers.google.com/identity/protocols/oauth2.
> > 
> > % echo 'key proto=oauth issuer=https://accounts.google.com scope=email
> > client_id=1234 !client_secret=5678' > /mnt/factotum/ctl
> > % auth/oauth 'client_id=1234'
> > go to https://google.com/device
> > your code is ABCD-EFGH
> > <after user consent is provided, the access token is printed>
> > 
> > auth_oauth is also available in libauth. Webfs uses it to implement
> > the preoauth command.
> > 
> > Bugs:
> > 
> > This code is specific to 9front, as libjson is required and Plan 9's
> > webfs doesn't support preoauth.
> > 
> > factotum uses the needkey RPC to display the verification URL and code
> > to the user. This means that, for now, the needkey file must not be
> > open so that fgui doesn't intercept it.
> > 
> > The module imports lots of code to support HTTP/1.0 so that the
> > refresh token doesn't leave factotum's address space.
> > 
> > Only the device and refresh flows are supported. There is an
> > implementation of the authorization code flow (tested on macOS) here:
> > https://github.com/Mitsos101/plan9port/pull/1. However, it is not
> > included in the module as there is no good browser to plumb the URL
> > to.
> > 
> > Refresh tokens are not saved to persistent storage when factotum
> > exits. The user must provide consent every time factotum is restarted.
> > 
> 
> And, now that we have something working, I wrote
> some code to use it. I wrote a patch to add oauth
> support to upas/fs -- see attached:
> 
> To use the patch, I followed this kind of clunky
> process:
> 
> 	https://developers.google.com/identity/protocols/oauth2
> 
> I went to the 'credentials' section on the sidebar
> and I created a key for a 'desktop application'; Then
> I went to the 'oauth consent screen' and added my work
> email account as a 'test user'.
> 
> I grabbed the keys, and on my unix box, went to
> the patched oauth:
> 
> 	% cd $HOME/src/plan9port/src/cmd/oauth
> 
> and generated a key using the full, browser based
> auth flow:
> 
> 	% python httpd.py
> 	% ./oauth https://accounts.google.com https://mail.google.com/ $clientkey $clientsecret
> 	key proto=oauth issuer=https://accounts.google.com client_id=72...
> 
> then edited the resulting output to include the appropriate
> attributes, adding the attributes in >>...<< for upas/fs:
> 
> 	key proto=oauth
> 		>>service=imap server=imap.gmail.com user=ori@pingthings.io<<
> 		issuer=https://accounts.google.com client_id=<id> 
> 		token_type=Bearer exptime=1629662303 scope=...
> 
> and then added that to factotum:
> 
> 	echo key=... >/mnt/factotum/ctl
> 
> With that, upas/fs just worked with my work email:
> 
> 	upas/fs -f /imaps/imap.gmail.com/ori@pingthings.io
> 
> 
> Bugs: there are way too many steps. Unfortunately, the most
> annoying one is generating and adding an oauth client key/secret,
> and short of shipping a pregenerated one (is that a good idea?),
> I don't think there's a solution.
> 
> Beyond that, 2 small bits of polish which I think we
> can do:
> 
> 	- Adding a '-t' flag to oauth (the way auth/rsa does)
> 	  to add type information to auth/oauth login would
> 	  make it more convenient to use: the output could
> 	  be stored directly rather than needing editing.
> 	- Adding a script that allows spawning a browser and
> 	  http listener on unix (or redirecting thigns through
> 	  to plan 9) would make it easier to drive the auth
> 	  process from plan 9.
> 
> Thanks for doing this work, Demetrius!

Oops, realized that I'd left this line in the patch:

+	imap->flags |= Fdebug;

you'll really want to delete that, or you end up with
a *TON* of debug spew.

Updated patch attached.

[-- Attachment #2: Type: text/plain, Size: 2470 bytes --]

diff bcfee7b54757eb64cade34e476cf0dba672832f6 uncommitted
--- a/sys/src/cmd/upas/fs/imap.c
+++ b/sys/src/cmd/upas/fs/imap.c
@@ -24,6 +24,7 @@
        Cnolog  = 1<<0,
        Ccram   = 1<<1,
        Cntlm   = 1<<2,
+       Coauth  = 1<<3,
 
        /* flags */
        Fssl    = 1<<0,
@@ -151,7 +152,7 @@
 static void
 imap4cmd(Imap *imap, char *fmt, ...)
 {
-       char buf[256], *p;
+       char buf[1024], *p;
        va_list va;
 
        va_start(va, fmt);
@@ -430,6 +431,8 @@
                                imap->cap |= Ccram;
                        if(strcmp(p, "ntlm") == 0)
                                imap->cap |= Cntlm;
+                       if(strcmp(p, "xoauth2") == 0)
+                               imap->cap |= Coauth;
                }else if(strcmp(t[i], "logindisabled") == 0)
                        imap->cap |= Cnolog;
        }
@@ -733,6 +736,38 @@
 }
 
 static char*
+imap4oauth(Imap *imap)
+{
+       char *s, *auth, *enc;
+       int n;
+       OAuth *oa;
+
+       if(imap->user == nil)
+               return "user required for oauth";
+       oa = auth_getoauth(auth_getkey, "proto=oauth service=imap server=%q user=%q", imap->host, imap->user);
+       if(oa == nil)
+               return "cannot find IMAP oauth token";
+
+       imap->tag = 1;
+       if((auth = smprint("user=%s\x01auth=Bearer %s\x01\x01", imap->user, oa->access_token)) == nil)
+               sysfatal("smprint: %r");
+       if((enc = smprint("%[", auth) == nil)
+               sysfatal("smprint: %r");
+       imap4cmd(imap, "authenticate xoauth2 %s", enc);
+       free(auth);
+       free(enc);
+       free(oa);
+       s = imap4resp(imap);
+       if(isokay(s))
+               return nil;
+       imap4cmd(imap, "");
+       s = imap4resp(imap);
+       if(isokay(s))
+               return nil;
+       return s;
+}
+
+static char*
 imap4passwd(Imap *imap)
 {
        char *s;
@@ -762,6 +797,8 @@
                e = imap4cram(imap);
        else if(imap->cap & Cntlm)
                e = imap4ntlm(imap);
+       else if(imap->cap & Coauth)
+               e = imap4oauth(imap);
        else
                e = imap4passwd(imap);
        if(e)
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T6899bf3f0654295d-Mbcaea13458be56f2909ea6c3
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] OAuth2 in factotum
  2021-08-22 20:32   ` Demetrius Iatrakis
@ 2021-08-22 20:38     ` ori
  0 siblings, 0 replies; 85+ messages in thread
From: ori @ 2021-08-22 20:38 UTC (permalink / raw)
  To: 9fans; +Cc: 9front

Quoth Demetrius Iatrakis <demetrius.iatrakis@gmail.com>:
> 
> type is text
> dst is oauth
> plumb to oauth
> 
> to your plumber's rules file to create the oauth port.

Ah -- right. This is in the plan9port side, and
it's used to send the oauth verification request
to the browser.

(iirc, it's not currently used for anything on the
plan 9 side, though it wil be once we figure out
how to glue together auth flows to either vmx or
some unix browser)


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T6899bf3f0654295d-Mf920328ca00963c2708ecd92
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] Drawterm GPU (was: Software philosophy)
  2021-08-22 18:50           ` sirjofri
@ 2021-09-24  1:50             ` Frank D. Engel, Jr.
  0 siblings, 0 replies; 85+ messages in thread
From: Frank D. Engel, Jr. @ 2021-09-24  1:50 UTC (permalink / raw)
  To: 9fans

Maybe /dev/gpgpu (general-purpose GPU) would be more to the point?


On 8/22/21 2:50 PM, sirjofri wrote:
>
> 22.08.2021 20:25:12 ori@eigenstate.org:
>
>> Quoth sirjofri <sirjofri+ml-9fans@sirjofri.de>:
>>>
>>> 22.08.2021 18:41:06 ori@eigenstate.org:
>>> Basically do software rendering on the GPU?
>>
>> Yes. Or software neural net evaluation on the GPU.
>> Or software video decoding on the GPU. Or software
>> image transforms on the GPU. Or software signal
>> processing on the GPU.
>>
>> If there's an interface to be selected, it needs
>> to be tractable to implement, *and* general purpose
>> enough for everything that wants to use it.
>>
>>> Well, it's totally possible. Even Nanite (the new system in Unreal 
>>> Engine
>>> 5) has its own rasterizer and I believe even its own base pass. Also
>>> Lumen does software rendering for global illumination.
>>>
>>> But for serious 3d AAA stuff we'd have to consider: Lumen is for 
>>> next-gen
>>> GPUs and Nanite for newer GPUs. We'll never reach their quality in
>>> realtime if we don't use the GPU features (built-in rasterizer, ...) to
>>> have enough free power for crazy software calculation.
>>
>> By the time any code is written, next-gen GPUs will be
>> previous-gen GPUs.
>>
>> General compute is what any hardware you buy a few years
>> from now will be doing -- and it's far more intersting
>> in terms of what capabilities it allows.
>>
>>> I like that /dev/compute approach, but may I suggest putting it below
>>> another directory /dev/gpu/compute so we have the ability to add
>>> /dev/gpu/{vertex,geometry,fragment,tessellation,pixel} later?
>>
>> I think supporting those is a cost we should not pay. It's
>> fundamentally solving a less general problem, and adds a
>> lot of complexity for the potential of a small performance
>> boost.
>>
>> We already have zero people sinking time into the slim
>> interface; sinking time into a fatter interface seems
>> like a bad idea.
> 
> Gotcha.
> 
> Maybe I'll find some time to implement some kind of gpufs or /dev/gpu
> (if it's general purpose I'd suggest renaming compute to gpu since
> "compute" could be anything. The computer does compute, wow.).
> 
> sirjofri

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-Mb1c40d6c9d3bca972decad36
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] Drawterm GPU (was: Software philosophy)
  2021-09-02  5:21             ` Eli Cohen
@ 2021-09-03 23:06               ` kokamoto
  0 siblings, 0 replies; 85+ messages in thread
From: kokamoto @ 2021-09-03 23:06 UTC (permalink / raw)
  To: 9fans

I put drawterm.apk onto my android device (SO-41B) successfully,
then, I tap that file on my device.
It does something for a while, I see graphic progress bar, and then, replied it did not
installed., which means failed to install.

By the way, android program should compile all for arm64, arm, x86 and x86_64?
I compiled it only for arm64, because my device has arm-A53 cpu.

Kenji
 
> hey Kenji,
> 
> when I was putting the apk on my phone I used the "adb" tool. I don't
> exactly remember the process... the phone has to be paired with the
> computer running adb either over a USB cable or over wifi, then the apk can
> be installed with adb. I do recall it being a bit difficult to get it
> working right consistently...
> 
> - Eli

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-M7e8fb15d448fa6580aebfcc1
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] Drawterm GPU (was: Software philosophy)
  2021-09-02  5:01           ` kokamoto
@ 2021-09-02  5:21             ` Eli Cohen
  2021-09-03 23:06               ` kokamoto
  0 siblings, 1 reply; 85+ messages in thread
From: Eli Cohen @ 2021-09-02  5:21 UTC (permalink / raw)
  To: 9fans

[-- Attachment #1: Type: text/plain, Size: 570 bytes --]

hey Kenji,

when I was putting the apk on my phone I used the "adb" tool. I don't
exactly remember the process... the phone has to be paired with the
computer running adb either over a USB cable or over wifi, then the apk can
be installed with adb. I do recall it being a bit difficult to get it
working right consistently...

- Eli

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-Mcbf7a2c5fb834f377c53c19a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 1159 bytes --]

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] Drawterm GPU (was: Software philosophy)
  2021-09-01  7:35         ` sirjofri
@ 2021-09-02  5:01           ` kokamoto
  2021-09-02  5:21             ` Eli Cohen
  0 siblings, 1 reply; 85+ messages in thread
From: kokamoto @ 2021-09-02  5:01 UTC (permalink / raw)
  To: 9fans

> This guide can help: 
> https://www.lifewire.com/install-apk-on-android-4177185

My phone is version 11, and made for Japanese (all the messages are Japanese),
which makes me difficult to follow it.   However, I'll do it soon...


> And there's the mouse offset bug. In my version it's almost the same 
> offset across the whole screen (y-axis), in the original the offset is 
> different.

I downloaded your cersion from https://github.com/sirjofri/drawterm-android.git,
and made it, somewhat different size of 777790.

Thank you very much.

Kenji


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-Mc8e9e426a772be6734bc3d7d
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] Drawterm GPU (was: Software philosophy)
  2021-09-01  0:29       ` kokamoto
@ 2021-09-01  7:35         ` sirjofri
  2021-09-02  5:01           ` kokamoto
  0 siblings, 1 reply; 85+ messages in thread
From: sirjofri @ 2021-09-01  7:35 UTC (permalink / raw)
  To: 9fans


01.09.2021 02:29:42 kokamoto@hera.eonet.ne.jp:
> By the way, I made your drawterm-android on my ubuntu-20.04.2 machine.
> My android is version 11, and made by Sony (SO-41B).
> I now have drawterm.apk file on my home directory, like 
> src/drawterm-android/drawterm.apk
> (size=777151).
>
> How I can install this to my android?
> I'm a novise user of android...

You have to copy the apk file to your android system and install there. 
If you haven't already stuff like f-droid installed you'll have to enable 
unknown sources in android. This guide can help: 
https://www.lifewire.com/install-apk-on-android-4177185


(Note, there are different solutions for different versions, and you can 
install apps using the adb, the usb android debugger, but I don't assume 
you want to use it.)

If you need other guides look for "install apk android (version)" or 
similar.

Btw there's a small known bug: when opening a connection the first time 
the app crashes silently. Opening it a second time it works without 
issues.

And there's the mouse offset bug. In my version it's almost the same 
offset across the whole screen (y-axis), in the original the offset is 
different.

Good luck

sirjofri

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-M22491d1fc47b10f157bfe87f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] Drawterm GPU (was: Software philosophy)
  2021-08-22 13:53     ` Eli Cohen
@ 2021-09-01  0:29       ` kokamoto
  2021-09-01  7:35         ` sirjofri
  0 siblings, 1 reply; 85+ messages in thread
From: kokamoto @ 2021-09-01  0:29 UTC (permalink / raw)
  To: 9fans


By the way, I made your drawterm-android on my ubuntu-20.04.2 machine.
My android is version 11, and made by Sony (SO-41B).
I now have drawterm.apk file on my home directory, like src/drawterm-android/drawterm.apk
(size=777151).

How I can install this to my android?
I'm a novise user of android...

Kenji


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-M01aa21d85ff8b03cc3f66aa0
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] Drawterm GPU (was: Software philosophy)
  2021-08-23  4:13             ` Bakul Shah
@ 2021-08-23  5:23               ` sirjofri
  0 siblings, 0 replies; 85+ messages in thread
From: sirjofri @ 2021-08-23  5:23 UTC (permalink / raw)
  To: 9fans

Good morning,

GPUs are SIMD processors. The hundreds of cores are great for highly 
parallel calculation.

In GLSL/HLSL I can write a program which is calculated for a very small 
set of pixels (usually 2x2 or 1x1). So if you have  a resolution of 10x10 
the program is basically run 5x5=25 or 10x10=100 times in parallel. Boost 
the resolution to more real values like 1080p you see how the many cores 
benefit the whole calculation.

This high parallelization can only really happen because most stuff is 
independent. For example, when raytracing each ray is (almost) 
independent of other rays.

Still, the 2x2 matrix is often calculated dependently because for 
texturing (and mip mapping) you need the "distance" between two pixels in 
a fragment shader. This is why (for texturing) you may end up having 
slower programs and some waiting time between some threads, because 
sometimes you need the value of the neighbor thread and have to wait 
until it's calculated.

Well, these are very language-specific details that are important for 
graphics, but apply similarly to other use cases. I can imagine that for 
neural networks you can just write the code for one node nad execute it 
500 times for 500 nodes in parallel. Imagine having this beast on the CPU 
with just 4 cores...

I hope this helps you understand how GPU cores ("shaders") work.

Vulkan would indeed be interesting. Since we are only interested in the 
compute part it might even make our programs really small, the "hello 
world" part of drawing triangles would be the "client" side (writing a 
rasterizer, raymarcher, tracer, whatever). It could still be a lot lines 
of code, but maybe we still benefit from the 10% speedup.

I still have to understand how all this "shader compilation" stuff works. 
In webgl it's like, "here's my code, make a shader from it, then I tell 
you it's a fragment shader". Shader compilation happens automatically. In 
UE shader compilation takes a long time, and I believe also in blender 
shaders are stored in a precompiled binaries.

sirjofri

23.08.2021 06:13:53 Bakul Shah <bakul@iitbombay.org>:

> Don't high end GPUs have thousands of "cores"? Even high end CPUs don't 
> have more than a few dozen cores to 128 or so. While each kind's cores 
> are very different, seems to me GPU/CPU paths have diverged for good. 
> Or we need some massive shift in programming languages + compilers. I 
> lack imagination how. Still, the thought of the CPUs gaining the 
> complexity of the graphics engine scares me!
>
> -- Bakul
>
> On Aug 22, 2021, at 12:09 PM, Paul Lalonde <paul.a.lalonde@gmail.com> 
> wrote:
>
> I'm pretty sure we're still re-inventing, though it's the CPU's turn to 
> gain some of the complexity of the graphics engine.
>
> Paul
>
> On Sun, Aug 22, 2021, 12:05 PM Bakul Shah <bakul@iitbombay.org> wrote:
>> Thanks. Looks like Sutherland's "Wheel of 
>> Reincarnation[https://www2.cs.arizona.edu/~cscheid/reading/myer-sutherland-design-of-display-processors.pdf]" 
>> has not only stopped but exploded :-) Or stopped being applicable.
>>
>> -- Bakul
>>
>> On Aug 22, 2021, at 9:23 AM, Paul Lalonde <paul.a.lalonde@gmail.com> 
>> wrote:
>>
>> It got complicated because there's no stable interface or ISA.  The 
>> hardware evolved from fixed-function to programmable in a commercial 
>> environment where the only meaningful measure was raw performance per 
>> dollar at many price points.  Every year the hardware spins and 
>> becomes more performant, usually faster than Moore's law.  With 3D 
>> APIs hiding the hardware details there is no pressure to make the 
>> hardware interface uniform, pretty, or neat.  And with the need for 
>> performance there are dozens of fixed function units that effectively 
>> need their own sub-drivers while coordinating at high performance with 
>> the other units. 
>> The system diagrams for GPUs look complex, but they are radical 
>> simplifications of what's really on the inside.
>>
>> Intel really pioneered the open driver stacks, but performance 
>> generally wasn't there.  That might be changing now, but I don't know 
>> if their recently announced discrete product line will be 
>> driver-compatible.
>>
>> Paul
>>
>>
>> On Sun, Aug 22, 2021 at 8:48 AM Bakul Shah <bakul@iitbombay.org> 
>> wrote:
>>> The FreeBSD amdgpu.ko is over 3Mbytes of compiled code. Not counting 
>>> the "firmware" that gets loaded on the GPU board. drm/amd/amdgpu has 
>>> 200K+ lines of source code. drm/amd over 2M lines of code. Intel's 
>>> i915 seems to be about 1/10th the amd size. AIUI, this is linux GPU 
>>> driver code, more or less unchanged (FreeBSD has shim code to use 
>>> it). How did the interface to an SIMD processor get so complicated?
>>>
>>> …
>>>
>>>
>>>
>>> -- Bakul
>>>
>
>
> *9fans[https://9fans.topicbox.com/latest]* / 9fans / see 
> discussions[https://9fans.topicbox.com/groups/9fans] + 
> participants[https://9fans.topicbox.com/groups/9fans/members] + 
> delivery options[https://9fans.topicbox.com/groups/9fans/subscription] 
> Permalink[https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-Me78513510ae4df2da186c73a]

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-M40ea45711a1551fd53807b84
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] Drawterm GPU (was: Software philosophy)
  2021-08-22 19:09           ` Paul Lalonde
@ 2021-08-23  4:13             ` Bakul Shah
  2021-08-23  5:23               ` sirjofri
  0 siblings, 1 reply; 85+ messages in thread
From: Bakul Shah @ 2021-08-23  4:13 UTC (permalink / raw)
  To: 9fans

[-- Attachment #1: Type: text/plain, Size: 6071 bytes --]

Don't high end GPUs have thousands of "cores"? Even high end CPUs don't have more than a few dozen cores to 128 or so. While each kind's cores are very different, seems to me GPU/CPU paths have diverged for good. Or we need some massive shift in programming languages + compilers. I lack imagination how. Still, the thought of the CPUs gaining the complexity of the graphics engine scares me!

-- Bakul

> On Aug 22, 2021, at 12:09 PM, Paul Lalonde <paul.a.lalonde@gmail.com> wrote:
> 
> I'm pretty sure we're still re-inventing, though it's the CPU's turn to gain some of the complexity of the graphics engine.
> 
> Paul
> 
> On Sun, Aug 22, 2021, 12:05 PM Bakul Shah <bakul@iitbombay.org <mailto:bakul@iitbombay.org>> wrote:
> Thanks. Looks like Sutherland's "Wheel of Reincarnation <https://www2.cs.arizona.edu/~cscheid/reading/myer-sutherland-design-of-display-processors.pdf>" has not only stopped but exploded :-) Or stopped being applicable.
> 
> -- Bakul
> 
>> On Aug 22, 2021, at 9:23 AM, Paul Lalonde <paul.a.lalonde@gmail.com <mailto:paul.a.lalonde@gmail.com>> wrote:
>> 
>> It got complicated because there's no stable interface or ISA.  The hardware evolved from fixed-function to programmable in a commercial environment where the only meaningful measure was raw performance per dollar at many price points.  Every year the hardware spins and becomes more performant, usually faster than Moore's law.  With 3D APIs hiding the hardware details there is no pressure to make the hardware interface uniform, pretty, or neat.  And with the need for performance there are dozens of fixed function units that effectively need their own sub-drivers while coordinating at high performance with the other units. 
>> The system diagrams for GPUs look complex, but they are radical simplifications of what's really on the inside.
>> 
>> Intel really pioneered the open driver stacks, but performance generally wasn't there.  That might be changing now, but I don't know if their recently announced discrete product line will be driver-compatible.
>> 
>> Paul
>> 
>> 
>> On Sun, Aug 22, 2021 at 8:48 AM Bakul Shah <bakul@iitbombay.org <mailto:bakul@iitbombay.org>> wrote:
>> The FreeBSD amdgpu.ko is over 3Mbytes of compiled code. Not counting the "firmware" that gets loaded on the GPU board. drm/amd/amdgpu has 200K+ lines of source code. drm/amd over 2M lines of code. Intel's i915 seems to be about 1/10th the amd size. AIUI, this is linux GPU driver code, more or less unchanged (FreeBSD has shim code to use it). How did the interface to an SIMD processor get so complicated?
>> 
>>> On Aug 22, 2021, at 6:44 AM, Paul Lalonde <paul.a.lalonde@gmail.com <mailto:paul.a.lalonde@gmail.com>> wrote:
>>> 
>>> I'd love to see  GPU support for Plan9.  This discussion falls right into my professional capacity.  I'll say that people generally *grossly* underestimate the complexity of a modern GPU and of its supporting software stack.  The GPU driver is effectively a second operating system with shared memory and DMA interfaces to the host.  Even bringing up a modern GPU for just compute tasks is a very large endeavour.
>>> 
>>> That being said, if you want real hardware support, the best place to start is currently AMD's open-source stack.  Ignoring the Vulkan bit, understanding their platform abstraction layer (PAL) and shader ISA (https://developer.amd.com/wp-content/resources/Vega_Shader_ISA_28July2017.pdf <https://developer.amd.com/wp-content/resources/Vega_Shader_ISA_28July2017.pdf>) is the base.  The lower hardware levels are reasonably well-described in linux's libdrm and its AMD support in amdgpu.
>>> 
>>> Opinions on how to bring this to Plan9?  I don't really have any - it's a huge pile of work with minimal benefit.  If you're looking for lightweight graphics, WebGL is a doable path, and almost certainly the right way to experiment with Plan9-like interfaces to graphics hardware.
>>> 
>>> Paul
>>> 
>>> 
>>> 
>>> On Sun, Aug 22, 2021 at 5:30 AM sirjofri <sirjofri+ml-9fans@sirjofri.de <mailto:sirjofri%2Bml-9fans@sirjofri.de>> wrote:
>>> 
>>> 22.08.2021 14:10:20 Stuart Morrow <morrow.stuart@gmail.com <mailto:morrow.stuart@gmail.com>>:
>>> > Also:
>>> >> people have discussed that for years
>>> >
>>> > They have?  I mean I might have seen occasionally someone vaguely
>>> > going "some sort of GPU support would be cool to have".  That isn't
>>> > discussion.
>>> 
>>> I've even heard of someone actually making GPU stuff work on plan 9. I've 
>>> only heard from their partner, who made a cute glenda thing on a piece of 
>>> cloth. I chatted with her a little and told her she should encourage her 
>>> partner for some discussion about this in our channels. It looked like 
>>> it's some academic work, but I don't know any details about it.
>>> 
>>> Worst case, someone already has a proper and good GPU implementation for 
>>> Plan 9 and nobody knows about it.
>>> 
>>> sirjofri
>>> 
>>> Btw if the said person reads this: it would be nice to learn some 
>>> details.
>>> 
>>> ------------------------------------------
>>> 9fans: 9fans
>>> Permalink: https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-Md3d5cd693c12f948ad4720bc <https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-Md3d5cd693c12f948ad4720bc>
>>> Delivery options: https://9fans.topicbox.com/groups/9fans/subscription <https://9fans.topicbox.com/groups/9fans/subscription>
>> 
>> 
>> 
>> -- Bakul
>> 
> 
> 9fans <https://9fans.topicbox.com/latest> / 9fans / see discussions <https://9fans.topicbox.com/groups/9fans> + participants <https://9fans.topicbox.com/groups/9fans/members> + delivery options <https://9fans.topicbox.com/groups/9fans/subscription>Permalink <https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-M6309d0d2644e0651e74b9901>

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-Me78513510ae4df2da186c73a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 9424 bytes --]

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] Drawterm GPU (was: Software philosophy)
  2021-08-22 18:25         ` ori
  2021-08-22 18:50           ` sirjofri
@ 2021-08-22 21:10           ` Philip Silva via 9fans
  1 sibling, 0 replies; 85+ messages in thread
From: Philip Silva via 9fans @ 2021-08-22 21:10 UTC (permalink / raw)
  To: 9fans

Vulkan (at least its promises) looks interesting though. As far as I understand it's more like a Meta API, really low-level and it claims to be very portable. But as mentioned before, the Hello Worlds are really long, apparently it's rather >1000 lines instead of "just" >100 for OpenGL.

On the other hand for driver development it might be less effort but seems to have its own pitfalls. (This is the only article I found about the driver aspect of it: https://lwn.net/Articles/702021/)

> > But for serious 3d AAA stuff we'd have to consider: Lumen is for next-gen
> >
> > GPUs and Nanite for newer GPUs. We'll never reach their quality in
> >
> > realtime if we don't use the GPU features (built-in rasterizer, ...) to
> >
> > have enough free power for crazy software calculation.
>
> By the time any code is written, next-gen GPUs will be
>
> previous-gen GPUs.
>
> General compute is what any hardware you buy a few years
>
> from now will be doing -- and it's far more intersting
>
> in terms of what capabilities it allows.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-Mc570eb4778bbb92d838c9b3c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] Drawterm GPU (was: Software philosophy)
  2021-08-22 19:04         ` Bakul Shah
@ 2021-08-22 19:09           ` Paul Lalonde
  2021-08-23  4:13             ` Bakul Shah
  0 siblings, 1 reply; 85+ messages in thread
From: Paul Lalonde @ 2021-08-22 19:09 UTC (permalink / raw)
  To: 9fans

[-- Attachment #1: Type: text/plain, Size: 5009 bytes --]

I'm pretty sure we're still re-inventing, though it's the CPU's turn to
gain some of the complexity of the graphics engine.

Paul

On Sun, Aug 22, 2021, 12:05 PM Bakul Shah <bakul@iitbombay.org> wrote:

> Thanks. Looks like Sutherland's "Wheel of Reincarnation
> <https://www2.cs.arizona.edu/~cscheid/reading/myer-sutherland-design-of-display-processors.pdf>"
> has not only stopped but exploded :-) Or stopped being applicable.
>
> -- Bakul
>
> On Aug 22, 2021, at 9:23 AM, Paul Lalonde <paul.a.lalonde@gmail.com>
> wrote:
>
> It got complicated because there's no stable interface or ISA.  The
> hardware evolved from fixed-function to programmable in a commercial
> environment where the only meaningful measure was raw performance per
> dollar at many price points.  Every year the hardware spins and becomes
> more performant, usually faster than Moore's law.  With 3D APIs hiding the
> hardware details there is no pressure to make the hardware interface
> uniform, pretty, or neat.  And with the need for performance there are
> dozens of fixed function units that effectively need their own sub-drivers
> while coordinating at high performance with the other units.
> The system diagrams for GPUs look complex, but they are radical
> simplifications of what's really on the inside.
>
> Intel really pioneered the open driver stacks, but performance generally
> wasn't there.  That might be changing now, but I don't know if their
> recently announced discrete product line will be driver-compatible.
>
> Paul
>
>
> On Sun, Aug 22, 2021 at 8:48 AM Bakul Shah <bakul@iitbombay.org> wrote:
>
>> The FreeBSD amdgpu.ko is over 3Mbytes of compiled code. Not counting the
>> "firmware" that gets loaded on the GPU board. drm/amd/amdgpu has 200K+
>> lines of source code. drm/amd over 2M lines of code. Intel's i915 seems to
>> be about 1/10th the amd size. AIUI, this is linux GPU driver code, more or
>> less unchanged (FreeBSD has shim code to use it). How did the interface to
>> an SIMD processor get so complicated?
>>
>> On Aug 22, 2021, at 6:44 AM, Paul Lalonde <paul.a.lalonde@gmail.com>
>> wrote:
>>
>> I'd love to see  GPU support for Plan9.  This discussion falls right into
>> my professional capacity.  I'll say that people generally *grossly*
>> underestimate the complexity of a modern GPU and of its supporting software
>> stack.  The GPU driver is effectively a second operating system with shared
>> memory and DMA interfaces to the host.  Even bringing up a modern GPU for
>> just compute tasks is a very large endeavour.
>>
>> That being said, if you want real hardware support, the best place to
>> start is currently AMD's open-source stack.  Ignoring the Vulkan bit,
>> understanding their platform abstraction layer (PAL) and shader ISA (
>> https://developer.amd.com/wp-content/resources/Vega_Shader_ISA_28July2017.pdf)
>> is the base.  The lower hardware levels are reasonably well-described in
>> linux's libdrm and its AMD support in amdgpu.
>>
>> Opinions on how to bring this to Plan9?  I don't really have any - it's a
>> huge pile of work with minimal benefit.  If you're looking for lightweight
>> graphics, WebGL is a doable path, and almost certainly the right way to
>> experiment with Plan9-like interfaces to graphics hardware.
>>
>> Paul
>>
>>
>>
>> On Sun, Aug 22, 2021 at 5:30 AM sirjofri <sirjofri+ml-9fans@sirjofri.de>
>> wrote:
>>
>>>
>>> 22.08.2021 14:10:20 Stuart Morrow <morrow.stuart@gmail.com>:
>>> > Also:
>>> >> people have discussed that for years
>>> >
>>> > They have?  I mean I might have seen occasionally someone vaguely
>>> > going "some sort of GPU support would be cool to have".  That isn't
>>> > discussion.
>>> 
>>> I've even heard of someone actually making GPU stuff work on plan 9.
>>> I've
>>> only heard from their partner, who made a cute glenda thing on a piece
>>> of
>>> cloth. I chatted with her a little and told her she should encourage her
>>> partner for some discussion about this in our channels. It looked like
>>> it's some academic work, but I don't know any details about it.
>>> 
>>> Worst case, someone already has a proper and good GPU implementation for
>>> Plan 9 and nobody knows about it.
>>> 
>>> sirjofri
>>> 
>>> Btw if the said person reads this: it would be nice to learn some
>>> details.
>>
>>
>>
>> -- Bakul
>>
>>
> *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions
> <https://9fans.topicbox.com/groups/9fans> + participants
> <https://9fans.topicbox.com/groups/9fans/members> + delivery options
> <https://9fans.topicbox.com/groups/9fans/subscription> Permalink
> <https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-M69dfd52c6b6d85727b06d9dc>
>

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-M6309d0d2644e0651e74b9901
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 7518 bytes --]

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] Drawterm GPU (was: Software philosophy)
  2021-08-22 16:23       ` Paul Lalonde
@ 2021-08-22 19:04         ` Bakul Shah
  2021-08-22 19:09           ` Paul Lalonde
  0 siblings, 1 reply; 85+ messages in thread
From: Bakul Shah @ 2021-08-22 19:04 UTC (permalink / raw)
  To: 9fans

[-- Attachment #1: Type: text/plain, Size: 5229 bytes --]

Thanks. Looks like Sutherland's "Wheel of Reincarnation <https://www2.cs.arizona.edu/~cscheid/reading/myer-sutherland-design-of-display-processors.pdf>" has not only stopped but exploded :-) Or stopped being applicable.

-- Bakul

> On Aug 22, 2021, at 9:23 AM, Paul Lalonde <paul.a.lalonde@gmail.com> wrote:
> 
> It got complicated because there's no stable interface or ISA.  The hardware evolved from fixed-function to programmable in a commercial environment where the only meaningful measure was raw performance per dollar at many price points.  Every year the hardware spins and becomes more performant, usually faster than Moore's law.  With 3D APIs hiding the hardware details there is no pressure to make the hardware interface uniform, pretty, or neat.  And with the need for performance there are dozens of fixed function units that effectively need their own sub-drivers while coordinating at high performance with the other units. 
> The system diagrams for GPUs look complex, but they are radical simplifications of what's really on the inside.
> 
> Intel really pioneered the open driver stacks, but performance generally wasn't there.  That might be changing now, but I don't know if their recently announced discrete product line will be driver-compatible.
> 
> Paul
> 
> 
> On Sun, Aug 22, 2021 at 8:48 AM Bakul Shah <bakul@iitbombay.org <mailto:bakul@iitbombay.org>> wrote:
> The FreeBSD amdgpu.ko is over 3Mbytes of compiled code. Not counting the "firmware" that gets loaded on the GPU board. drm/amd/amdgpu has 200K+ lines of source code. drm/amd over 2M lines of code. Intel's i915 seems to be about 1/10th the amd size. AIUI, this is linux GPU driver code, more or less unchanged (FreeBSD has shim code to use it). How did the interface to an SIMD processor get so complicated?
> 
>> On Aug 22, 2021, at 6:44 AM, Paul Lalonde <paul.a.lalonde@gmail.com <mailto:paul.a.lalonde@gmail.com>> wrote:
>> 
>> I'd love to see  GPU support for Plan9.  This discussion falls right into my professional capacity.  I'll say that people generally *grossly* underestimate the complexity of a modern GPU and of its supporting software stack.  The GPU driver is effectively a second operating system with shared memory and DMA interfaces to the host.  Even bringing up a modern GPU for just compute tasks is a very large endeavour.
>> 
>> That being said, if you want real hardware support, the best place to start is currently AMD's open-source stack.  Ignoring the Vulkan bit, understanding their platform abstraction layer (PAL) and shader ISA (https://developer.amd.com/wp-content/resources/Vega_Shader_ISA_28July2017.pdf <https://developer.amd.com/wp-content/resources/Vega_Shader_ISA_28July2017.pdf>) is the base.  The lower hardware levels are reasonably well-described in linux's libdrm and its AMD support in amdgpu.
>> 
>> Opinions on how to bring this to Plan9?  I don't really have any - it's a huge pile of work with minimal benefit.  If you're looking for lightweight graphics, WebGL is a doable path, and almost certainly the right way to experiment with Plan9-like interfaces to graphics hardware.
>> 
>> Paul
>> 
>> 
>> 
>> On Sun, Aug 22, 2021 at 5:30 AM sirjofri <sirjofri+ml-9fans@sirjofri.de <mailto:sirjofri%2Bml-9fans@sirjofri.de>> wrote:
>> 
>> 22.08.2021 14:10:20 Stuart Morrow <morrow.stuart@gmail.com <mailto:morrow.stuart@gmail.com>>:
>> > Also:
>> >> people have discussed that for years
>> >
>> > They have?  I mean I might have seen occasionally someone vaguely
>> > going "some sort of GPU support would be cool to have".  That isn't
>> > discussion.
>> 
>> I've even heard of someone actually making GPU stuff work on plan 9. I've 
>> only heard from their partner, who made a cute glenda thing on a piece of 
>> cloth. I chatted with her a little and told her she should encourage her 
>> partner for some discussion about this in our channels. It looked like 
>> it's some academic work, but I don't know any details about it.
>> 
>> Worst case, someone already has a proper and good GPU implementation for 
>> Plan 9 and nobody knows about it.
>> 
>> sirjofri
>> 
>> Btw if the said person reads this: it would be nice to learn some 
>> details.
>> 
>> ------------------------------------------
>> 9fans: 9fans
>> Permalink: https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-Md3d5cd693c12f948ad4720bc <https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-Md3d5cd693c12f948ad4720bc>
>> Delivery options: https://9fans.topicbox.com/groups/9fans/subscription <https://9fans.topicbox.com/groups/9fans/subscription>
> 
> 
> 
> -- Bakul
> 
> 9fans <https://9fans.topicbox.com/latest> / 9fans / see discussions <https://9fans.topicbox.com/groups/9fans> + participants <https://9fans.topicbox.com/groups/9fans/members> + delivery options <https://9fans.topicbox.com/groups/9fans/subscription>Permalink <https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-M1a557f299e542dc652b550b8>

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-M69dfd52c6b6d85727b06d9dc
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 7843 bytes --]

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] Drawterm GPU (was: Software philosophy)
  2021-08-22 18:25         ` ori
@ 2021-08-22 18:50           ` sirjofri
  2021-09-24  1:50             ` Frank D. Engel, Jr.
  2021-08-22 21:10           ` Philip Silva via 9fans
  1 sibling, 1 reply; 85+ messages in thread
From: sirjofri @ 2021-08-22 18:50 UTC (permalink / raw)
  To: 9fans


22.08.2021 20:25:12 ori@eigenstate.org:

> Quoth sirjofri <sirjofri+ml-9fans@sirjofri.de>:
>>
>> 22.08.2021 18:41:06 ori@eigenstate.org:
>> Basically do software rendering on the GPU?
>
> Yes. Or software neural net evaluation on the GPU.
> Or software video decoding on the GPU. Or software
> image transforms on the GPU. Or software signal
> processing on the GPU.
>
> If there's an interface to be selected, it needs
> to be tractable to implement, *and* general purpose
> enough for everything that wants to use it.
>
>> Well, it's totally possible. Even Nanite (the new system in Unreal 
>> Engine
>> 5) has its own rasterizer and I believe even its own base pass. Also
>> Lumen does software rendering for global illumination.
>>
>> But for serious 3d AAA stuff we'd have to consider: Lumen is for 
>> next-gen
>> GPUs and Nanite for newer GPUs. We'll never reach their quality in
>> realtime if we don't use the GPU features (built-in rasterizer, ...) 
>> to
>> have enough free power for crazy software calculation.
>
> By the time any code is written, next-gen GPUs will be
> previous-gen GPUs.
>
> General compute is what any hardware you buy a few years
> from now will be doing -- and it's far more intersting
> in terms of what capabilities it allows.
>
>> I like that /dev/compute approach, but may I suggest putting it below
>> another directory /dev/gpu/compute so we have the ability to add
>> /dev/gpu/{vertex,geometry,fragment,tessellation,pixel} later?
>
> I think supporting those is a cost we should not pay. It's
> fundamentally solving a less general problem, and adds a
> lot of complexity for the potential of a small performance
> boost.
>
> We already have zero people sinking time into the slim
> interface; sinking time into a fatter interface seems
> like a bad idea.

Gotcha.

Maybe I'll find some time to implement some kind of gpufs or /dev/gpu (if 
it's general purpose I'd suggest renaming compute to gpu since "compute" 
could be anything. The computer does compute, wow.).

sirjofri

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-M3c0e76a0b437dd9071c6f579
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] Drawterm GPU (was: Software philosophy)
  2021-08-22 17:29       ` sirjofri
@ 2021-08-22 18:25         ` ori
  2021-08-22 18:50           ` sirjofri
  2021-08-22 21:10           ` Philip Silva via 9fans
  0 siblings, 2 replies; 85+ messages in thread
From: ori @ 2021-08-22 18:25 UTC (permalink / raw)
  To: 9fans

Quoth sirjofri <sirjofri+ml-9fans@sirjofri.de>:
> 
> 22.08.2021 18:41:06 ori@eigenstate.org:
> Basically do software rendering on the GPU?

Yes. Or software neural net evaluation on the GPU.
Or software video decoding on the GPU. Or software
image transforms on the GPU. Or software signal
processing on the GPU.

If there's an interface to be selected, it needs
to be tractable to implement, *and* general purpose
enough for everything that wants to use it.

> Well, it's totally possible. Even Nanite (the new system in Unreal Engine 
> 5) has its own rasterizer and I believe even its own base pass. Also 
> Lumen does software rendering for global illumination.
> 
> But for serious 3d AAA stuff we'd have to consider: Lumen is for next-gen 
> GPUs and Nanite for newer GPUs. We'll never reach their quality in 
> realtime if we don't use the GPU features (built-in rasterizer, ...) to 
> have enough free power for crazy software calculation.

By the time any code is written, next-gen GPUs will be
previous-gen GPUs.

General compute is what any hardware you buy a few years
from now will be doing -- and it's far more intersting
in terms of what capabilities it allows.

> I like that /dev/compute approach, but may I suggest putting it below 
> another directory /dev/gpu/compute so we have the ability to add 
> /dev/gpu/{vertex,geometry,fragment,tessellation,pixel} later?

I think supporting those is a cost we should not pay. It's
fundamentally solving a less general problem, and adds a
lot of complexity for the potential of a small performance
boost.

We already have zero people sinking time into the slim
interface; sinking time into a fatter interface seems
like a bad idea.


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-M9436d5323abdd3522e9996aa
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] Drawterm GPU (was: Software philosophy)
  2021-08-22 16:41     ` ori
@ 2021-08-22 17:29       ` sirjofri
  2021-08-22 18:25         ` ori
  0 siblings, 1 reply; 85+ messages in thread
From: sirjofri @ 2021-08-22 17:29 UTC (permalink / raw)
  To: 9fans


22.08.2021 18:41:06 ori@eigenstate.org:

> Quoth Paul Lalonde <paul.a.lalonde@gmail.com>:
>> Opinions on how to bring this to Plan9?  I don't really have any - 
>> it's a
>> huge pile of work with minimal benefit.  If you're looking for 
>> lightweight
>> graphics, WebGL is a doable path, and almost certainly the right way 
>> to
>> experiment with Plan9-like interfaces to graphics hardware.
>
> It seems like the interesting part of GPUs
> is the general purpose computation. Writing
> an interface for pure computation seems like
> the way to go.
>
> Hardware rendering is a restricted case of
> software rendering; it seems like it would
> be better to write code that could do software
> rendering, and run it on the general purpose
> compute engine of the GPU. The same goes for
> basically everything else you may want to do
> with a GPU.

Basically do software rendering on the GPU?

Well, it's totally possible. Even Nanite (the new system in Unreal Engine 
5) has its own rasterizer and I believe even its own base pass. Also 
Lumen does software rendering for global illumination.

But for serious 3d AAA stuff we'd have to consider: Lumen is for next-gen 
GPUs and Nanite for newer GPUs. We'll never reach their quality in 
realtime if we don't use the GPU features (built-in rasterizer, ...) to 
have enough free power for crazy software calculation.

On the other hand, getting _any_ GPU computation running on Plan 9 would 
be great, even if it's just compatible pure-CPU implementation (aka gpufs 
without a GPU).

> Spitballing a while ago on the grid, I came
> up with something that looked a bit like a
> batch job interface, with a heirarchy that
> looks something like this:
>
>         /dev/compute
>                 new
>                 $func/new
>                 $func/$job/data
>                 $func/$job/result

I like that /dev/compute approach, but may I suggest putting it below 
another directory /dev/gpu/compute so we have the ability to add 
/dev/gpu/{vertex,geometry,fragment,tessellation,pixel} later?

I haven't looked at your sample script in more detail, but on the first 
glance it seems solid.

> Prototyping something like this as a 9p server
> on unix would be interesting. So would providing
> this kind of cpu interface in software.

This is also a great idea, instead of tweaking drawterm. I don't have a 
linux machine with a GPU (I'm full 9front and only windows for work), but 
I guess if this prototype uses OpenGL (or alt) it could also work with 
software GPU emulation.

I'd really like to try something like that, but writing filesystems is 
(still, sadly) new to me and I also don't have much time, being a 
full-time game developer.

If someone else wants to try it please make development open source so we 
can provide patches, and I'm also happy to at least test things.

> Hooking this up to devdraw would probably be
> interesting for doing "hardware" rendering, though
> latency may be an issue if it's not implemetned as
> a local '#' device.

I'm not sure about the latency (I would just try it once it's done), but 
can't we use the hwdraw stub function for interfacing with this? I also 
doubt we'll draw many complex shaders for /dev/draw.

sirjofri

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-Mf5ef60c88b77f937e3cd7c38
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] Drawterm GPU (was: Software philosophy)
  2021-08-22 14:57     ` sirjofri
@ 2021-08-22 16:45       ` ori
  0 siblings, 0 replies; 85+ messages in thread
From: ori @ 2021-08-22 16:45 UTC (permalink / raw)
  To: 9fans

Quoth sirjofri <sirjofri+ml-9fans@sirjofri.de>:
> Basically just a driver bridge between 9p and 
> OpenGL for example.

While that may be a neat hack, I think the way
forward is to *ignore* everything but the ability
to run arbitrary code. The alternative binds us
tightly to complex interfaces that we are unable
to control, and unwilling to implement ourselves.


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-M669861f673e387c2799da01b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] Drawterm GPU (was: Software philosophy)
  2021-08-22 13:44   ` Paul Lalonde
                       ` (2 preceding siblings ...)
  2021-08-22 15:47     ` Bakul Shah
@ 2021-08-22 16:41     ` ori
  2021-08-22 17:29       ` sirjofri
  3 siblings, 1 reply; 85+ messages in thread
From: ori @ 2021-08-22 16:41 UTC (permalink / raw)
  To: 9fans

Quoth Paul Lalonde <paul.a.lalonde@gmail.com>:
> Opinions on how to bring this to Plan9?  I don't really have any - it's a
> huge pile of work with minimal benefit.  If you're looking for lightweight
> graphics, WebGL is a doable path, and almost certainly the right way to
> experiment with Plan9-like interfaces to graphics hardware.

It seems like the interesting part of GPUs
is the general purpose computation. Writing
an interface for pure computation seems like
the way to go.

Hardware rendering is a restricted case of
software rendering; it seems like it would
be better to write code that could do software
rendering, and run it on the general purpose
compute engine of the GPU. The same goes for
basically everything else you may want to do
with a GPU.

It also seems like it may be both a more
useful and more long-lived tool.

Spitballing a while ago on the grid, I came
up with something that looked a bit like a
batch job interface, with a heirarchy that
looks something like this:

        /dev/compute
                new
                $func/new
                $func/$job/data
                $func/$job/result

which you could use from a script like so:

        #!/bin/rc
        # example:
        #
        # runs the neural net for finding cats,
        # which is compiled using some sort of
        # compiler backend that generates spirv,
        <[3=1] <>/dev/compute/new{
                # upload the code which can then
                # be run by the compute engine;
                # statically allocating resources
                # can simplify the driver.
                #
                # protocol would look something
                # like:
                #       "config param\n"
                #       "config param\n"
                #       "code\n"
                #       <spirv-oid bytecode>
                #       EOF
                filtdir=/dev/compute/`{sed 1q}
                echo alloc 8g
                echo code
                cat /bin/spir/catfinder

                # then launch a job, sending it
                # the arguments over the data
                # channel.
                #
                # it's up to the submitter and
                # the compute job to agreee on a
                # format; in this case, a single
                # uncompressed plan9 image is
                # written, and the result file
                # could contain a single string:
                # 'cat', 'not cat', or 'rifle'
                <>$dir/new{
                        jobdir=/dev/compute/`{sed 1q}
                        jpg -9 $i >$jobdir/data
                        cat $jobdir/result >[3]
                }
        }

Prototyping something like this as a 9p server
on unix would be interesting. So would providing
this kind of cpu interface in software.

Vmx could be extended with device passthrough
if you want to fit the entire thing on one box,
and then you may be able to find someone with
a bunch of time on their hands to write a basic
driver... maybe.

Hooking this up to devdraw would probably be
interesting for doing "hardware" rendering, though
latency may be an issue if it's not implemetned as
a local '#' device.

Anyways, this is fun to consider, but I've got
other more quotidian tools to work on before I even
think about thinking about this more :)


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-Mc5753788883d2ed17e4acdbd
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] Drawterm GPU (was: Software philosophy)
  2021-08-22 15:47     ` Bakul Shah
@ 2021-08-22 16:23       ` Paul Lalonde
  2021-08-22 19:04         ` Bakul Shah
  0 siblings, 1 reply; 85+ messages in thread
From: Paul Lalonde @ 2021-08-22 16:23 UTC (permalink / raw)
  To: 9fans

[-- Attachment #1: Type: text/plain, Size: 4353 bytes --]

It got complicated because there's no stable interface or ISA.  The
hardware evolved from fixed-function to programmable in a commercial
environment where the only meaningful measure was raw performance per
dollar at many price points.  Every year the hardware spins and becomes
more performant, usually faster than Moore's law.  With 3D APIs hiding the
hardware details there is no pressure to make the hardware interface
uniform, pretty, or neat.  And with the need for performance there are
dozens of fixed function units that effectively need their own sub-drivers
while coordinating at high performance with the other units.
The system diagrams for GPUs look complex, but they are radical
simplifications of what's really on the inside.

Intel really pioneered the open driver stacks, but performance generally
wasn't there.  That might be changing now, but I don't know if their
recently announced discrete product line will be driver-compatible.

Paul


On Sun, Aug 22, 2021 at 8:48 AM Bakul Shah <bakul@iitbombay.org> wrote:

> The FreeBSD amdgpu.ko is over 3Mbytes of compiled code. Not counting the
> "firmware" that gets loaded on the GPU board. drm/amd/amdgpu has 200K+
> lines of source code. drm/amd over 2M lines of code. Intel's i915 seems to
> be about 1/10th the amd size. AIUI, this is linux GPU driver code, more or
> less unchanged (FreeBSD has shim code to use it). How did the interface to
> an SIMD processor get so complicated?
>
> On Aug 22, 2021, at 6:44 AM, Paul Lalonde <paul.a.lalonde@gmail.com>
> wrote:
>
> I'd love to see  GPU support for Plan9.  This discussion falls right into
> my professional capacity.  I'll say that people generally *grossly*
> underestimate the complexity of a modern GPU and of its supporting software
> stack.  The GPU driver is effectively a second operating system with shared
> memory and DMA interfaces to the host.  Even bringing up a modern GPU for
> just compute tasks is a very large endeavour.
>
> That being said, if you want real hardware support, the best place to
> start is currently AMD's open-source stack.  Ignoring the Vulkan bit,
> understanding their platform abstraction layer (PAL) and shader ISA (
> https://developer.amd.com/wp-content/resources/Vega_Shader_ISA_28July2017.pdf)
> is the base.  The lower hardware levels are reasonably well-described in
> linux's libdrm and its AMD support in amdgpu.
>
> Opinions on how to bring this to Plan9?  I don't really have any - it's a
> huge pile of work with minimal benefit.  If you're looking for lightweight
> graphics, WebGL is a doable path, and almost certainly the right way to
> experiment with Plan9-like interfaces to graphics hardware.
>
> Paul
>
>
>
> On Sun, Aug 22, 2021 at 5:30 AM sirjofri <sirjofri+ml-9fans@sirjofri.de>
> wrote:
>
>>
>> 22.08.2021 14:10:20 Stuart Morrow <morrow.stuart@gmail.com>:
>> > Also:
>> >> people have discussed that for years
>> >
>> > They have?  I mean I might have seen occasionally someone vaguely
>> > going "some sort of GPU support would be cool to have".  That isn't
>> > discussion.
>> 
>> I've even heard of someone actually making GPU stuff work on plan 9. I've
>> only heard from their partner, who made a cute glenda thing on a piece of
>> cloth. I chatted with her a little and told her she should encourage her
>> partner for some discussion about this in our channels. It looked like
>> it's some academic work, but I don't know any details about it.
>> 
>> Worst case, someone already has a proper and good GPU implementation for
>> Plan 9 and nobody knows about it.
>> 
>> sirjofri
>> 
>> Btw if the said person reads this: it would be nice to learn some
>> details.
>
>
>
> -- Bakul
>
> *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions
> <https://9fans.topicbox.com/groups/9fans> + participants
> <https://9fans.topicbox.com/groups/9fans/members> + delivery options
> <https://9fans.topicbox.com/groups/9fans/subscription> Permalink
> <https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-M8658a330dbb6ca9a6e216777>
>

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-M1a557f299e542dc652b550b8
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 6293 bytes --]

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] Drawterm GPU (was: Software philosophy)
  2021-08-22 13:44   ` Paul Lalonde
  2021-08-22 13:53     ` Eli Cohen
  2021-08-22 14:57     ` sirjofri
@ 2021-08-22 15:47     ` Bakul Shah
  2021-08-22 16:23       ` Paul Lalonde
  2021-08-22 16:41     ` ori
  3 siblings, 1 reply; 85+ messages in thread
From: Bakul Shah @ 2021-08-22 15:47 UTC (permalink / raw)
  To: 9fans

[-- Attachment #1: Type: text/plain, Size: 3765 bytes --]

The FreeBSD amdgpu.ko is over 3Mbytes of compiled code. Not counting the "firmware" that gets loaded on the GPU board. drm/amd/amdgpu has 200K+ lines of source code. drm/amd over 2M lines of code. Intel's i915 seems to be about 1/10th the amd size. AIUI, this is linux GPU driver code, more or less unchanged (FreeBSD has shim code to use it). How did the interface to an SIMD processor get so complicated?

> On Aug 22, 2021, at 6:44 AM, Paul Lalonde <paul.a.lalonde@gmail.com <mailto:paul.a.lalonde@gmail.com>> wrote:
> 
> I'd love to see  GPU support for Plan9.  This discussion falls right into my professional capacity.  I'll say that people generally *grossly* underestimate the complexity of a modern GPU and of its supporting software stack.  The GPU driver is effectively a second operating system with shared memory and DMA interfaces to the host.  Even bringing up a modern GPU for just compute tasks is a very large endeavour.
> 
> That being said, if you want real hardware support, the best place to start is currently AMD's open-source stack.  Ignoring the Vulkan bit, understanding their platform abstraction layer (PAL) and shader ISA (https://developer.amd.com/wp-content/resources/Vega_Shader_ISA_28July2017.pdf <https://developer.amd.com/wp-content/resources/Vega_Shader_ISA_28July2017.pdf>) is the base.  The lower hardware levels are reasonably well-described in linux's libdrm and its AMD support in amdgpu.
> 
> Opinions on how to bring this to Plan9?  I don't really have any - it's a huge pile of work with minimal benefit.  If you're looking for lightweight graphics, WebGL is a doable path, and almost certainly the right way to experiment with Plan9-like interfaces to graphics hardware.
> 
> Paul
> 
> 
> 
> On Sun, Aug 22, 2021 at 5:30 AM sirjofri <sirjofri+ml-9fans@sirjofri.de <mailto:sirjofri%2Bml-9fans@sirjofri.de>> wrote:
> 
> 22.08.2021 14:10:20 Stuart Morrow <morrow.stuart@gmail.com <mailto:morrow.stuart@gmail.com>>:
> > Also:
> >> people have discussed that for years
> >
> > They have?  I mean I might have seen occasionally someone vaguely
> > going "some sort of GPU support would be cool to have".  That isn't
> > discussion.
> 
> I've even heard of someone actually making GPU stuff work on plan 9. I've 
> only heard from their partner, who made a cute glenda thing on a piece of 
> cloth. I chatted with her a little and told her she should encourage her 
> partner for some discussion about this in our channels. It looked like 
> it's some academic work, but I don't know any details about it.
> 
> Worst case, someone already has a proper and good GPU implementation for 
> Plan 9 and nobody knows about it.
> 
> sirjofri
> 
> Btw if the said person reads this: it would be nice to learn some 
> details.
> 
> ------------------------------------------
> 9fans: 9fans
> Permalink: https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-Md3d5cd693c12f948ad4720bc <https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-Md3d5cd693c12f948ad4720bc>
> Delivery options: https://9fans.topicbox.com/groups/9fans/subscription <https://9fans.topicbox.com/groups/9fans/subscription>
> 9fans <https://9fans.topicbox.com/latest> / 9fans / see discussions <https://9fans.topicbox.com/groups/9fans> + participants <https://9fans.topicbox.com/groups/9fans/members> + delivery options <https://9fans.topicbox.com/groups/9fans/subscription>Permalink <https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-M5f5fc3eff26e802047dbc69d>


-- Bakul


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-M8658a330dbb6ca9a6e216777
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 5679 bytes --]

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] Drawterm GPU (was: Software philosophy)
  2021-08-22 13:44   ` Paul Lalonde
  2021-08-22 13:53     ` Eli Cohen
@ 2021-08-22 14:57     ` sirjofri
  2021-08-22 16:45       ` ori
  2021-08-22 15:47     ` Bakul Shah
  2021-08-22 16:41     ` ori
  3 siblings, 1 reply; 85+ messages in thread
From: sirjofri @ 2021-08-22 14:57 UTC (permalink / raw)
  To: 9fans

The benefit of a drawterm GPU implementation is that you can basically 
use the whole driver pipeline of the underlying host OS. Eg for the 
windows version you can just write the software that uses the GPU driver. 
All programming effort will just be writing a graphics implementation and 
a proper 9p interface. Basically just a driver bridge between 9p and 
OpenGL for example.

sirjofri

22.08.2021 15:44:45 Paul Lalonde <paul.a.lalonde@gmail.com>:

> I'd love to see  GPU support for Plan9.  This discussion falls right 
> into my professional capacity.  I'll say that people generally 
> *grossly* underestimate the complexity of a modern GPU and of its 
> supporting software stack.  The GPU driver is effectively a second 
> operating system with shared memory and DMA interfaces to the host.  
> Even bringing up a modern GPU for just compute tasks is a very large 
> endeavour.
>
> That being said, if you want real hardware support, the best place to 
> start is currently AMD's open-source stack.  Ignoring the Vulkan bit, 
> understanding their platform abstraction layer (PAL) and shader ISA 
> (https://developer.amd.com/wp-content/resources/Vega_Shader_ISA_28July2017.pdf) 
> is the base.  The lower hardware levels are reasonably 
> well-described in linux's libdrm and its AMD support in amdgpu.
>
> Opinions on how to bring this to Plan9?  I don't really have any - it's 
> a huge pile of work with minimal benefit.  If you're looking for 
> lightweight graphics, WebGL is a doable path, and almost certainly the 
> right way to experiment with Plan9-like interfaces to graphics 
> hardware.
>
> Paul
>
>
>
> On Sun, Aug 22, 2021 at 5:30 AM sirjofri 
> <sirjofri+ml-9fans@sirjofri.de[sirjofri%2Bml-9fans@sirjofri.de]> wrote:
>>
>> 22.08.2021 14:10:20 Stuart Morrow <morrow.stuart@gmail.com>:
>>> Also:
>>>> people have discussed that for years
>>>
>>> They have?  I mean I might have seen occasionally someone vaguely
>>> going "some sort of GPU support would be cool to have".  That isn't
>>> discussion.
>> 
>> I've even heard of someone actually making GPU stuff work on plan 9.
>> I've
>> only heard from their partner, who made a cute glenda thing on a piece
>> of
>> cloth. I chatted with her a little and told her she should encourage
>> her
>> partner for some discussion about this in our channels. It looked like
>> it's some academic work, but I don't know any details about it.
>> 
>> Worst case, someone already has a proper and good GPU implementation
>> for
>> Plan 9 and nobody knows about it.
>> 
>> sirjofri
>> 
>> Btw if the said person reads this: it would be nice to learn some
>> details.
>
> *9fans[https://9fans.topicbox.com/latest]* / 9fans / see 
> discussions[https://9fans.topicbox.com/groups/9fans] + 
> participants[https://9fans.topicbox.com/groups/9fans/members] + 
> delivery options[https://9fans.topicbox.com/groups/9fans/subscription] 
> Permalink[https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-M5f5fc3eff26e802047dbc69d]

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-M620f53eecae429a368d102bf
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] Drawterm GPU (was: Software philosophy)
  2021-08-22 13:44   ` Paul Lalonde
@ 2021-08-22 13:53     ` Eli Cohen
  2021-09-01  0:29       ` kokamoto
  2021-08-22 14:57     ` sirjofri
                       ` (2 subsequent siblings)
  3 siblings, 1 reply; 85+ messages in thread
From: Eli Cohen @ 2021-08-22 13:53 UTC (permalink / raw)
  To: 9fans

I wasn't aware of open-source cards only for ML/NN... that's interesting.

I was just poking through the # drivers... as I recalled there was
something specifically for using the FPU, but now I can't figure that
out... I'm not sure where I saw that or thought that... that was more
what I was thinking, though.

On Sun, Aug 22, 2021 at 6:46 AM Paul Lalonde <paul.a.lalonde@gmail.com> wrote:
>
> I'd love to see  GPU support for Plan9.  This discussion falls right into my professional capacity.  I'll say that people generally *grossly* underestimate the complexity of a modern GPU and of its supporting software stack.  The GPU driver is effectively a second operating system with shared memory and DMA interfaces to the host.  Even bringing up a modern GPU for just compute tasks is a very large endeavour.
>
> That being said, if you want real hardware support, the best place to start is currently AMD's open-source stack.  Ignoring the Vulkan bit, understanding their platform abstraction layer (PAL) and shader ISA (https://developer.amd.com/wp-content/resources/Vega_Shader_ISA_28July2017.pdf) is the base.  The lower hardware levels are reasonably well-described in linux's libdrm and its AMD support in amdgpu.
>
> Opinions on how to bring this to Plan9?  I don't really have any - it's a huge pile of work with minimal benefit.  If you're looking for lightweight graphics, WebGL is a doable path, and almost certainly the right way to experiment with Plan9-like interfaces to graphics hardware.
>
> Paul
>
>
>
> On Sun, Aug 22, 2021 at 5:30 AM sirjofri <sirjofri+ml-9fans@sirjofri.de> wrote:
>>
>>
>> 22.08.2021 14:10:20 Stuart Morrow <morrow.stuart@gmail.com>:
>> > Also:
>> >> people have discussed that for years
>> >
>> > They have?  I mean I might have seen occasionally someone vaguely
>> > going "some sort of GPU support would be cool to have".  That isn't
>> > discussion.
>> 
>> I've even heard of someone actually making GPU stuff work on plan 9. I've
>> only heard from their partner, who made a cute glenda thing on a piece of
>> cloth. I chatted with her a little and told her she should encourage her
>> partner for some discussion about this in our channels. It looked like
>> it's some academic work, but I don't know any details about it.
>> 
>> Worst case, someone already has a proper and good GPU implementation for
>> Plan 9 and nobody knows about it.
>> 
>> sirjofri
>> 
>> Btw if the said person reads this: it would be nice to learn some
>> details.
>
> 9fans / 9fans / see discussions + participants + delivery options Permalink

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-Mdcb928be475cb614573450f3
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] Drawterm GPU (was: Software philosophy)
  2021-08-22 12:29 ` sirjofri
@ 2021-08-22 13:44   ` Paul Lalonde
  2021-08-22 13:53     ` Eli Cohen
                       ` (3 more replies)
  0 siblings, 4 replies; 85+ messages in thread
From: Paul Lalonde @ 2021-08-22 13:44 UTC (permalink / raw)
  To: 9fans

[-- Attachment #1: Type: text/plain, Size: 2329 bytes --]

I'd love to see  GPU support for Plan9.  This discussion falls right into
my professional capacity.  I'll say that people generally *grossly*
underestimate the complexity of a modern GPU and of its supporting software
stack.  The GPU driver is effectively a second operating system with shared
memory and DMA interfaces to the host.  Even bringing up a modern GPU for
just compute tasks is a very large endeavour.

That being said, if you want real hardware support, the best place to start
is currently AMD's open-source stack.  Ignoring the Vulkan bit,
understanding their platform abstraction layer (PAL) and shader ISA (
https://developer.amd.com/wp-content/resources/Vega_Shader_ISA_28July2017.pdf)
is the base.  The lower hardware levels are reasonably well-described in
linux's libdrm and its AMD support in amdgpu.

Opinions on how to bring this to Plan9?  I don't really have any - it's a
huge pile of work with minimal benefit.  If you're looking for lightweight
graphics, WebGL is a doable path, and almost certainly the right way to
experiment with Plan9-like interfaces to graphics hardware.

Paul



On Sun, Aug 22, 2021 at 5:30 AM sirjofri <sirjofri+ml-9fans@sirjofri.de>
wrote:

>
> 22.08.2021 14:10:20 Stuart Morrow <morrow.stuart@gmail.com>:
> > Also:
> >> people have discussed that for years
> >
> > They have?  I mean I might have seen occasionally someone vaguely
> > going "some sort of GPU support would be cool to have".  That isn't
> > discussion.
> 
> I've even heard of someone actually making GPU stuff work on plan 9. I've
> only heard from their partner, who made a cute glenda thing on a piece of
> cloth. I chatted with her a little and told her she should encourage her
> partner for some discussion about this in our channels. It looked like
> it's some academic work, but I don't know any details about it.
> 
> Worst case, someone already has a proper and good GPU implementation for
> Plan 9 and nobody knows about it.
> 
> sirjofri
> 
> Btw if the said person reads this: it would be nice to learn some
> details.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-M5f5fc3eff26e802047dbc69d
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 4014 bytes --]

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [9fans] Drawterm GPU (was: Software philosophy)
  2021-08-22 12:10 [9fans] Drawterm GPU (was: Software philosophy) Stuart Morrow
@ 2021-08-22 12:29 ` sirjofri
  2021-08-22 13:44   ` Paul Lalonde
  0 siblings, 1 reply; 85+ messages in thread
From: sirjofri @ 2021-08-22 12:29 UTC (permalink / raw)
  To: 9fans


22.08.2021 14:10:20 Stuart Morrow <morrow.stuart@gmail.com>:
> Also:
>> people have discussed that for years
>
> They have?  I mean I might have seen occasionally someone vaguely
> going "some sort of GPU support would be cool to have".  That isn't
> discussion.

I've even heard of someone actually making GPU stuff work on plan 9. I've 
only heard from their partner, who made a cute glenda thing on a piece of 
cloth. I chatted with her a little and told her she should encourage her 
partner for some discussion about this in our channels. It looked like 
it's some academic work, but I don't know any details about it.

Worst case, someone already has a proper and good GPU implementation for 
Plan 9 and nobody knows about it.

sirjofri

Btw if the said person reads this: it would be nice to learn some 
details.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-Md3d5cd693c12f948ad4720bc
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

* [9fans] Drawterm GPU (was: Software philosophy)
@ 2021-08-22 12:10 Stuart Morrow
  2021-08-22 12:29 ` sirjofri
  0 siblings, 1 reply; 85+ messages in thread
From: Stuart Morrow @ 2021-08-22 12:10 UTC (permalink / raw)
  To: 9fans

On 22/08/2021, Eli Cohen <echoline@gmail.com> wrote:
> 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!

There's virtio_gpu, which I assume is less hairy and better-documented
than real hardware. I think it's graphics-purpose-only. Maybe you'd be
better-off just supporting cards that *only* do ML/NN acceleration?
There's open-source ones.

Also:
> people have discussed that for years

They have?  I mean I might have seen occasionally someone vaguely
going "some sort of GPU support would be cool to have".  That isn't
discussion.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-M3cda662328b544acbd9fd894
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 85+ messages in thread

end of thread, other threads:[~2021-09-24  1:51 UTC | newest]

Thread overview: 85+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-08-16 11:15 [9fans] OAuth2 in factotum Demetrius Iatrakis
2021-08-17  3:48 ` Lucio De Re
2021-08-17  7:47   ` Keith Gibbs
2021-08-18  3:55     ` Lucio De Re
2021-08-18  7:02       ` [9fans] Software philosophy Skip Tavakkolian
2021-08-18  7:19         ` hiro
2021-08-18 10:15           ` Lucio De Re
2021-08-18  9:46         ` Keith Gibbs
2021-08-18 10:13         ` vic.thacker
2021-08-18 11:34           ` Keith Gibbs
2021-08-18 11:47             ` Lucio De Re
2021-08-18 23:44             ` hiro
2021-08-19  4:34               ` Lucio De Re
2021-08-19 10:44                 ` Keith Gibbs
2021-08-19 18:53                 ` Git & Conventional Browsers (Was Re: [9fans] Software philosophy) unobe
2021-08-19 19:00                   ` ori
2021-08-18 11:34           ` [9fans] Software philosophy Lucio De Re
2021-08-18 11:28         ` Lucio De Re
2021-08-18 12:02           ` Keith Gibbs
2021-08-18 19:33             ` leimy2k via 9fans
2021-08-18 20:09               ` David du Colombier
2021-08-18 22:00                 ` Eli Cohen
2021-08-19  7:08                   ` Keith Gibbs
2021-08-19  7:59                     ` sirjofri
2021-08-19  9:27                       ` Lucio De Re
2021-08-19  9:45                         ` hiro
2021-08-19  9:51                         ` hiro
2021-08-19 10:10                           ` sirjofri
2021-08-19 10:38                         ` Keith Gibbs
2021-08-19 11:45                           ` hiro
2021-08-19 12:43                             ` Eli Cohen
2021-08-19 19:58                               ` Aram Hăvărneanu
2021-08-19 10:56                         ` kvik
2021-08-19 11:33                           ` sirjofri
2021-08-19 20:44                           ` ori
2021-08-19  9:29                       ` hiro
2021-08-19  9:44                         ` sirjofri
2021-08-19  9:19                     ` hiro
2021-08-22  2:46                   ` kokamoto
2021-08-22  3:16                     ` Eli Cohen
2021-08-22  7:07                       ` [9fans] Drawterm GPU (was: Software philosophy) sirjofri
2021-08-22 10:04                         ` Frank D. Engel, Jr.
2021-08-22 11:49                           ` sirjofri
2021-08-22 12:24                             ` Chris McGee
2021-08-18  9:18       ` [9fans] OAuth2 in factotum Keith Gibbs
2021-08-18 12:10         ` Ethan Gardener
2021-08-18 15:23         ` Stuart Morrow
2021-08-18 16:58           ` Stuart Morrow
2021-08-18 17:06             ` Sigrid Solveig Haflínudóttir
2021-08-17 15:25   ` ori
2021-08-18  3:59     ` Lucio De Re
2021-08-18  4:20       ` ori
2021-08-18  4:42         ` Eli Cohen
2021-08-18  5:06         ` Lucio De Re
2021-08-17  4:13 ` ori
2021-08-17  5:43   ` Lucio De Re
2021-08-19  3:52 ` Kurt H Maier
2021-08-19  5:38 ` ori
2021-08-22 20:16 ` ori
2021-08-22 20:32   ` Demetrius Iatrakis
2021-08-22 20:38     ` ori
2021-08-22 20:36   ` ori
2021-08-22 12:10 [9fans] Drawterm GPU (was: Software philosophy) Stuart Morrow
2021-08-22 12:29 ` sirjofri
2021-08-22 13:44   ` Paul Lalonde
2021-08-22 13:53     ` Eli Cohen
2021-09-01  0:29       ` kokamoto
2021-09-01  7:35         ` sirjofri
2021-09-02  5:01           ` kokamoto
2021-09-02  5:21             ` Eli Cohen
2021-09-03 23:06               ` kokamoto
2021-08-22 14:57     ` sirjofri
2021-08-22 16:45       ` ori
2021-08-22 15:47     ` Bakul Shah
2021-08-22 16:23       ` Paul Lalonde
2021-08-22 19:04         ` Bakul Shah
2021-08-22 19:09           ` Paul Lalonde
2021-08-23  4:13             ` Bakul Shah
2021-08-23  5:23               ` sirjofri
2021-08-22 16:41     ` ori
2021-08-22 17:29       ` sirjofri
2021-08-22 18:25         ` ori
2021-08-22 18:50           ` sirjofri
2021-09-24  1:50             ` Frank D. Engel, Jr.
2021-08-22 21:10           ` Philip Silva via 9fans

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).