Re: [9fans] what heavy negativity!

[Tyga]

Hi Mayuresh !

Can't help offering the quote:

*First they ignore you, then they laugh at you, then they fight you, then
you win. *
*Mahatma Gandhi*

I have read with considerable bemusement the many responses to your
proposal.  Granted that it does look like a huge challenge.  Knowledgeable
people can see many problems with what you are contemplating.  But you have
to remember that you might learn a great deal if you attempt your idea and
sometimes good things come from attempting grand challenges. Just think
what would have happened if Columbus had given up when his proposal was
first rejected.

May I suggest that you overlook the emotional negativity and look at the
technical specifics of why many others see your proposal as foolhardy.
Then having given due consideration to the technical issues and your
resources (both time and knowledge) you would be in a far better position
to make an informed decision.

IMHO Plan9 offers a great deal of potential but is hamstrung by the lack of
resources to advance device drivers and accommodate the evolution of
hardware since the times it was designed.  To many people the visual
aspects of the user interface are unappealing and yet to others that is
exactly what appeals to them.  So it is impossible to please all the people
all the time.  I for one, would very much like to see the Plan9
architecture and thus concepts become available within more mainstream
environments.





On Fri, 5 Oct 2018 at 15:11, Mayuresh Kathe  wrote:

> man, i experienced such heavy negativity towards my efforts to build a
> linux kernel based plan9port vehicle that i am sure considering
> abandoning the effort.
>
> the idea was to have a 64-bit linux kernel with the advantages of
> plan9port (small and elegantly designed+developed tools).
>
> no, really, there was too much negativity.
>
> sorry that i bothered you all.
>
> ~mayuresh
>
>
>

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

[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 complex.  Perhaps we
should call them "complexifying" compilers.

Generally, model-to-model transformations (which is effectively what
compilers do under the covers) are easier to define when we transform from
a higher level of abstraction to a lower level of abstraction.  As folks in
the MBSE field explain it, trying to put a pig together from sausages.

On Wed, 5 Sep 2018 at 09:20, Charles Forsyth 
wrote:

> 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,
>>
>> 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/SubscriberLink/763641/c9a04da2a33af0a3/
>>
>> I'm curious how the Plan 9 C compiler fits into this story. I know that
>> it was designed to avoid many of the pitfalls of standard C. Does it try to
>> address some of these dangers or is it focused on making code more readable
>> so that problems are more apparent?
>>
>> How does everyone feel about the Plan 9/9front kernel? Have they gone
>> through hardening/testing exercises over the years? I'm curious what tools
>> are available to help discover bugs.
>>
>> Cheers,
>> Chris
>>
>

Re: [9fans] What are you using Plan 9 for?

[Tyga]

That's very neat !

You might want to consider using a derivative of that PDP-11 work in a IoT
(Internet of Things) context.

IoT devices really need a better programming environment than that provided
by Arduino development tools.

On 28 June 2018 at 02:20, Brian L. Stuart  wrote:

> On Wed, 6/20/18, Ethan A. Gardener  wrote:
> > but on the back burner is a
> > Forth-based project; a sort of operating system where the
> > primary interface to all tasks is a Forth interpreter. So
> > far, I've written the basics of a text editor. It's
> > *very* little code!
>
> I love seeing this idea coming back around.  Way back
> in college, one of my senior projects was a little OS on
> the PDP-11 that was done exactly this way.  The app
> language and the command language were a Forth
> implementation I had done out of curiosity in my freshman
> year.  About a year and half ago, I got it running again,
> first in simh, then on a little LSI-11 in those cute little
> BA11-VA boxes.  It was wild seeing that running again
> after over 30 years, and I found and fixed a concurrency
> bug. :)  One of my students did (mostly just started on)
> a project his past term that's gotten me to thinking a
> little about reimplementing the whole thing on a Pi.
>
> BLS
>
>

Re: [9fans] What are you using Plan 9 for?

[Tyga]

Talking of Forth,  it is worthwhile to note that Postscript as implemented
by Adobe for laser printers and subsequently for photo-typesetters, etc is
a very good example of Forth-like system running on bare metal and
providing an application specific programming + operating environment.

Years ago, Byte magazine published an excellent book "Threaded Interpreted
Languages" (TIL) which contains lots of good information, including details
of how to roll your own using the Z80 (yes, the book is that old).

On 27 June 2018 at 15:18, Iruatã Souza  wrote:

