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

[Lucio De Re]

On 9/2/18, hiro <23h...@gmail.com> wrote:
> "prevailing wisdom" sounds like an oxymoron.
>
Yes, real wisdom is for some (evolutionary? counter-evolutionary?)
reason unlikely to prevail.

Go figure.

Lucio.

Re: [9fans] 9P or better file services for multiple platforms

[Lucio De Re]

On 9/2/18, hiro <23h...@gmail.com> wrote:
>
> i suppose you could check the individual blogs, possibly in an
> automated way by writing some one-liner rc and hget script and publish
> the outcome, plus keep it updated. then perhaps you can figure out if
> this is the kind of information currently lacking.
>
The book, the book! I think that's what I'll look into. We have Nemo's
commentary and of course Forsyth's (9) man pages, maybe a start would
be to condense knowledge in a "Tiger's" commentary of 9front. I can
already see the two columns of 9legacy and 9front code side by side
(the kernel isn't going to be enough, though, you guys have been way
too busy).

And, while I have your attention, I was a fan of Tanenbaum and Minix.
Is anyone here familiar with Minix v3? Thinking about, isn't a book
precisely what it takes to guarantee an OS eternal life?

Thanks for the thought, Hiro, in my dotage, when evening comes, my
thinking slows down beyond useful pondering, blogs may be just what I
need instead of television. That will almost certainly improve the
quality of my last years.

Lucio.

Re: [9fans] 9P or better file services for multiple platforms

[Lucio De Re]

On 9/3/18, Kurt H Maier  wrote:
> [ ... ]
>
> Most commonly, someone will mandate two-factor authentication, and
> kerberos tickets (usually via GSSAPI) are the back-end, regardless of
> which security tokens (RSA SecurID, smart cards, yubikeys, etc) are
> chosen.
>
Thanks, Kurt, I knew 9fans was a fountain of knowledge with, mostly,
just the right sprinkling of skepticism. Plus the humour, of course.

Lucio.

PS: I suffered a server failure, way back when, and returning to the
9fans fold took some determination. I'm not sure I'll be able to do
without 9fans any time soon.

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

[Skip Tavakkolian]

To me, one of the big advantages for Plan 9 is structural, not necessarily
related to C. There's no need to put everything in the kernel and one can
have different specialized kernels (e.g. kenfs), so long as the basic
protocols are followed.

On Sun, Sep 2, 2018 at 9:32 AM Chris McGee  wrote:

> Hi All,
>
> I'm reading this article about how they are going through the giant
> heaping pile of Linux kernel code and trying to come up with safer
> practices to avoid the "dangers" of C. The prevailing wisdom appears to be
> that things should eventually be rewritten in Rust some day.
>
> https://lwn.net/SubscriberLink/763641/c9a04da2a33af0a3/
>
> I'm curious how the Plan 9 C compiler fits into this story. I know that it
> was designed to avoid many of the pitfalls of standard C. Does it try to
> address some of these dangers or is it focused on making code more readable
> so that problems are more apparent?
>
> How does everyone feel about the Plan 9/9front kernel? Have they gone
> through hardening/testing exercises over the years? I'm curious what tools
> are available to help discover bugs.
>
> Cheers,
> Chris
>

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

[Charles Forsyth]

