Re: [9fans] IP Multicast - Results
Hi All, Multicast is working fine for me with the latest patches in 9front hg on my raspberry Pi. Thanks Cinap, Alex et al for pointing me in the right direction. Current status is that I can use multicast dns to discover nodes on my local network using a Go library and some patches to the Go networking code to add multicast support. I'm going to try and see if I can get that contributed to the next version. Btw, I noticed that the net manpage doesn't accurately describe the format of /net/ipifc/x/status files. It says there are 9 columns but mine has more than that and also some extra rows for assigned IP addresses. Does anyone know if this is a 9front specific deviation or if the man page is just way out of date? Chris > On Sep 17, 2016, at 7:53 AM, Chris McGee wrote: > > I recompiled with the latest in hg. I'm still not having success with the > multicast. I'm going to start adding debugging to figure out what's going on. > > Chris >
Re: [9fans] Questions on the browser as a platform if plan 9 had gained marketshare
> Would this be fast enough for what we experienced back then with early > websites, however? What with the stats on how people close or click away from > a tab within N seconds if it hasn't fully loaded yet, I'd think that having > to compile at all could've been prohibitive to people taking this route vs. > web forms. Though, I'm not sure how user behaviors or expectations of speed > were back then for the web. I have a couple of ideas in this area. If a more guided interface is needed then when you mount a service you can hook up a console to a file using "con" command allowing for interactive prompts such as "enter search criteria" and responses. Still no remote code required. Another option is to provide a readme.txt file describing the service, relevant files, etc. Inside that document are examples of shell commands that you can run. echo 'search cat pictures' >> ctl Open the readme in acme, edit the examples, select and middle click on it and it runs the command. You learn how to use the service and again, there is no remote command execution other than what you selected and ran. > > I was thinking what may have eventually happened would have been an > interpreted language would pop up that would be what web applications were > written in, sort of like java applets, except not embedded in the browser, > and hopefully in a simpler language. Early web applications were also very > simple 'put info in textbox and hit enter' forms, if I remember correctly, so > a small, expandable runtime that would be quickly started up in a sandbox > might have been on equal footing with html, assuming it was indeed able to > start up and run quickly (or maybe just fork a running one into a new > namespace?). Ideally, developers could then write their own libraries (in C > or whatever they like) that the web language would hook into that could do > more powerful things - and those libraries might be the time to provide > source and makefiles, or binaries if they wanted to keep things close to the > chest. That's possible that an interpreted language would have taken off. With OS level sandboxing, hopefully people run these within the sandboxes, providing access the minimal set needed for the service. > > Thinking more on the 'writing to a ctl file' idea, which I'm really getting > into, I was thinking users may have ended up making their own graphical > interfaces for web services; UIs that abstracted away the actual writing to > ctl files and put it in a GUI for less advanced users. It'd've been > interesting to see a competition in UI design among OSS interfaces for web > services, sort of like what we see today with apps for reddit on phones > (except hopefully they wouldn't all be awful). Or, maybe everyone would just > use the service-provider's provided interfaces. I think that many GUI's were created to hide ugly, inconsistent and large layers underneath. I have a hypothesis that if you start with a small, well designed system with a simple interface that people can and will use it of the alternative is a system that is brittle, complex and allows accidental security breaches at the click of a button. Textual interfaces can good and usable, with a bit of learning. Add graphics only when the problem warrants it (eg. CAD) or it truly simplifies the interface. > Do you think there would've been fewer large databases if things had gone > this way? Just thinking on my banking example, it seems like it'd be easiest > to just have a /bank.com/users/ folder with the relevant files in > it that users could union-mount, since you're not forced to show things > through a web interface. Though, I suppose a bank could just expose that > folder as an interface for what's actually a DB running in the background. The bank may expose files, but it doesn't necessarily mean you can edit them like simple text files. Plan 9 has some really interesting paradigms with read only files, updating using control file protocols, append only files, file descriptors that return errors for invalid writes. I've only scratched the surface. It could be a really interesting project to write up how different paradigms work for certain scenarios. Chris
Re: [9fans] Questions on the browser as a platform if plan 9 had gained marketshare
It's all based on their new language go. On 9/20/16, Marshall Conover wrote: >> Ken and rob are currently working at google trying to > make sure it stays so - the idea being that if the stupid people that > control the real OS can't be made to learn at least they'll make > themselves an abstract environment that can hide the past and all the > pain, to then work on interesting, more challenging ideas on the > higher level (in the web) without distractions. > > So, to make sure I understand correctly, the idea is to leave the actual OS > behind, and have all future development done entirely in the web, with the > browser as an application platform/web services being the OS, and finding a > way to make web services more composable? And this is being actively worked > on by Rob and Ken? I'm tempted to somehow work in the 9front release title > "Why not as a JS library?" > > Is there any more information on this? I'd be interested in seeing what a > design like that would be like, and what challenges they're trying to > address. The browser as a platform and the technologies around it seem like > such a kludge after 20-some years of incremental, meandering progress, I'd > think there might be a lot of difficulty trying to base a simple, solid > system on them. Then again, I'm not a web dev, so I could be > misunderstanding what goes on in that domain entirely. > > Thanks again! > > mars >
Re: [9fans] Questions on the browser as a platform if plan 9 had gained marketshare
I was thinking more along the lines of hardware implementation of 9P minus any OS. For example, a disk serves up a filesystem via 9P or an Ethernet device serving a /net with 9P. Chris > On Sep 20, 2016, at 2:16 AM, David Pick wrote: > >> On 19/09/16 21:55, Chris McGee wrote: >> >> >> >> Maybe 9P could be implemented in a SoC. > > It already has: the Raspberry Pi is built round a SoC... > ...all that's needed is to boot from SoC ROM instead of the SD card. > > -- > David Pick > Network Security Manager, IT Services > Queen Mary University of London > Tel: +44 (0) 20 7882 7079 > Mob: +44 (0) 7973 379 161 > E-Mail: d.m.p...@qmul.ac.uk > > Normal working days are Monday to Wednesday inclusive > > Worried about Cyber Security? Check out the > Cyber Security Information and Training described at > http://connect.qmul.ac.uk/qmandyou/staff/items/2016/item177974.html > >
[9fans] Questions on the browser as a platform if plan 9 had gained marketshare
> Ken and rob are currently working at google trying to make sure it stays so - the idea being that if the stupid people that control the real OS can't be made to learn at least they'll make themselves an abstract environment that can hide the past and all the pain, to then work on interesting, more challenging ideas on the higher level (in the web) without distractions. So, to make sure I understand correctly, the idea is to leave the actual OS behind, and have all future development done entirely in the web, with the browser as an application platform/web services being the OS, and finding a way to make web services more composable? And this is being actively worked on by Rob and Ken? I'm tempted to somehow work in the 9front release title "Why not as a JS library?" Is there any more information on this? I'd be interested in seeing what a design like that would be like, and what challenges they're trying to address. The browser as a platform and the technologies around it seem like such a kludge after 20-some years of incremental, meandering progress, I'd think there might be a lot of difficulty trying to base a simple, solid system on them. Then again, I'm not a web dev, so I could be misunderstanding what goes on in that domain entirely. Thanks again! mars
Re: [9fans] Questions on the browser as a platform if plan 9 had gained marketshare
> Well, since everyone is trying to make the web the OS - see the chrome > boxes, for example - why not cut out the middleman and just have the OS > doing things? It seems like it's going to happen no matter what. Well, it's happened, so now we have two shitty OS: chrome on top of mac os x. Naturally interoperability between different programs from the web and anything else (even other programs in the web) is non-existent. Ken and rob are currently working at google trying to make sure it stays so - the idea being that if the stupid people that control the real OS can't be made to learn at least they'll make themselves an abstract environment that can hide the past and all the pain, to then work on interesting, more challenging ideas on the higher level (in the web) without distractions. Please correct me if I'm wrong, my googleinos :)
Re: [9fans] Questions on the browser as a platform if plan 9 had gained marketshare
> Also, external storage (hdd, ssd) with a built in filesystem exposed as 9P. > UTF-8 file names, of course. already exists, see coraid.