> On Wed, Jun 20, 2018 at 10:39 PM, Kurt H Maier  wrote:
> > On Wed, Jun 20, 2018 at 10:35:42PM +0100, Ethan A. Gardener wrote:
> >>
> >> a sort of operating system where the primary interface to all tasks is
> >> a Forth interpreter.
> >
> > I think we've talked about this in another venue some years back, but I
> > often thing of the OpenFirmware implementation used by the OLPC XO-1
> > laptop.  Instead of a BIOS or UEFI or linux trash in their stead, the
> > system was managed by an OpenFirmware installation, much of which was
> > written in Forth, and whose primary interface was a Forth shell.  This
> > environment had complete access to the hardware of the system, which
> > was used by the project to create really comprehensive hardware
> > diagnostics tools.
> >
>
> Kurt and Ethan,
>
> I am sure you know that, but Forth has basically started as an
> language + operating system and stayed there for quite some time.
> Forth hosted on other operating systems is the (not so) new thing.
>
> For a "recent" instance of Forth language+os for the pc, check Andy
> Valencia's ForthOS.
>
>

Re: [9fans] What are you using Plan 9 for?

[Tyga]

Re: your comment about trackpad / vertical mouse.

I had a similar RSI problem a couple of years ago.  I solved it by using a
Logitech trackball with my right hand - but only to move the cursor and I
used a MS optical mouse with the tracking window taped over so that I would
only use it to click or scroll with the left hand.  I had to tape over the
window so that moving the mouse wouldn't actually move the pointer which I
had carefully positioned with the trackball.  Cured the RSI and now able to
even use a normal trackpad on a notebook for short periods of time.  But I
do prefer to use my desktop for serious amounts of work.



On 26 June 2018 at 13:24, 刘宇宝  wrote:

> // seems this email was lost according to http://marc.info/?l=9fans, send
> again, sorry if duplicated.
>
> On Jun 24, 2018, at 5:12 PM, 刘宇宝  wrote:
>
> Very like your comment, thanks! On macOS I mainly use iTerm2 + VIM + SSH +
> Firefox, if Plan 9 had a decent native web browser I may use 9front for
> serious daily work. I don't care much native app stack because I mainly do
> Python/Java/Node on remote Linux server.
>
> I hate trackpad, it hurts my wrists, I just got a cheap vertical mouse,
> may buy Evoluent mouse later. Meanwhile, I was wondering whether trackball
> will heal my wrists more.
>
> Recently I read Rob Pike's "Systems Software Research is Irrelevant", I
> felt pity, and I was wondering what the operating system would look like in
> the future,  here is my stupid optimistic predication:
>
> • Server hardware will become extreme powerful,  TB DRAM,
> non-volatile memory, NVMe disk, 100Gb ethernet, the paradigm of separate
> cpu server, file server, (a little fat) terminals will come back to be
> mainstream,  network of piles of cheap PCs will go away.
> • Linux，even BSD，became the underlying device driver and "BIOS",
> this is almost the current situation, Linux KVM, Xen + Linux dom0 hide
> details of hardware. This layer takes care maximum hardware support and raw
> performance.
> • *Distributed* operating systems above KVM/Xen will step into a
> period of great development, hardware support and maximum raw performance
> are not top priorities, *OS native* fault tolerance, simple and clear
> distributed process scheduling, easy and consistent IPC/RPC API will win,
> Google Kubernetes will die. Many ideas of Plan 9 will revive, just like
> memory garbage collecting revived after about 30 years.
>
> Regards,
> Yubao Liu
>
> >
> > From: 9fans-boun...@9fans.net <9fans-boun...@9fans.net> on behalf of
> Rui Carmo 
> > Sent: Thursday, June 21, 2018 5:06 PM
> > To: Fans of the OS Plan 9 from Bell Labs
> > Subject: Re: [9fans] What are you using Plan 9 for?
> >
> > I’m late to the thread, but this seems like a good point to step in.
> >
> > I’m using plan9 on a quad-core Raspberry Pi as a sort of universal
> terminal to manage some of my home machines, and recently deleted the
> 9front VM I had on my home KVM server because even though the programming
> model and Go support were nice, most of my day-to-day work is on cloud
> solutions and there was no easy way to make those co-exist with Plan9 usage.
> >
> > There were a few discussions in this thread around dev stacks, browsers,
> etc., and my $0.02 on that is that I could probably work in Plan9 on a
> daily basis _if_ it had a usable (i.e., all the warts including JavaScript
> and fonts) web browser, but that the lack of alignment (intended or
> otherwise) with Linux tools and app stacks (SSH, Node, Python, Java) would
> make it very painful.
> >
> > Running a remote browser (which is what I do often in that Pi) sort of
> works, but you never get the full benefits you’d get with a native process.
> And lack of access to modern app stacks renders the platform unattractive
> for mainstream development work.
> >
> > But what killed it for me was the need for chording (mouse or keys).
> Using a modern trackpad on a MacBook or Surface device is a quantum leap
> beyond using a mouse for general use, and the lack of a modernised Rio with
> enough thoughtful design to overcome the differences in philosophy is the
> first barrier to continued usage.
> >
> > Acme is something I miss on occasion, but modern GUI editors compensate
> in other ways (at the expense of resource usage, etc., but with a massive
> boost in productivity for me). Also, I’m typing this on an iMac 5K with
> nearly unmatched font rendering and legibility (the only thing that comes
> close is the Surface Pro alongside it). Visuals matter a great deal.
> >
> > There is an unmatchable degree of purity in Plan9, but (even though the
> diehards will stick their ground and claim it’s perfect to the exclusion of
> other modern comforts) to coexist successfully it has to provide more
> affordances.
> >
> > Kind Regards,
> >
> > R.
> >
> > > On 14 Jun 2018, at 04:53, 刘宇宝  wrote:
> > >
> > > Compared to "not for you", "don't care",  "intend to not be
> successful", I like more the topic of cat-v irc channel 

