Re: [9fans] Git

2018-09-15 Thread Nick Owens
hi dave, would it be possible for you to vendor your dependencies of dgit? if not for the git repo itself, perhaps just vendor them for a tagged release tarball uploaded to github. that would be a way around the 'you need git to go get dgit' problem. On Sat, Sep 15, 2018 at 9:03 AM Dave

[9fans] Git

2018-09-15 Thread Dave MacFarlane
I've been trying to do more development of dgit under 9front instead of DragonFly so that it'll force me to catch/fix any major bugs missed by the test suite. I fixed one significant performance problem and now it seems to mostly be useable for basic git usage under Plan 9 (or at least 9front) and

[9fans] undead, undead, undead...

2018-09-13 Thread Steve Simon
I believe the 1st edition CD had some music on it, sadly I never tried playing it. Sounds stunning IMHO. https://bauhaus.bandcamp.com/track/bela-lugosis-dead-official-version -Steve

Re: [9fans] 9front VMX

2018-09-10 Thread Skip Tavakkolian
Also, Windows NT support! nice touch :) On Mon, Sep 10, 2018 at 10:00 AM Skip Tavakkolian < skip.tavakkol...@gmail.com> wrote: > Very cool! > > On Mon, Sep 10, 2018 at 8:02 AM wrote: > >> vmx(1) documentation in the dash1: >> >> http://fqa.9front.org/fqa8.html#8.7.5.1 >> >> script i use

Re: [9fans] 9front VMX

