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 l
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
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:
> H
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" essent
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.
nothi
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 primar
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 do
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
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 wi
> 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 diver
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,
> 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 hav
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 fo
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 thi
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 propensi
> 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
"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.
https://lwn.net/Su
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 t
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 b
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..
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 Nationa
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, r
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, p
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 9p
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 authenticati
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 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 beyon
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 promisin
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,
image
38 matches
Mail list logo
