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.
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
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
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:
>
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"
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
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?
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.
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
You're here. Sometimes an audience is all the artist needs as the
stimulus. How does it go? "They also serve...".
Lucio.
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
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
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
> 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
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
> 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.
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
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
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
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
> 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
"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.
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.
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
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.
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
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
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
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,
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,
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
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
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
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
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
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
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
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,
38 matches
Mail list logo