2018-09-10 Thread sl
Yes, you get full graphics, but performance is terrible (the frame buffer is emulated entirely in software). You can run any browser, and everything works, but probably not fast enough for regular use. I have used Chromium in a pinch to login to Patreon, PayPal, etc. Gimp also works fine (if

Re: [9fans] 9front VMX

2018-09-10 Thread Nick Owens
while we're on the subject, here's a half-assed script called 'inception' to boot your 9front kernel in a vmx instance on a terminal while sharing the host's fs. #!/bin/rc # inception rfork ne ramfs ip=`{ndb/query sys $sysname ip} aux/listen1 -t 'tcp!*!564' /bin/exportfs -r /root & cat

Re: [9fans] 9front VMX

2018-09-10 Thread Dave MacFarlane
I've always found performance to be terrible for OpenBSD even on physical hardware, so I can't really hold that against vmx.. - Dave

Re: [9fans] 9front VMX

2018-09-10 Thread Ori Bernstein
On Mon, 10 Sep 2018 18:57:29 +0100 Steve Simon wrote: > is there any graphics support? would it be usable to run a browser? dillo > talking to a framebuffer maybe? > > ever hopefull of getting modern browser support in plan9... > > -Steve Chrome and Firefox work, if you're willing to wait as

Re: [9fans] 9front VMX

2018-09-10 Thread Kurt H Maier
On Mon, Sep 10, 2018 at 06:57:29PM +0100, Steve Simon wrote: > is there any graphics support? would it be usable to run a browser? dillo > talking to a framebuffer maybe? > > ever hopefull of getting modern browser support in plan9... > > -Steve This is documented in the linked fqa section.

Re: [9fans] 9front VMX

2018-09-10 Thread hiro
yes to all 4

Re: [9fans] 9front VMX

2018-09-10 Thread Steve Simon
is there any graphics support? would it be usable to run a browser? dillo talking to a framebuffer maybe? ever hopefull of getting modern browser support in plan9... -Steve > On 10 Sep 2018, at 6:03 pm, G B wrote: > > Thank you. > > On Monday, September 10, 2018, 12:02:23 PM CDT, Skip

Re: [9fans] 9front VMX

2018-09-10 Thread G B
Thank you. On Monday, September 10, 2018, 12:02:23 PM CDT, Skip Tavakkolian wrote: Very cool! On Mon, Sep 10, 2018 at 8:02 AM wrote: vmx(1) documentation in the dash1:         http://fqa.9front.org/fqa8.html#8.7.5.1 script i use to run openbsd:        

Re: [9fans] 9front VMX

2018-09-10 Thread Skip Tavakkolian
Very cool! On Mon, Sep 10, 2018 at 8:02 AM wrote: > vmx(1) documentation in the dash1: > > http://fqa.9front.org/fqa8.html#8.7.5.1 > > script i use to run openbsd: > > http://plan9.stanleylieber.com/rc/openbsd > > in my setup opensd is the first hard drive and 9front > is the

Re: [9fans] 9front VMX

2018-09-10 Thread sl
vmx(1) documentation in the dash1: http://fqa.9front.org/fqa8.html#8.7.5.1 script i use to run openbsd: http://plan9.stanleylieber.com/rc/openbsd in my setup opensd is the first hard drive and 9front is the second. vmx(1) runs openbsd from the hard drive installation. note:

[9fans] 9front VMX

2018-09-10 Thread G B
I'm interested in trying to run OpenBSD using VMX on 9front.  Can someone give me an example of how I'd set this up and run it? % vmx -M 128 -n ether0 bsd Where "bsd" is the OpenBSD 6.2 kernel.  I must be missing more to it than just this?  Thanks for any help.

Re: [9fans] APL for Plan 9?

2018-09-10 Thread Rudolf Sykora
On Fri, 7 Sep 2018 at 17:53, Xiao-Yong Jin wrote: > I would love to know what you did for OpenBSD. > I am stuck with the linux version on FreeBSD for now. > Do all the test pass on OpenBSD? Do all the 15!: actually work? > For Plan 9, we can just get rid of libedit and make jconsole a lot

Re: [9fans] APL for Plan 9?

2018-09-07 Thread Xiao-Yong Jin
> On Sep 7, 2018, at 1:35 AM, Rudolf Sykora wrote: > > But. There are several parts of the system: jlibrary, jconsole, jqt. > The first two I finally managed to compile on OpenBSD, I failed with > jqt (which is a very nice qt-based environment, btw.) And nobody will > use the latter on Plan9.

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

2018-09-07 Thread Richard Miller
> This looks like it fits the bill: open, small, simple. How was it formally > verified? http://www.clifford.at/papers/2017/riscv-formal/slides.pdf > How can I help with the compiler port? Compiling & testing lots of library code would likely reveal remaining bugs. Also it might be useful to

Re: [9fans] APL for Plan 9?

2018-09-07 Thread Bakul Shah
On Fri, 07 Sep 2018 08:35:23 +0200 Rudolf Sykora wrote: > I also note that there now exists a GPL'd version of the K language, > Kona. That one was straightforward to build on OpenBSD. Kona uses mmap so not so easy to port. If you are used to normal C style, kona code style will be very hard to

Re: [9fans] APL for Plan 9?

2018-09-07 Thread Rudolf Sykora
Hello, On Thu, 6 Sep 2018 at 19:36, Richard Miller <9f...@hamnavoe.com> wrote: > > There's a Plan 9 port of J 3.02 in /n/sources/contrib/miller/j/8.j > > > > 386 executable only, as I don't have permission to share source, but I can > > compile for other $objtypes on request. > > I recall the

Re: [9fans] APL for Plan 9?

2018-09-06 Thread Lyndon Nerenberg
Ethan Gardener writes: > Is there an implementation of APL or a related language for Plan 9? For pure APL, I don't think so. Long ago I ran the Thompson APL interpreter on our Ultrix VAX. It was built from source, but I forget which tape it came from. It would have been one of V7 or 4.2BSD,

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

2018-09-06 Thread Chris McGee
Thanks Richard, This looks like it fits the bill: open, small, simple. How was it formally verified? This doesn’t seem to need any of the chisel/scala suff, which is great. How can I help with the compiler port? Which fpga board do you recommend? Chris On Sep 6, 2018, at 1:48 PM, Richard

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

2018-09-06 Thread Skip Tavakkolian
Thank you. This is fantastic. I've been looking into running Plan 9 in JSLinux ( https://bellard.org/jslinux/ and https://bellard.org/jslinux/tech.html) and came across riscvemu (https://bellard.org/riscvemu/). I wonder if it might be a useful for trying things on. On Thu, Sep 6, 2018 at 10:48

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

2018-09-06 Thread Richard Miller
> It could be, but after having looked briefly at the size of the design for > RISC-V Rocket and especially BOOM I wonder if it's all overly complicated. > They even built their own high level hardware language (Chisel) that > generates Verilog using Scala. Yuck. It's possible to build a simple

Re: [9fans] APL for Plan 9?

2018-09-06 Thread Richard Miller
On 2009-07-10 I announced this in 9fans: > There's a Plan 9 port of J 3.02 in /n/sources/contrib/miller/j/8.j > > 386 executable only, as I don't have permission to share source, but I can > compile for other $objtypes on request. I recall the port being very simple to do, so it would probably

Re: [9fans] APL for Plan 9?

2018-09-06 Thread Greg Lewin
and there is J, from the same stable as APL and its natural successor but using only ascii characters: http://www.jsoftware.com/ - sources under GPL v3 dual licence On Thu, 6 Sep 2018 at 14:42, Ethan Gardener wrote: > > Is there an implementation of APL or a related language for Plan 9? > > --

Re: [9fans] APL for Plan 9?

2018-09-06 Thread Bakul Shah
On Sep 6, 2018, at 6:41 AM, Ethan Gardener wrote: > > Is there an implementation of APL or a related language for Plan 9? http://t3x.org/klong/ Though it is not as nice as k or kona. Rob Pike’s ivy may compile on plan9, it being implemented in go.

Re: [9fans] APL for Plan 9?

2018-09-06 Thread Dave Lukes
I know nothing of any pure APL for p9 or related systems, but theres A+: http://www.aplusdev.org/ which is GPLed, so could, theoretically, be ported. On Sep 06, 2018, at 02:43 PM, Ethan Gardener wrote: Is there an implementation of APL or a related language for Plan 9? -- The lyf so short,

[9fans] APL for Plan 9?

2018-09-06 Thread Ethan Gardener
Is there an implementation of APL or a related language for Plan 9? -- The lyf so short, the craft so long to lerne. -- Chaucer

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

2018-09-06 Thread Ethan Gardener
On Thu, Sep 6, 2018, at 1:32 AM, Bakul Shah wrote: > On Wed, 05 Sep 2018 07:42:52 -0400 Chris McGee wrote: > > Could you get away with a much simpler, smaller hardware design and still > > run Plan 9 in a reasonable way? Maybe one side of the software/hardware > > divide has to take on more

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

2018-09-06 Thread Chris McGee
> What one wants is Plan 9 as a > model for what may be a family of hardware APIs. It makes sense to > promote massive parallelism, but the API to it should be sufficiently > simple for a single individual to manage. > This is the what I wonder about. Is this possible at the hardware level and

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

2018-09-05 Thread Lucio De Re
On 9/6/18, Bakul Shah wrote: > > But if all you want to do is just run plan9 why even bother? > But that is disingenuous, isn't it? What one wants is Plan 9 as a model for what may be a family of hardware APIs. It makes sense to promote massive parallelism, but the API to it should be

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

2018-09-05 Thread Bakul Shah
On Wed, 05 Sep 2018 07:42:52 -0400 Chris McGee wrote: > > It could be, but after having looked briefly at the size of the design for > RISC-V Rocket and especially BOOM I wonder if it's all overly complicated. > They even built their own high level hardware language (Chisel) that > generates

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

2018-09-05 Thread Chris McGee
> Take a look at greenarraychips.com and how Chuck Moore tries to > simplify the whole instead of software or hardware. > Thanks, that is a very interesting read on the topic of asynchronous and highly parallel computing. I'm not sure if the designs for these are very simple though.

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

2018-09-05 Thread Iruatã Souza
On Wed, Sep 5, 2018 at 4:45 AM Chris McGee wrote: > > >> Wasn't that the whole point of RISC? > > > It could be, but after having looked briefly at the size of the design for > RISC-V Rocket and especially BOOM I wonder if it's all overly complicated. > They even built their own high level

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

2018-09-05 Thread Ethan Gardener
On Wed, Sep 5, 2018, at 12:42 PM, Chris McGee wrote: > > They even built their own high level hardware language (Chisel) that > generates Verilog using Scala. Yuck. >From what I've heard of Verilog and VHDL, this is the sane approach. I only >have second hand knowledge of these languages, my

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

2018-09-05 Thread Chris McGee
> Wasn't that the whole point of RISC? > It could be, but after having looked briefly at the size of the design for RISC-V Rocket and especially BOOM I wonder if it's all overly complicated. They even built their own high level hardware language (Chisel) that generates Verilog using Scala. Yuck.

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

2018-09-05 Thread Dave MacFarlane
On Tue, Sep 4, 2018, 22:31 Chris McGee, wrote: > > I believe that the core of the problem with the C language is that is >> based upon abstracting the PDP-11 instruction set. CPUs, such as Intel/AMD >> x64 are vastly more complex so "optimising" C compilers are trying to make >> something

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

2018-09-05 Thread Ethan Gardener
On Wed, Sep 5, 2018, at 4:25 AM, Ori Bernstein wrote: > > > CPUs, such as Intel/AMD x64 > > are vastly more complex so "optimising" C compilers are trying to make > > something simple take advantage of something far more complex. > > Ironically, because of the complexity in the CPUs, many of the

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

2018-09-04 Thread Ori Bernstein
On Wed, 5 Sep 2018 09:30:22 +1000, Tyga wrote: > Ha HA ! Good one ! > CPUs, such as Intel/AMD x64 > are vastly more complex so "optimising" C compilers are trying to make > something simple take advantage of something far more complex. Ironically, because of the complexity in the CPUs, many

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

2018-09-04 Thread Chris McGee
> I believe that the core of the problem with the C language is that is > based upon abstracting the PDP-11 instruction set. CPUs, such as Intel/AMD > x64 are vastly more complex so "optimising" C compilers are trying to make > something simple take advantage of something far more complex.

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

2018-09-04 Thread Tyga
Ha HA ! Good one ! I believe that the core of the problem with the C language is that is based upon abstracting the PDP-11 instruction set. CPUs, such as Intel/AMD x64 are vastly more complex so "optimising" C compilers are trying to make something simple take advantage of something far more

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

2018-09-04 Thread Charles Forsyth
Plan 9 C implements C by attempting to follow the programmer's instructions, which is surprisingly useful in systems programming. The big fat compilers work hard to find grounds to interpret those instructions as "undefined behaviour". On Sun, 2 Sep 2018 at 17:32, Chris McGee wrote: > Hi All,

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

2018-09-04 Thread Chris McGee
> > Could even be that the many-eyes approach encouraged the complexity; > > in fact, that could easily be the unintended consequence. > > I suppose it made complexity seem less bad, for a while, but I was > thinking economic factors likely drove it to get more complex. Also, I get > the

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

2018-09-04 Thread Ethan Gardener
On Tue, Sep 4, 2018, at 11:51 AM, Lucio De Re wrote: > On 9/3/18, Ethan Gardener wrote: > > On Mon, Sep 3, 2018, at 1:40 PM, Chris McGee wrote: > >> While the idea that many eyes makes bugs shallower seems to have failed > >> in the world of complex behemoth software it may work here. > > > > I

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

2018-09-04 Thread Lucio De Re
On 9/3/18, Ethan Gardener wrote: > On Mon, Sep 3, 2018, at 1:40 PM, Chris McGee wrote: >> While the idea that many eyes makes bugs shallower seems to have failed >> in the world of complex behemoth software it may work here. > > I think it worked for a while, but eventually complexity grew beyond

Re: [9fans] focus window on plumb

2018-09-03 Thread umbraticus
Even simpler, run the following program in riostart thus: window 'raiseplumb web & mothra' window 'raiseplumb edit & sam' could probably even be an rc script #include #include #include void main(int argc, char **argv) { Plumbmsg *m; int port, wctl; if(argc != 2)

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

2018-09-03 Thread Ethan Gardener
On Mon, Sep 3, 2018, at 1:40 PM, Chris McGee wrote: > While the idea that many eyes makes bugs shallower seems to have failed > in the world of complex behemoth software it may work here. I think it worked for a while, but eventually complexity grew beyond even the many eyes approach.

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

2018-09-03 Thread Chris McGee
Thanks everyone. This is pretty much what I expected was the case. I just wanted to confirm my understanding. Plan 9 C was re-engineered with some focus on readable code. Readability is expected to make bugs more apparent, making it less “dangerous.” Linux is so huge and hard to read that even

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

2018-09-02 Thread 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

2018-09-02 Thread 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

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

2018-09-02 Thread 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

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

2018-09-02 Thread 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: >

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

2018-09-02 Thread 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"

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

2018-09-02 Thread 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

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

2018-09-02 Thread 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?"

2018-09-02 Thread 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.

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

2018-09-02 Thread 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

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

2018-09-02 Thread 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

2018-09-02 Thread 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

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

2018-09-02 Thread 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

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

2018-09-02 Thread 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

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

2018-09-02 Thread 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

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

2018-09-02 Thread 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

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

2018-09-02 Thread 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

2018-09-02 Thread 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

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

2018-09-02 Thread 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

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

2018-09-02 Thread 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

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

2018-09-02 Thread 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

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

2018-09-02 Thread 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

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

2018-09-02 Thread 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?"

2018-09-02 Thread 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.

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

2018-09-02 Thread 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

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

2018-09-02 Thread 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

2018-09-02 Thread 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

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

2018-09-02 Thread 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

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

2018-09-02 Thread 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

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

2018-09-02 Thread 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,

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

2018-09-02 Thread 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,

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

2018-09-02 Thread 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

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

2018-09-02 Thread 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

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

2018-09-02 Thread 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

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

2018-09-02 Thread 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

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

2018-09-02 Thread 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

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

2018-09-02 Thread 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

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

2018-09-02 Thread 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

[9fans] focus window on plumb

2018-09-02 Thread 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,

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

2018-09-01 Thread Brian L. Stuart
On Sat, 9/1/18, Lucio De Re wrote: > I'm trying to arrive at the most elegant solution to the following > problem that does not sacrifice a great deal of efficiency. And, maybe > I need to state this, the final result must be as robust or more > robust than what I have in place currently, which

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

2018-09-01 Thread hiro
no, 9p2000.L or Linux syscalls are not supported by plan9.

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

2018-09-01 Thread Ethan Gardener
On Sat, Sep 1, 2018, at 11:29 AM, Rui Carmo wrote: > > I myself have similar needs and recently bookmarked this:  > https://github.com/chaos/diod (but had no time to test it yet). diod's readme states it speaks 9p2000.L. Isn't that incompatible with Plan 9? I recall reading something like,

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

2018-09-01 Thread Joseph Stewart
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. -joe On Sat, Sep 1, 2018 at 8:20 AM Lucio De Re wrote: > On 9/1/18, Lucio De

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

2018-09-01 Thread Lucio De Re
On 9/1/18, Lucio De Re wrote: > > Trying it out, it fails to find "attach" and there is no clue where > that should come from. It did strike me as complex, but if it serves > an NFS filesystem, that is probably adequate. > > I'll wait to pass judgement for after I have it actually serving >

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

2018-09-01 Thread Lucio De Re
On 9/1/18, Emery Hemingway wrote: > I don't think you can find better than u9fs for unix. > I tend to use that as a norm, but the backing Plan 9 server is kind of in the wrong "key". OK for Plan 9, but too slow for Linux. Still, that sounds like a warning that better that u9fs is not out there.

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

2018-09-01 Thread Emery Hemingway
I don't think you can find better than u9fs for unix. I've tried to use diod once or twice, but it is some weird overengineered linux shit. Emery On Saturday, September 1, 2018 3:33:54 PM CEST, Lucio De Re wrote: On 9/1/18, Rui Carmo wrote: I myself have similar needs and recently

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

2018-09-01 Thread Lucio De Re
On 9/1/18, Rui Carmo wrote: > I myself have similar needs and recently bookmarked this: > https://github.com/chaos/diod (but had no time to test it yet). > Thank you, Rui, that looks pretty exciting, I'll be happy to look into it. It does rather look like Plan 9 itself may have to be of the

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

2018-09-01 Thread Rui Carmo
I myself have similar needs and recently bookmarked this: https://github.com/chaos/diod (but had no time to test it yet). R.

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

2018-08-31 Thread Lucio De Re
I'm trying to arrive at the most elegant solution to the following problem that does not sacrifice a great deal of efficiency. And, maybe I need to state this, the final result must be as robust or more robust than what I have in place currently, which has yet to let me down, partially due to the

Re: [9fans] updating awk ...

2018-08-30 Thread Pumba The Pig
Sent from my iPad > On 29 Aug 2018, at 17:55, Kurt H Maier wrote: > >> On Wed, Aug 29, 2018 at 12:40:21AM -0400, Benjamin Purcell wrote: >> Spew here. I only made minimal changes to 9front awk to convert it to > > On the topic of awk, a while ago Paul A. Patience did some work to > the awk

Re: [9fans] updating awk ...

2018-08-29 Thread Kurt H Maier
On Wed, Aug 29, 2018 at 12:40:21AM -0400, Benjamin Purcell wrote: > Spew here. I only made minimal changes to 9front awk to convert it to On the topic of awk, a while ago Paul A. Patience did some work to the awk in Boyd's contrib, so people interested in a native awk have options these days.

Re: [9fans] updating awk ...

2018-08-28 Thread Benjamin Purcell
Spew here. I only made minimal changes to 9front awk to convert it to a native application (this allowed 9front to remove the regexp library that was duplicated in APE). Arnold: thanks for the information on the awk improvements. I will look at them and merge them into 9front when I have time. On

  1   2   3   4   5   6   7   8   9   10   >