Re: [9fans] What are you using Plan 9 for?

[Tyga]

I fear that I might be starting a flame war, but ...

I have been using Plan9 (and Inferno to a lesser extent) on and off for
about two decades.  The concepts are very enticing.  But like any other
niche OS (e.g. Minix) the biggest stumbling block seems to be device
drivers.  And display adaptors are one of the most challenging for device
drivers which in turn means that anything that depends on X, etc is going
to be a challenge.  Sound cards, etc are almost as bad.

For these reasons Plan9 struggles to become more widely adopted as a
desktop system and in turn porting programs is either taken on as a
challenge or labour of love.  So it is not surprising that the utilities
that you mention are lagging behind the ports to more widely used platforms.

To answer your question, there are a some people who use Plan9 seriously,
but I doubt that their numbers will ever become much larger. Personally, I
would like to use Plan9 for servers, but due to the development toolchain
issues I keep going back to Linux variants.

Wishing you continued with your adventure series.


On 11 June 2018 at 16:14, 刘宇宝  wrote:

> Yesterday night I finished the sixth article of my Plan 9 adventure series
> at Zhihu, a Chinese Quora like site, https://zhuanlan.zhihu.com/c_
> 185117725
>
> I feel many things are interesting and special, such as Rio(simple and
> beautiful, love it), Acme(so easy to extend), 9p(simple and clean),
> rc(right shell), but I'm still not very used to heavy use of mouse.
>
> I find a bunch of game emulators, instruction simulators, fs servers,
> incomplete POSIX environment, all seem very old, this makes me wondering
> whether anybody still seriously uses(or used?) Plan 9 for serious work,
> what software they frequently use, what software is most lack of.
>
> For my daily work and hobby, I use macOS for Desktop and Linux for
> Server,  most frequently used softwares include:
>
> * iTerm2+Vim+Spacemacs: I can use Acme + rc instead.
> * SSH:  Plan9 has an old SSH client.
> * Perl, Python, NodeJS: Probably I can't get latest versions and enough
> support for their C extensions, it's basically fine, I can edit it with
> Acme and run on Linux.
> * VirtualBox:   I haven't played vmx.
> * Firefox:  I heard there is an old version running on X.
> Abaco and Mothra are not enough to render correctly most (crappy) web pages.
> * Apple Mail:   haven't played upasfs, I guess this is enough.
> * Wechat:   certainly not exist on Plan 9, it's fine,  it doesn't
> exist on Linux too.
> * Video Player:  don't know any on Plan 9.
>
> So far, seems the most lacking software for me is a good enough Web
> browser.
>
> Oh, don't get me wrong, I don't care whether Plan 9 will win the market,
> I'm just curious whether Plan 9 can still be used seriously.
>
> Thanks,
> Yubao Liu
>
>
>
>

Re: [9fans] R.I.P cs.bell-labs.com

[Tyga]

Would GitHub or similar be easier to manage and track changes,
contributions, etc?