The Plan 9 C compiler doesn't take an insane view of the meaning of
"undefined behaviour", which makes a big difference.
It also assumes you know how to write loops if they need to be fast (which
frankly hasn't really mattered at the O/S level, esp on modern hardware),
so it won't "optimise" essential code out of your program by miscalculating
the ranges during "aggressive-loop-optimisation".
No doubt it could be better, but it could easily be worse.
The executable is also finite size, not unbounded-but-finite.
For a compiler of a language the size and complexity of C (without some
ANSI crud), I think it's not far off a size comparable to the language
complexity
(although it could be a bit smaller); meanwhile, by treating "compiling C"
as a subset problem of "compiling C++", gcc and especially clang are vast
whales whistling at the wrong frequency for the problem.

On Sun, 2 Sep 2018 at 20:23, Iruatã Souza  wrote:

> On 09/02/2018 09:31 AM, Chris McGee wrote:
> > I'm curious what
> > tools are available to help discover bugs.
> >
>
> Does simplicity and clarity count?
>
>

Re: [9fans] 9P or better file services for multiple platforms

[Kurt H Maier]

On Sun, Sep 02, 2018 at 08:09:55PM +0200, Lucio De Re wrote:
> On 9/2/18, Skip Tavakkolian  wrote:
> >
> > Regarding authentication and access control, I think the only *standard*
> > option for a mixed OS environment (Plan 9, Linux/*BSD, Windows) is
> > Kerberos.
> >
> Is that still actively used (I mean, outside of Microsoft's attempted
> hi-jacking)? In my Linux-prone wider environment, the name is never
> uttered.

Yes, it's extremely common in many business and government
environments.  All of linux's weird-ass authentication systems are
poorly-reinvented kerberos implementations, with the primary limitations
and pain points directly stemming from unix tropes.  Generally someone
comes up with a bad idea, everyone adopts it, and then that bad idea
slowly evolves as closely as it can to being kerberos.

Most commonly, someone will mandate two-factor authentication, and
kerberos tickets (usually via GSSAPI) are the back-end, regardless of
which security tokens (RSA SecurID, smart cards, yubikeys, etc) are
chosen.

khm

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

[Iruatã Souza]

On 09/02/2018 09:31 AM, Chris McGee wrote:
> I'm curious what
> tools are available to help discover bugs.
> 

Does simplicity and clarity count?

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

[Steve Simon]

the most significant change that plan9’s c made (that i can think of) is 
compile time type checking between modules /files.

this helps but is not a huge improvement to safety.

the main reasons plan9’s kernel is fairly safe is its clean and simple design, 
which makes problems less likely.

nothing cleverer than that (imho). Sorry, no magic.

-Steve


> On 2 Sep 2018, at 19:16, Lucio De Re  wrote:
> 
>> On 9/2/18, Chris McGee  wrote:
>> I'm reading this article about how they are going through the giant heaping
>> pile of Linux kernel code and trying to come up with safer practices to
>> avoid the "dangers" of C. The prevailing wisdom appears to be that things
>> should eventually be rewritten in Rust some day.
>> 
> Like hell they will! By the time they have even a minute portion of
> Linux running under a different language, the language-du-jour will
> have moved on. It's a monolith, it cannot be translated, unless it is
> mechanically. And we know how brilliant that is likely to be.
> 
>> How does everyone feel about the Plan 9/9front kernel? Have they gone
>> through hardening/testing exercises over the years? I'm curious what tools
>> are available to help discover bugs.
>> 
> Simplicity is Plan 9's most relevant trait here, but that's where you
> draw the line. If anyone feels like finding possible security holes in
> the Plan 9 or the 9front kernels, they have to have very strong
> motivation to do it. In general that motivation is spelled M-O-N-E-Y
> and no one is likely to find the 9 flavours worthy of a big lump of
> that resource.
> 
> My opinions, of course.
> 
> Lucio.

Re: [9fans] 9P or better file services for multiple platforms

[Ethan Gardener]

On Sun, Sep 2, 2018, at 7:24 PM, Lucio De Re wrote:
> You're here. Sometimes an audience is all the artist needs as the
> stimulus. How does it go? "They also serve...".

I probably shouldn't talk about all I've done for the sake of an audience. XD  
I tell myself I'm doing my latest project primarily for myself though.

Re: [9fans] 9P or better file services for multiple platforms

[Lucio De Re]

You're here. Sometimes an audience is all the artist needs as the
stimulus. How does it go? "They also serve...".

Lucio.

Re: [9fans] 9P or better file services for multiple platforms

[Ethan Gardener]

On Sun, Sep 2, 2018, at 7:02 PM, Lucio De Re wrote:
> On 9/2/18, Ethan Gardener  wrote:
> > I had a thought pertaining to the original topic.
> >
> [ ... ]
> >
> > FreeBSD has ZFS too, which of course offers snapshots, but it has so many
> > options that I found it a bit too much.  It seems well documented and the
> > interface seems reasonable for the feature set, but it's a big feature set.
> > I have a habit of trying to understand and use too much at once, I guess.
> >
> A personality analysis of 9fans I'm sure will reveal some traits that
> make us very much alike. A desire to get to the bottom of things would
> be one of those, is my guess.

Probably! :)

> Of course, it's simplistic. Thing is, if our community were to find a
> sufficiently capable leader, we'd be able to contribute immensely.
> It's unfortunate that such coordination doesn't naturally occur
> whenever the resources become available. But maybe the necessary
> catalyst will eventually materialise, before it's too late.
> 
> Here's to that hope.

I don't know.  cinap tried to teach me.  He's a good teacher, but he couldn't 
help me.  Things are looking up now I'm trying to improve my life generally, 
dealing with sources of stress instead of trying to block them out with a 
million distractions.  I'm cutting back to one hobby.  Unfortunately, it's not 
Plan 9, but it will share some ideas and I intend to make it run on Plan 9 when 
it runs at all.  Anyway, one hobby means anyone trying to get me to work on 
Plan 9 would be up against some stiff competition. :)

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

[Lucio De Re]

On 9/2/18, Chris McGee  wrote:
> I'm reading this article about how they are going through the giant heaping
> pile of Linux kernel code and trying to come up with safer practices to
> avoid the "dangers" of C. The prevailing wisdom appears to be that things
> should eventually be rewritten in Rust some day.
>
Like hell they will! By the time they have even a minute portion of
Linux running under a different language, the language-du-jour will
have moved on. It's a monolith, it cannot be translated, unless it is
mechanically. And we know how brilliant that is likely to be.

> How does everyone feel about the Plan 9/9front kernel? Have they gone
> through hardening/testing exercises over the years? I'm curious what tools
> are available to help discover bugs.
>
Simplicity is Plan 9's most relevant trait here, but that's where you
draw the line. If anyone feels like finding possible security holes in
the Plan 9 or the 9front kernels, they have to have very strong
motivation to do it. In general that motivation is spelled M-O-N-E-Y
and no one is likely to find the 9 flavours worthy of a big lump of
that resource.

My opinions, of course.

Lucio.

Re: [9fans] 9P or better file services for multiple platforms

[Lucio De Re]

On 9/2/18, Skip Tavakkolian  wrote:
>
> Regarding authentication and access control, I think the only *standard*
> option for a mixed OS environment (Plan 9, Linux/*BSD, Windows) is
> Kerberos.
>
Is that still actively used (I mean, outside of Microsoft's attempted
hi-jacking)? In my Linux-prone wider environment, the name is never
uttered.

> It would be great if factotum could handle Kerberos 5. There is a pure Go
> package (https://github.com/jcmturner/gokrb5) that could help. Of course,
> this would take some work.
>
Factotum deserves a research institute of its own. Every time I have
to change a password that has expired or have to look in my secstore
for one I have not used in a while, I wish I could add the few modules
I find lacking in factotum.

So much Plan 9 that comes just short of perfect, where everything else
is at best mediocre!

Lucio.

Re: [9fans] 9P or better file services for multiple platforms

[hiro]

> bringing divergent developments together

one big diversion one should not forget is inferno.
i would welcome if some efforts were put into synchronizing some of
the inferno and plan 9 changes and perhaps apply acquired wisdom that
stems from either project.

otherwise 9front doesn't try to divert at all. even some bell-labs
changes that were frowned upon and broke backwards compatibility were
imported into 9front bec. of the wish to stay compatible.

Re: [9fans] 9P or better file services for multiple platforms

[Lucio De Re]

On 9/2/18, Ethan Gardener  wrote:
> I had a thought pertaining to the original topic.
>
[ ... ]
>
> FreeBSD has ZFS too, which of course offers snapshots, but it has so many
> options that I found it a bit too much.  It seems well documented and the
> interface seems reasonable for the feature set, but it's a big feature set.
> I have a habit of trying to understand and use too much at once, I guess.
>
A personality analysis of 9fans I'm sure will reveal some traits that
make us very much alike. A desire to get to the bottom of things would
be one of those, is my guess.

Of course, it's simplistic. Thing is, if our community were to find a
sufficiently capable leader, we'd be able to contribute immensely.
It's unfortunate that such coordination doesn't naturally occur
whenever the resources become available. But maybe the necessary
catalyst will eventually materialise, before it's too late.

Here's to that hope.

Lucio.

Re: [9fans] 9P or better file services for multiple platforms

[hiro]

> Of course, you're sadly right.

I don't know what's so sad to you.

apart from all other developers having left and work for google now.

Re: [9fans] 9P or better file services for multiple platforms

[Lucio De Re]

On 9/2/18, Skip Tavakkolian  wrote:
> Have you considered using AoE (Coraid)? It would require dedicated fossil,
> NFS CIFS servers, but they'd all be sharing the storage -- Coraid supports
> ext4 and NTFS. Most servers have multiple NICs, which makes a dedicated LAN
> for AoE traffic easy.
>
I have, many times, Skip.

I was told once or twice that is money is the only obstacle between me
and success, then there is no obstacle at all, but my ability to grow
debt or at least keep it at the permanent level my bank tolerates from
me, is at least one factor against having any Coraid kit in my space.

I think that is the greatest regret I have, by far. Coraid kit should
be listed as a non-negotiable human right.

Lucio.

Re: [9fans] 9P or better file services for multiple platforms

[Lucio De Re]

On 9/2/18, hiro <23h...@gmail.com> wrote:
> The way I inform myself of valuable contributions to plan 9 these days
> is by watching 9front commit logs and the #cat-v irc channel.
>
> If there are any valuable commits in David's repository that we should
> apply, please inform us.
>
I was waiting for the real Hiro to pop out .

Of course, you're sadly right. On the merit side, 9legacy is
frighteningly stable (ask me, I ain't changed a thing in years), so it
is eminently ready to absorb 9front's commits, if only the effort did
not reduce 9legacy to a stuttering idiot.

Small as Plan 9 is, bringing divergent developments together requires
that scarce resource called humility on all sides. I can only beat
humility into others, no risk of swallowing a dose of it for my own
edification.

No, I am joking, which is another side of Plan 9 I cherish: few, if
anyone at all have their livelihood dependent on Plan 9. I actually
can fake humility better than I can fake just about anything else and
people do accept it as real. That's good enough.

To return to 9legacy versus 9front, I'm totally incompetent at this
point, but I'm hoping to familiarise myself with 9front fairly soon,
it is too inviting. But my loyalty to the original Plan 9 source is
very strong, it's hard to tell how it will pan out.

In the meantime, I do have answers I need to pursue, and this is as
good an opportunity as any to say thanks to all who have reply and I
look forward to hearing even the smallest tidbits that may illuminate
the way forward. Unknown to the majority, we are privileged to be
acquainted in some detail with a precious thing, we need, as a
community, to appreciate whatever it is that we can do to nurture it.

Lucio.

Re: [9fans] 9P or better file services for multiple platforms

[Skip Tavakkolian]

Have you considered using AoE (Coraid)? It would require dedicated fossil,
NFS CIFS servers, but they'd all be sharing the storage -- Coraid supports
ext4 and NTFS. Most servers have multiple NICs, which makes a dedicated LAN
for AoE traffic easy.

Regarding authentication and access control, I think the only *standard*
option for a mixed OS environment (Plan 9, Linux/*BSD, Windows) is Kerberos.

It would be great if factotum could handle Kerberos 5. There is a pure Go
package (https://github.com/jcmturner/gokrb5) that could help. Of course,
this would take some work.

This setup would require 4 (or potentially only 3) machines:
  * AoE block storage
  * the KDC (MIT, Heimdal, or MS Active Directory)
  * Plan 9 file server (fossil, but also CIFS and NFS servers)
  * Linux or NetBSD file server for CIFS and NFS

-Skip

On Fri, Aug 31, 2018 at 10:22 PM Lucio De Re  wrote:

>
>
> My hope is to provide a central file server that fulfills reliable
> file services to both Plan 9 and Linux as seamlessly as possible. I am
> willing to sacrifice a few Unix features, such as file links, in that
> file server, if I can dedicate it to a narrower role than to support
> the full Linux environment. In Plan 9 parlance, I only need file
> services, not computing capabilities and the file server is allowed to
> limit some of the computing needs involved (like, say, graphics, any
> multimedia stuff, even mouse use).
>
> The question, then, is what file service will satisfy these needs,
> including access control, automatic backup as provided by default
> under Plan 9, etc. I am not very fond of Linux's propensity to need
> daily upgrades, but Plan 9 has quirks of its own, which I would be
> hard pressed to enumerate here, but we are all aware of.
>
> Lucio.
>
>

Re: [9fans] 9P or better file services for multiple platforms

[Ethan Gardener]

I had a thought pertaining to the original topic.

On Sat, Sep 1, 2018, at 6:21 AM, Lucio De Re wrote:
> The question, then, is what file service will satisfy these needs,
> including access control, automatic backup as provided by default
> under Plan 9, etc. I am not very fond of Linux's propensity to need
> daily upgrades, but Plan 9 has quirks of its own, which I would be
> hard pressed to enumerate here, but we are all aware of.
> 
> If I could run the file server on a modern (or even an ancient)
> version of NetBSD, I'd be even happier as NetBSD is the Unix flavour I
> highly favour. But that is a bonus, not an essential.

Regarding the automatic backup, FreeBSD's UFS (the default filesystem) provides 
snapshots much like CWFS's dump.  I think you can enable it for the whole 
filesystem with a mount option, but if not, I think it's quite easy to set up 
anyway.  

FreeBSD has ZFS too, which of course offers snapshots, but it has so many 
options that I found it a bit too much.  It seems well documented and the 
interface seems reasonable for the feature set, but it's a big feature set.  I 
have a habit of trying to understand and use too much at once, I guess.

Re: [9fans] 9P or better file services for multiple platforms

[Bakul Shah]

> On Sep 2, 2018, at 2:25 AM, Lucio De Re  wrote:
> 
> (GIT is the main reason for my begging here: I "pull" the latest Go to
> my workstation, then "archive" to Plan 9 (fossil). But fossil is slow,
> too slow to compete even with cross-compiling to plan9_386. Part of
> the problem is needing to flush the "archive" target in case bits have
> been removed and "export" does not delete them on the target - that
> works well, though, with fresh releases, like go1.11, of late. To be
> honest, I have the slack to use Plan 9 on a low-powered
> server/workstation combination and even cross-produce Linux-64
> executables for production; but building the Go distribution isn't
> really worth the trouble - I make a special effort to do that, not
> often enough.)

I now run 9front on FreeBSD under bhyve on a 10 year old
athlon64 machine. Initially I cross compiled go but now a native
compile doesn’t take all that long, using a previously compiled
Go as the bootstrap compiler. I’m using 9front’s new filesystem,
not fossil.

The “dgit” program (Dave McFarlane, with assists from Chris
McGee) works well enough now for “go get” or “git pull”.

I too want a unified filesystem that all my machines feed off of but
so far I have not found a solution. Local file systems are still faster.

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

[hiro]

"prevailing wisdom" sounds like an oxymoron.

The plan 9 kernel has not enjoyed the pressure of attacks like more
common operating systems.

If you want to help, it's easy to discover bugs by reading the source
code, which is very short and readable.

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

[Chris McGee]

Hi All,

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

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

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

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

Cheers,
Chris

Re: [9fans] 9P or better file services for multiple platforms

[cinap_lenrek]

this has little chance to get into linux imho. theres nobody
in charge.

supporting foreign protocols in plan9 is doable as done with
ntlm for example.

the best authentication infrastructure linux has is ssh with
ssh-agent imho. so we might as well let linux users authenticte
against plan9 using ther existing ssh rsa keys (for stuff like
9p mounts, drawterm).

--
cinap

Re: [9fans] 9P or better file services for multiple platforms

[hiro]

The way I inform myself of valuable contributions to plan 9 these days
is by watching 9front commit logs and the #cat-v irc channel.

If there are any valuable commits in David's repository that we should
apply, please inform us.

Re: [9fans] 9P or better file services for multiple platforms

[hiro]

On 9/2/18, Lucio De Re  wrote:
> On 9/2/18, hiro <23h...@gmail.com> wrote:
>>
>> already cinap is supporting dp9ik in drawterm, so...
>>
> That's subversive in the most practical sense. Is academia aware of it
> and its import? That is what curatorship (a friend from past days was
> and may still be the curator of the South African National (Art)
> Gallery, I am thinking of the role he and his predecessors play in the
> Arts landscape): inform potentially interested parties of the
> existence of something valuable.
>
> Of course, it is clearly not only academia that needs to know and
> curatorship would extend beyond that, clearly. Sponsorship is probably
> even more important. A curator may be able to justify a salary from a
> successful crowd-funding effort, for example.
>
> Am I being unreasonably optimistic?
>
> Lucio.
>
>

I'm not aware of adademia, but funds and code are always welcome.

Re: [9fans] 9P or better file services for multiple platforms

[hiro]

i think the original planet software ran on linux. right now cat-v.org
is maintained by sl, and on 9front, not linux.

and it might indeed be best to concentrate on creating software of
actual value, as opposed to administrating even more third-party
systems that don't share our style of approach...

i suppose you could check the individual blogs, possibly in an
automated way by writing some one-liner rc and hget script and publish
the outcome, plus keep it updated. then perhaps you can figure out if
this is the kind of information currently lacking.

On 9/2/18, Lucio De Re  wrote:
> On 9/2/18, hiro <23h...@gmail.com> wrote:
>>
>> there used to also be a planet/rss aggregation, but nobody alive knows
>> how to get the used software behind this to run on plan9 again
>
> I used to be a debugging whiz, in happier, more youthful times, maybe
> I can give that a try (it seems a challenge, rather than a really
> useful idea). Would you care to make that available?
>
> I do think there are many here who would be better at this, so if you
> say "no one alive" it does sound totally hopeless. But I presume
> you're exaggerating :-).
>
> Lucio.
>
>

Re: [9fans] 9P or better file services for multiple platforms

[Lucio De Re]

On 9/2/18, hiro <23h...@gmail.com> wrote:
>
> already cinap is supporting dp9ik in drawterm, so...
>
That's subversive in the most practical sense. Is academia aware of it
and its import? That is what curatorship (a friend from past days was
and may still be the curator of the South African National (Art)
Gallery, I am thinking of the role he and his predecessors play in the
Arts landscape): inform potentially interested parties of the
existence of something valuable.

Of course, it is clearly not only academia that needs to know and
curatorship would extend beyond that, clearly. Sponsorship is probably
even more important. A curator may be able to justify a salary from a
successful crowd-funding effort, for example.

Am I being unreasonably optimistic?

Lucio.

Re: [9fans] 9P or better file services for multiple platforms

[Lucio De Re]

On 9/2/18, hiro <23h...@gmail.com> wrote:
>
> there used to also be a planet/rss aggregation, but nobody alive knows
> how to get the used software behind this to run on plan9 again

I used to be a debugging whiz, in happier, more youthful times, maybe
I can give that a try (it seems a challenge, rather than a really
useful idea). Would you care to make that available?

I do think there are many here who would be better at this, so if you
say "no one alive" it does sound totally hopeless. But I presume
you're exaggerating :-).

Lucio.

Re: [9fans] 9P or better file services for multiple platforms

[Lucio De Re]

I think your reply touches most of the sore spots I am familiar with.
There's no doubt that 9legacy is missing out badly from the absence of
cinap's contributions to 9front and I'm the first to believe that a
one and true Plan 9 cannot afford to omit such pertinent enhancements,
just to list one, pretty massive example.

In a way, David IS the Plan 9 curator, but like all volunteers, his
focus has to be restricted to his interest scope, at the expense of
features that may spell life and death (in a metaphoric sense) for the
Plan 9 effort.

If one considers how much has been spent on Plan 9 so far and how much
it has served, irrespective of the emotional and aesthetic appeal that
we as 9fans presumably feel for it, it would be a shame to let slip,
as no doubt has happened already in the past, opportunities to give
Plan 9 a better grip in its context to ensure its survival against
more popular brands.

I guess it's a Darwinian issue: is there a flavour of Plan 9 capable
of earning sufficient traction where it matters (minds, more likely
than physical hosts) to ensure that its many still under-utilised
unique features are not lost, particularly to our very own community?
Can that flavour of Plan 9 be created, if necessary, from the
available "corpus" and what would the cost a committed community like
this one would need to bear to make that possible?

Such an effort would be the curatorship I have in mind, if you can call it that.

Lucio.


On 9/2/18, hiro <23h...@gmail.com> wrote:
> what form of curation are you imagining? we have a generic place for
> plan9-related news at http://ninetimes.cat-v.org/, but perhaps we
> haven't looked out far enough around 9front?
>
> there used to also be a planet/rss aggregation, but nobody alive knows
> how to get the used software behind this to run on plan9 again. and
> most people's blogs in that list shifted from plan9-related to
> go-related activities, so i'm not sure it's even worth updating any
> more.
>
>


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

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

Re: [9fans] 9P or better file services for multiple platforms

[hiro]

On 9/2/18, Lucio De Re  wrote:
> On 9/2/18, Lucio De Re  wrote:
>> On 9/1/18, hiro <23h...@gmail.com> wrote:
>>> no, 9p2000.L or Linux syscalls are not supported by plan9.
>>>
>>>
>> So Ethan is right, this is a "lark", if an interesting one. 9P is
>> getting quite a few "takers". I seem to recall a paper on adding Plan
>> 9 authentication to the Linux kernel, for purposes beyond the Plan 9
>> scope? That also needed 9P features.
>>
> Found it
> :
>
> "This paper discusses the extension of Linux authentication
> mechanisms to allow the use of the Plan 9 approach with
> existing Linux applications in order to reduce the security
> risks mentioned earlier. It describes the port of the Plan 9
> capability device as a character device driver for the Linux
> kernel. It also describes the port of the Plan 9 authentication
> server and the implementation of a PAM module which
> allows the use of these new facilities. It is now possible to
> restrain processes like login and su from the uncontrolled setuid
> bit and make them run on behalf of an unprivileged user
> in Linux."
>
> Lucio.
>
>

sounds like a linux-centric approach, with little or even no novelty.
once you have to deal with stuff like PAM you can give up altogether.

Re: [9fans] 9P or better file services for multiple platforms

[hiro]

i used to think it's good to put plan9 authentication in the linux
kernel, and perhaps it's true, because linux is so big, this little
more doesn't even hurt that much.

but it might be better to extend the pseudo-plan9-kernels in
drawterm/inferno in a way so that the linux kernel can talk plain 9p
to them, so that less code has to depend on redhat^Wlinux
patch-refusal monarchy.

already cinap is supporting dp9ik in drawterm, so...

Re: [9fans] 9P or better file services for multiple platforms

[Lucio De Re]

On 9/2/18, Lucio De Re  wrote:
> On 9/1/18, hiro <23h...@gmail.com> wrote:
>> no, 9p2000.L or Linux syscalls are not supported by plan9.
>>
>>
> So Ethan is right, this is a "lark", if an interesting one. 9P is
> getting quite a few "takers". I seem to recall a paper on adding Plan
> 9 authentication to the Linux kernel, for purposes beyond the Plan 9
> scope? That also needed 9P features.
>
Found it 
:

"This paper discusses the extension of Linux authentication
mechanisms to allow the use of the Plan 9 approach with
existing Linux applications in order to reduce the security
risks mentioned earlier. It describes the port of the Plan 9
capability device as a character device driver for the Linux
kernel. It also describes the port of the Plan 9 authentication
server and the implementation of a PAM module which
allows the use of these new facilities. It is now possible to
restrain processes like login and su from the uncontrolled setuid
bit and make them run on behalf of an unprivileged user
in Linux."

Lucio.

Re: [9fans] 9P or better file services for multiple platforms

[hiro]

what form of curation are you imagining? we have a generic place for
plan9-related news at http://ninetimes.cat-v.org/, but perhaps we
haven't looked out far enough around 9front?

there used to also be a planet/rss aggregation, but nobody alive knows
how to get the used software behind this to run on plan9 again. and
most people's blogs in that list shifted from plan9-related to
go-related activities, so i'm not sure it's even worth updating any
more.

Re: [9fans] 9P or better file services for multiple platforms

[Lucio De Re]

On 9/1/18, hiro <23h...@gmail.com> wrote:
> no, 9p2000.L or Linux syscalls are not supported by plan9.
>
>
So Ethan is right, this is a "lark", if an interesting one. 9P is
getting quite a few "takers". I seem to recall a paper on adding Plan
9 authentication to the Linux kernel, for purposes beyond the Plan 9
scope? That also needed 9P features.

Lucio.

Re: [9fans] 9P or better file services for multiple platforms

[Lucio De Re]

On 9/1/18, Joseph Stewart  wrote:
> This thread got me searching and I found MJL's guide for running a plan9
> network on a *nix system using u9fs.
>
> Hope this helps:
>
> https://www.ueber.net/who/mjl/plan9/plan9-obsd.html
>
> I'm gonna tinker with this myself.
>
That authsrv9 looks very promising. Definitely a gem worth knowing about.

What would be necessary for some bod to curate (as David to a great
extent does with the 9legacy stuff, better than may seem justified,
for his pay grade :-) ) a broader range of Plan 9 offerings, so it's
easier to keep the community informed?

Lucio.

Re: [9fans] 9P or better file services for multiple platforms

[Lucio De Re]

On 9/2/18, Brian L. Stuart  wrote:
> On Sat, 9/1/18, Lucio De Re  wrote:
>> [ ...  ]
>> My hope is to provide a central file server that fulfills reliable
>> file services to both Plan 9 and Linux as seamlessly as possible. I am
>
> I'm not going to make any guarantees about the reliability,
> but I do have a file system running on Plan 9, that natively
> provides NFS service as well as 9P.

That's definitely a good start.

> I also run it with a
> snapshot device under it and get the type of history we
> expect in a Plan 9 world.  To make the *nix side happy,
> it does support symbolic links.  (Reading a symlink in Plan 9
> just results in the path name string that the link points to.)

Does stat report anything fancy in the case of symbolic links? That
may be all that's needed to handle special applications that are
willing and able... But I will take more than a peek, find there the
answers I seek.

> And to make things really fun, it also serves AOE.
>
I wish...

> I've been running it now on my home system for several
> years.  I honestly don't use the NFS capability all that often,
> but I did test it a fair amount back at Coraid.  Recently, I
> added a little feature to the snapshot device to allow me
> to easily migrate to a larger disk.  As a matter of fact, I read
> your e-mail in acme on a 9vx which was taking its root from
> this file system.

But 9vx (which I nearly worship, but have been reluctant to get
attached to since I've been running 64-bit Linux) uses 9P, so that is
purely of anecdotal interest - I love anecdotes, myself. It's been a
long time, long enough for me to forget whether 9vx will execute Go
binaries or not - now, that's embarrassing!

>
> I'm sure there are plenty of nits that people could pick with
> it and the details of its design, but it was an interesting
> approach to experiment with and it's been serving me
> well for about 4 or 5 years.  The file system itself runs in
> user space on vanilla Plan 9, and the snapshot device
> can be added to the kernel very easily.
>
What nits would you pick, though, being the best qualified to do that?
I have a feeling for your abilities, this may be something 9fans (the
people, not the list) may be able to add much value to, if given some
direction, even I may be able to chip in.

> Although there is a version of both the snapshot device
> and the file system on contrib, if anyone's interested, I
> can get you the most recent code to play with.
>
Not Venti? I like Venti even more than I like 9vx, although
nit-picking there would yield a rich crop :-).

tl;dr: Please upload you efforts to github (or...) unless you have
extreme reasons not to. I'd love to be part of a Plan 9 revival and we
do have a presence on github, let's exploit the time github has got
left.

(GIT is the main reason for my begging here: I "pull" the latest Go to
my workstation, then "archive" to Plan 9 (fossil). But fossil is slow,
too slow to compete even with cross-compiling to plan9_386. Part of
the problem is needing to flush the "archive" target in case bits have
been removed and "export" does not delete them on the target - that
works well, though, with fresh releases, like go1.11, of late. To be
honest, I have the slack to use Plan 9 on a low-powered
server/workstation combination and even cross-produce Linux-64
executables for production; but building the Go distribution isn't
really worth the trouble - I make a special effort to do that, not
often enough.)

Lucio.

PS: I prefer not to be controversial, but Plan 9 needs a bit of
religious fervour to keep it alive: if I need to start a fire under
anyone's buttocks to help along, trust me, I'll do it. :-)

[9fans] focus window on plumb

[umbraticus]

Hi 9fans,

I wrote the attached to listen on a plumb port and make
a given window current when it gets a message.  I'm not
sure how much I will like it: it's nice not to have to
hunt for a buried client program after plumbing something;
on the other hand, sometimes I like to plumb a few urls,
images, or pdfs and view later.  Still, I thought I'd
figure out a way to do it.

The first argument is the port to listen on and the second
is a string to match against the label of the window to
raise.  In my riostart I start my main rc window like this:

window 'raiseplumb web mothra! & raiseplumb edit sam & raiseplumb image page & 
cat todo; label rc; rc'

(After setting page's label I bind /dev/null over it so it
isn't overwritten) The program could be improved but it
seems to work well enough for a quick implementation.

Other solutions I thought of were to prime the windows I
want to raise by posting their wctl in /srv (since /dev/wsys
isn't in the plumber's namespace) then writing plumb rules
to first raise the window by mounting the wctl, then plumb
to the port; or else patch the client programs to raise
themselves when they get a plumb.

Has anyone else wanted/implemented something like this?

umbraticus#include 
#include 
#include 

enum{LEN = 128};

int
match(int n, char *label)
{
int fd, len;
char s[LEN];

snprint(s, LEN, "/dev/wsys/%d/label", n);
if((fd = open(s, OREAD)) < 0)
return 0;
len = strlen(label);
if(read(fd, s, len) != len || memcmp(s, label, len) != 0){
close(fd);
return 0;
}
close(fd);
snprint(s, LEN, "/dev/wsys/%d/wctl", n);
if((fd = open(s, OWRITE)) < 0)
return -1;
fprint(fd, "unhide");
fprint(fd, "current");
close(fd);
return 1;
}

void
findwctl(char *label)
{
Dir *d;
int fd, n, i;

if((fd = open("/dev/wsys", OREAD)) < 0)
return;
while((n = dirread(fd, )) > 0){
for(i = 0; i < n; i++)
if(match(atoi(d[i].name), label)){
free(d);
close(fd);
return;
}
free(d);
}
close(fd);
}

void
main(int argc, char **argv)
{
Plumbmsg *m;
int fd;

if(argc != 3)
sysfatal("usage: %s fd label", argv[0]);
if(strlen(argv[2]) >= LEN)
sysfatal("label match too long: %s", argv[2]);
if((fd = plumbopen(argv[1], OREAD)) < 0)
sysfatal("couldn't open plumb fd %s", argv[1]);
for(;;){
if((m = plumbrecv(fd)) == nil)
sysfatal("error on plumb fd %s", argv[1]);
plumbfree(m);
findwctl(argv[2]);
}
}