Re: [9fans] Questions on the browser as a platform if plan 9
> I wonder if 9p could be implemented on an SoC. It'd be neat for the whole 'internet of things' hullabaloo.
Re: [9fans] 9front 5492 1919
Thanks Hurt F.A.K.K.2, SNES Kurt. "you don't need a fact three". On Mon, Sep 19, 2016 at 5:14 PM, Kurt H Maierwrote: > On Mon, Sep 19, 2016 at 04:56:39PM -0700, Jules Merit wrote: > > Go away Die NSA release fails to go beyond... > > "759M memory: 256M kernel data. 503M user, 1128M swap" > > See section 9.5.2 of the 9front FQA: > http://fqa.9front.org/fqa9.html#9.5.2 > > Further troubleshooting should probably happen on the 9front list so as > not to distract 9fans users with onerous email unrelated to their > interests. > > khm > >
Re: [9fans] 9front 5492 1919
It was *bogobananas= Taken from the undocumented 65c816 processor. On Mon, Sep 19, 2016 at 4:56 PM, Jules Merit < jules.merit.eurocorp...@gmail.com> wrote: > Go away Die NSA release fails to go beyond... > "759M memory: 256M kernel data. 503M user, 1128M swap" > > It got past 9boot, I can get ">" > #Y0 Ricoh 476, #l0 i82557, #l1 wavelanpc, #A0 ac97 detected > > Any extra plan9.ini statements to try to get more verbose messages? > > I know this worked on plan9 since I wrote a driver for the wacom tablet > earlier, perhaps it lost the CDROM drive after bios->kernel. before it was > PXE. > > This system has hardware GL documented by intel and I was able to port > MesaGL to plan9. >
Re: [9fans] 9front 5492 1919
On Mon, Sep 19, 2016 at 04:56:39PM -0700, Jules Merit wrote: > Go away Die NSA release fails to go beyond... > "759M memory: 256M kernel data. 503M user, 1128M swap" See section 9.5.2 of the 9front FQA: http://fqa.9front.org/fqa9.html#9.5.2 Further troubleshooting should probably happen on the 9front list so as not to distract 9fans users with onerous email unrelated to their interests. khm
[9fans] 9front 5492 1919
Go away Die NSA release fails to go beyond... "759M memory: 256M kernel data. 503M user, 1128M swap" It got past 9boot, I can get ">" #Y0 Ricoh 476, #l0 i82557, #l1 wavelanpc, #A0 ac97 detected Any extra plan9.ini statements to try to get more verbose messages? I know this worked on plan9 since I wrote a driver for the wacom tablet earlier, perhaps it lost the CDROM drive after bios->kernel. before it was PXE. This system has hardware GL documented by intel and I was able to port MesaGL to plan9.
Re: [9fans] Questions on the browser as a platform if plan 9 had gained marketshare
> Mounting a bin directory from some remote servers is a potential vector for malicious code and requires all services to provide binaries for all platforms (arm, x86, riscv,...). Instead, serving the source code and mkfile allows for audit ability (what did I just run?) and support for their own platform. Plan 9 compilers were designed not just to produce optimal code but also for speed of compilation. 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 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. 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. 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. > This was however because I wanted to call a site "Troff the Crime Blog." I chortled. I was wondering if maybe today a similar thing could be done with docker or the rocket containers, but I'm not familiar enough with them; it seems like they're somewhat baked images, not just namespaced folders with the relevant things union-mounted inside them, so it might not be easy or fast to just union mount the things you need for the web-app you're loading in a new docker instance. Also, they have no UI support, thought it seems like you can dynamically link an X socket into them to draw to an X session on the parent machine with some extra work. Let me know if this conversation is not really appropriate for this mailing list at this point, by the way. I don't want to be a nuisance. I appreciate the discussion so far - thanks! mars
Re: [9fans] Questions on the browser as a platform if plan 9 had gained marketshare
If plan 9 had taken off I wonder if there would be peripherals with built-in 9P support. For example, a network adapter that you can mount into /net/etherxyz over USB, PCI using a 9P connection. No driver needed, except to communicate with the bus. Also, external storage (hdd, ssd) with a built in filesystem exposed as 9P. UTF-8 file names, of course. Maybe 9P could be implemented in a SoC. Chris
Re: [9fans] Questions on the browser as a platform if plan 9 had gained marketshare
> > > You just mount search engine, route planning tool, or even shopping site > > and echo commands into the ctl file. > > I hadn't thought of this - was more thinking on the user union mounting, say, > google.com/bin into their bin directory and running a google operation. The > concept of just echoing into a ctl file is really interesting from a security > perspective. Right, in this case there is no remote code execution. Web users run all kinds of code they are unaware of today. It's a major problem. It also helps to create a certain uniformity and expectation of how services should work. Mounting a bin directory from some remote servers is a potential vector for malicious code and requires all services to provide binaries for all platforms (arm, x86, riscv,...). Instead, serving the source code and mkfile allows for audit ability (what did I just run?) and support for their own platform. Plan 9 compilers were designed not just to produce optimal code but also for speed of compilation.
Re: [9fans] Questions on the browser as a platform if plan 9 had gained marketshare
On Sat, Sep 17, 2016 at 11:51 AM, Jules Merit < jules.merit.eurocorp...@gmail.com> wrote: > Troff + net, > This spring (in the northern hemisphere) I had toyed with the notion of using troff as an intermediate format for publishing public record data sets. This was however because I wanted to call a site "Troff the Crime Blog." True story. Ian
Re: [9fans] Questions on the browser as a platform if plan 9 had gained marketshare
Thanks, Chris! That was a lot more detailed than I had thought into it. > You just mount search engine, route planning tool, or even shopping site and echo commands into the ctl file. I hadn't thought of this - was more thinking on the user union mounting, say, google.com/bin into their bin directory and running a google operation. The concept of just echoing into a ctl file is really interesting from a security perspective. > Multimedia documents with both pictures and text are compiled into self contained files kind of like PDF without hyperlinks and arbitrary code expectation... This rich format is for longer and more focused reading sessions: studying a topic, leisure reading. I had originally been thinking along these lines, but the more I think about it, the more I think there would have been a lot of demand for flashy displays, and so I think something like a library for a flash-like language that users would execute would've popped up. While I think users could've gotten used to normal text (and it actually may have been more intuitive, especially for older, non-technical people who are distracted by flashy things), I think the people paying for development would've wanted more, including graphics and animations. >Also, services are designed to be focused enough and standard enough that they can be easily interact with other services using pipes, redirects, etc. so that the user can combine them to suit their needs. This would've been amazing. > Single signon is achieved using symmetric encryption. If the service recognizes your public key and you are able to sign a message using your private key you can proceed. Not sure how much overlap there is here with what is in tls and factotum. Something like factotum could be useful to allow you to specify different keys (identities) for different services. This would be interesting, as well, when combined with network+union filesystems, for being able to do something like run a website like reddit with pointers to files hosted by users themselves. The possible advantage I was thinking about is that a user could post comments as files stored on their local accounts with group permissions they can specify, allowing them to only have their friends see those files; the 'reddit' site would only host the file pointers, and people would only be able to see those comments on the reddit reader-app if they had the correct permissions. Usrers could then delete their comments at will without worrying about the site holding onto them in old DB backups or the like. Thanks, also, Hiro! > There is nothing wrong with the web having a limited scope of features. 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. > If they are on par, then why waste time with the web part? Well, that's the point, isn't it? You can access applications from anywhere, and you don't need a browser to act as a platform to do it. You also don't need to install them using some wizard and registry and all the other BS. > security and privacy in the web is hopeless. it plainly was never a real goal. Would plan9 have made it reasonable to become one? > popular things tend to drive people. doesn't say anything about the technical or even educational qualities though. I think this is a good point. I was also thinking that ease-of-entry would likely have developed more on the application side if more people had been using it. > Plan 9 technically is just one small collection of more consistent alternative building blocks, but the web has ignored, reinvented or misunderstood most others, too. Yeah, this is sort of why I've been thinking about this. I've almost begun getting frustrated when I see all the redundant design in the browser that, at least it seems, could've just been done with the OS. Every time a friend or intern pings me with a web problem, it seems more and more like the web is just a series of kludges from trying to make the newspaper man be a song-and-dance man who gives you live television. Thanks for the thoughts! mars