I would prefer to have separate directories for common, 9front specific,
native specific.  At the moment stuff is a bit all over the place.

On 5 January 2018 at 10:24, Lyndon Nerenberg  wrote:

> On Thu, 4 Jan 2018, Joseph Stewart wrote:
>
> Someone (not me) should make a 9p to S3 service and put all the goodies
>> there.
>>
>
> Why not just set up a public Plan9 fileserver?
>
>

Re: [9fans] What does your fileserver consist of?

[Tyga]

Hi Jim,

I think you should be fine.  I'm using five rescued HP ePCs

all
with PIII @800MHz, 128MB RAM and a range of HDs, including one one with
80GB.  All connected via a HP ProCurve 1G switch.  I have one RPi2
connected to the cluster and it, too, works fine with them.  Still having
struggles with auth, etc.

For what it's worth, I have an ePC booting off a compact flash card (via an
IDE adaptor) - that one is rather slow.  I haven't benchmarked this cluster
against anything, but my impression is that it's Ok, but a single
contemporary PC seems faster (SSD, SATA3, etc)

Well that's one dodgy data point for you!


On 12 October 2016 at 11:33, James A. Robinson 
wrote:

> Folks,
>
> One of the things I'm thinking about is setting up a full Plan 9
> cluster, meaning one of the components would be a stand-alone
> fileserver hooked up to a decent amount of storage.
>
> I was wondering what experience people have had with slower or faster
> machines in this role?
>
> I was wondering whether or not it'd be feasible to hook up something
> like http://tinyurl.com/jgov5gc (Amazon.com) to something small like a
> Raspberry Pi 3, or if the I/O would be too much for that kind of
> computer to handle.
>
> Does anyone here run a fileserver on a small computer like a
> raspberry pi 3, or perhaps something like an Intel nuc?
>
> I wouldn't be supporting multiple users, just myself moving between
> a couple of devices.
>
> Jim
>
>

Re: [9fans] Compiling ken-cc on Linux

[da Tyga]

I have been following this discussion about the C compiler and can no
longer stop myself from making a (snarky?) comment.

The K standard for C was very much written when the C language was a
higher than assembler language for the PDP-11 (at least that's how I became
acquainted with it back in 1976).  Most of us, in those days, welcomed
something that was more high level than macro-assembler and yet amenable to
writing operating systems and utilities (unlike FORTRAN, ALGOL and COBOL of
that era).  Many of us would use the -s switch to check the generated
assembler code and in some cases even modify the assembler code for
selected functions to get exactly the desired result.

The PDP-11 had a rather simple instruction set, thus the compiler produced
relatively predictable code.  The undefined behaviours in many cases meant
that at least on the PDP-11 we would know what to expect.  It was only once
code was ported to other systems that these assumptions started getting
sorely tested.

Fast forward to present time, we have a bloated C standard and even more
bloated C++ standards.  The target instruction sets are rich with lots of
special case instructions; out of sequence execution; multi-level caches
add further constraints.  So today's compilers need to analyse complex
source code to run with good performance on extremely complex targets.  We
shouldn't forget that in the case of the x86 family the compilers need to
optimise for an ever evolving instruction set and retain backward
compatibility across earlier variants.


On 28 November 2015 at 12:01, erik quanstrom  wrote:

> > Funny, but actually I was wondering if there is any subtle issue in the
> > standards of the C language that makes it somehow hard to implement.
> > For example I've met a few times weird implementations of libraries and
> > frameworks dictated by broken standards: once they are in, they can never
> > be removed due to backward compatibility. I thought that Charles (that
> also
> > implemented the Limbo compiler) might have referenced these kind of
> issues
> > in his pun.
>
> i think the simple answer is: no.  but many folks just love complexity,
> and are
> determined to find it.  if you give such a person one problem, they'll
> come back
> with two problems.  i call these folks complicators.  don't be a
> complicator.
>
> (i have to remind myself this from time to time.)
>
> - erik
>
>

Re: [9fans] rpi boot

[da Tyga]

I might be doing something wrong here, I was just responding to Adriano's
post - which I thought remained at the bottom of my response.

On 24 October 2015 at 10:00, Andrew Simmons  wrote:

> I’m not sure where you’re up to, so apologies if this isn’t helpful, but
> to get the image on to the SD I just did what it says here (I use a Mac):
>
> https://www.raspberrypi.org/documentation/installation/installing-images/
>
> https://www.raspberrypi.org/documentation/installation/installing-images/mac.md
>
> This was a while back on OSX Yosemite. I haven’t tried on El Capitan. I
> found getting the standalone image to boot trivially simple.  To add
> networking I just did what it says here:
>
> https://www.raspberrypi.org/forums/viewtopic.php?f=80=24480
>
> -ie copy cmdline-demo-net.txt to cmdline.txt in the boot partition.
>
>
>
> > On Oct 24, 2015, at 10:25 AM, Adriano Verardo 
> wrote:
> >
> > I'm using a rpi with prof Miller Plan9 img.
> > A remarkable work.
> > I would like to know the details of the rpi boot process.
> > i.e. where u-boot is stored, how to generate a micro sd etc.
> > After reading some doc, I'm getting a bit confused.
> > Could someone kindly indicate a "roadmap" and some good doc ?
> >
> > Thanks in advance
> >
> > adriano
> >
> >
> >
>
>
>

Re: [9fans] rpi boot

[da Tyga]

I don't have the Plan9 uSD card handy, but to the best of my recollection
all Raspberry Pi SD cards have at least two partitions on them.  The ARM
processor remains halted upon reset and the VideoCore loads the image from
the (first?) DOS formatted partition.  Once that image is loaded into RAM,
the ARM processor starts running it.

I'm not even sure that uboot is involved.

You might find some useful information at:
http://raspberrypi.stackexchange.com/questions/10489/how-does-raspberry-pi-boot

Whilst the details are for Linux, I assume that Plan9 booting is very
similar.




On 24 October 2015 at 08:25, Adriano Verardo 
wrote:

> I'm using a rpi with prof Miller Plan9 img.
> A remarkable work.
> I would like to know the details of the rpi boot process.
> i.e. where u-boot is stored, how to generate a micro sd etc.
> After reading some doc, I'm getting a bit confused.
> Could someone kindly indicate a "roadmap" and some good doc ?
>
> Thanks in advance
>
> adriano
>
>
>
>

Re: [9fans] Small Plan 9 Platforms

[da Tyga]

Hi Brian,

Plan 9 works really well on a Raspberry Pi B for me.  Haven't tried it on a
RasPi 2 yet though.

I would be rather cautious about so called compatible products.  I have yet
to meet a product that is truly compatible and the quirks tend to take up a
disproportionate amount of time to resolve.  When you are trying to get a
course together you have enough to contend with before getting caught out
by incompatibilities.

Is there any reason you don't choose to just go with Raspberry Pi as is?
After all, it is cheap and with lots of support.

On 8 August 2015 at 11:13, Nick Owens misch...@offblast.org wrote:

 brian,

 i have started work on porting 9front to
 http://www.elinux.org/MIPS_Creator_CI20.

 this board has quite a number of features, and might be useful for
 education if the cost isn't prohibitive.

 nick

 On Fri, Aug 7, 2015 at 6:09 PM, Brian L. Stuart blstu...@bellsouth.net
 wrote:
  I'm teaching a special topics course this fall I'm
  calling Computing in the Small.  Right now, I'm
  leaning toward conducting it on a platform that
  runs Plan 9.  I'm looking for something based on
  ARM or MIPS and that has some useful connection
  to the external world in the form of GPIOs.  SPI,
  I2C, and analog I/O would be nice to have too.
  Obviously, the Raspberry Pi is a candidate.  What
  are some others?  I've seen some code in the
  source tree for the BBB.  Has anyone tried it out
  to see what is and isn't there?  How about the
  Banana Pi?  The SATA port on it is quite appealing.
  Some of the other options I've been looking at
  include the VIA APC Rock and Paper, the Phytec
  Cosmic, the CubieBoard, the Odroid, the Riotboard,
  and the Wandboard.  Has anyone done anything
  on porting Plan 9 to any of them?  Are there others
  I'm missing that would be good targets for such a class?
 
  Thanks in advance,
  BLS
 
 
 

Re: [9fans] DigiLand DL701Q quad core tablet

[da Tyga]

Plan9 kernel is monolithic with the drivers required for a specific
platform compiled in.

So you might need to write specific drivers for new hardware if they are
not already available.

The paper:  http://plan9.bell-labs.com/wiki/plan9/compiling_kernels/ explains
the steps required to generate a new kernel.  BTW, even for the same
hardware, the kernels are different for terminals, cpu servers, etc.


On 19 December 2014 at 07:06, cigar562hfsp952f...@icebubble.org wrote:

 cigar562hfsp952f...@icebubble.org writes:

  Yes, I figured it might require some new device drivers, but why would
  it require a new kernel?  I thought there was already a Plan 9 kernel
  for Arm Cortex-series processors.  That's one of the reasons why I
  developed such a crush on OMAP.  ;)

 BTW, that was not intended as a rhetorical question; I really am curious
 why the device would require a whole new kernel...

Re: [9fans] questions about 9atom and 9legacy; and their updates

[da Tyga]

Thank you for the clarification, I was puzzling over similar issues.

You could also consider 9vx http://swtch.com/9vx/ especially if you are
tempted to try running under Qemu or some other virtualised environment.
Although I'm only at the exploratory stage, I find 9vx more useful than
9front.

I also use the Raspberry Pi image
http://plan9.bell-labs.com/sources/contrib/miller/9pi.img.gz which is
surprisingly easy to install and use.  I found it easier to get going than
Bell Labs release on various old i386 systems.



On 19 December 2014 at 02:46, David du Colombier 0in...@gmail.com wrote:

  1) How often does Bell Lab's version change? How often/well
  do patches from 9legacy enter BL's version? Some numbers?

 There used to be changes on sources almost every day,
 up to March 2014. Now the latest change is from September 17.

 Most of the 9legacy changes where included into Plan 9.
 Unfortunately, Plan 9 is now in a pretty frozen state.

  2) How do 9atom and 9legacy notice that there has been
  a change in BL? (I'd guess that 9legacy could notice
  immediately, but ...) How is it with 9atom?

 I'll speak for 9legacy. Most of the patches are automatically
 applied on the latest Plan 9 CD image on a regular basis.

 When a patch doesn't apply anymore, I fix it.
 When a patch has already been applied, I remove it.

  3) How is updating supposed to work in case of 9atom
  and 9legacy (as compared to BL's replica) I.e., when
  I decide to use either 9atom or 9legacy and at some
  point there is some change in them, will I / can I
  easily notice and follow?

 9legacy is really just a set of patches available on
 top on Plan 9. It's not a full distribution like 9atom
 or 9front.

 I didn't want to run my own replica server, having
 to keep the whole repository synchronized with Plan 9.

 Instead, I chose to simply provide a list of patches
 that any Plan 9 user might find useful and install
 on its machine.

 If you choose to install from a 9legacy CD image, you
 will get updates from the /n/sources replica server.

 That said, now that Plan 9 is not as actively maintained
 as it used to be, 9legacy might move to his own
 full distribution.

  5) I am puzzled about licences. At one point I almost
  thought that the software is actually BSD-like
  (i.e. you can do almost whatever, no copyleft,
  Lucent Public License Version 1.02). Now I read:
 
  In February 2014 the University of California, Berkeley, has been
  authorised by the current Plan 9 copyright holder – Alcatel-Lucent
  – to release all Plan 9 software previously governed by the Lucent
  Public License, Version 1.02 under the GNU General Public License,
  Version 2
 
  so the mentioned univesity will offer it under GPL, which is viral
  (is copyleft). That surprises me...

 Plan 9 is currently available under LPL 1.02 (/n/sources)
 or GPLv2 (https://github.com/brho/plan9).

 Unfortunately, this is a complicated story. Ron could tell you
 more about this. Alcatel-Lucent refused to distribute Plan 9
 under a more liberal licence than GPLv2.

 --
 David du Colombier

Re: [9fans] Chrome and 9

[da Tyga]

I think that Plan9Port using the underlying Linux OS might be a better
choice.  I have also been thinking about cross-compiling from a Plan9
install (such as that on Raspberry Pi) to Samsung ARM based ChromeBook.

Getting Plan9 to work with fastboot and implementing device drivers for the
various ChromeBooks might be a lot of work.  Don't know enough to justify
my assumptions though.

On 8 December 2014 at 06:35, Roswell Grey orangecal...@gmail.com wrote:

 It's no question that the Chromebook makes a wonderful candidate to
 integrate features of 9 into. The thing was practically BUILT for
 distributed computing, what with app servers and cloud integration tightly
 integrated into the hardware. What I was thinking was creating a chrome
 extension for 9P and the distributed file system, so that there'd be an
 easy way to connect 9 machines and maybe even create a chrome 9 grid for
 super processing. What would be your opinion on doing such a thing?
 Practical? Waste of time? Wanna help?