[9fans] There is no fork

[9fans] There is no fork

[Benjamin Huntsman]

[-- Attachment #1: Type: text/plain, Size: 277 bytes --]

Just curious as to the state of the union.  Is 9front pretty much the de facto "official" Plan 9 these days, or does anyone still use or maintain any of the following:


9atom

NIX

9legacy

The original Bell Labs distribution


Thanks for your input!


-Ben


[-- Attachment #2: Type: text/html, Size: 1165 bytes --]

Re: [9fans] There is no fork

[Lucio De Re]

On 2/10/18, Benjamin Huntsman <BHuntsman@mail2.cu-portland.edu> wrote:
> Just curious as to the state of the union.  Is 9front pretty much the de
> facto "official" Plan 9 these days, or does anyone still use or maintain any
> of the following:

I'm with David (legacy), nearly all the way.

That said, I deem it unfortunate that there isn't a drive to
consolidate the various flavours of Plan 9 into a single offering, or
at least identify and discuss the differences and provide for the
choices from a single source (pun intended).

And, yes, after an uncomfortable separation, I am lurking here again.

Hello, everyone!

Lucio.

PS: Ron Minnich, my old address was <lucio@proxima.alt.za>, it is now
<lucio.dere@gmail.com>. Both are still in existence (in case you wish
to make adjustments to your mailer configuration).

Re: [9fans] There is no fork

[Ethan Grammatikidis]

On Sat, Feb 10, 2018, at 4:24 AM, Lucio De Re wrote:
>
> That said, I deem it unfortunate that there isn't a drive to
> consolidate the various flavours of Plan 9 into a single offering, or
> at least identify and discuss the differences and provide for the
> choices from a single source (pun intended).

Identifying and discussing the differences might be nice.
Providing a single source sounds suspiciously like work. :)
In any case, this very mailing list seems a useful single point
of contact for many forks.

--
The lyf so short, the craft so long to lerne. -- Chaucer

Re: [9fans] There is no fork

[Jens Staal]

[-- Attachment #1: Type: text/plain, Size: 599 bytes --]

There is also one additional fork that has diverged quite significantly
from its Plan9 roots: Harvey OS.

One thing that might be interesting to back port from Harvey is the
modernized APE.

Den 10 feb. 2018 03:51 skrev "Benjamin Huntsman" <
BHuntsman@mail2.cu-portland.edu>:

> Just curious as to the state of the union.  Is 9front pretty much the
> de facto "official" Plan 9 these days, or does anyone still use or maintain
> any of the following:
>
>
> 9atom
>
> NIX
>
> 9legacy
>
> The original Bell Labs distribution
>
>
> Thanks for your input!
>
>
> -Ben
>
>
>

[-- Attachment #2: Type: text/html, Size: 1590 bytes --]

Re: [9fans] There is no fork

[hiro]

The reason 9front exists is because it was too difficult to get
patches applied to mainline plan9. Like geoff for mainline, 9front has
cinap as gatekeeper to maintain quality and when possible stability.
Also cinap is a programming monster and keeps on improving 9front
in big steps, so there isn't really any competition from the
point of view of a user.

Our way of collaboration might not be everybody's style: Grant money
doesn't exist, just one clear goal for everybody: advancing 9front.
Depending on the quality, contributions are either discussed till
fruition or, for trivial stuff, cleaned up and applied without big
discussion. Nobody is left to wonder for months why his patches suck,
there's always detailed feedback, for the people who want to improve.
Even as a bystander you can learn a lot from the process.

Admittedly a big chunk of the communication happens on irc (#cat-v)
and is not always
efficient. Sadly it's hard to work together if you don't all sit in
the same lab, so it's the best we can do. Still there are very
enlightening moments every now and then that are extremely satisfying.
Honest and early feedback helps the less experienced people not get
off track.

For some of us 9front is also a very important counterbalance to bad
technological decisions at our workplaces.

Of course we also multiply the rumours, secrecy, fear and
misunderstandings that have arisen around the plan 9 community with
our awesome propaganda and humour. So I see people getting offended
and distancing themselves. Sometimes it's not clear whether we should
laugh about this or be sad.

I don't speak for 9front, I speak for myself. People sadly aren't used
to the idea that we're all just independent individuals, so I'm
leaving this disclaimer here trying to avoid making a bad impression
on the project.

Re: [9fans] There is no fork

[Ethan Grammatikidis]

eeh... I cut out a bunch of stuff from my last mail because I didn't want to derail the thread.

Anyone want a new thread on discussing the differences, or shall we just bung it all here?

Re: [9fans] There is no fork

[hiro]

i forgot to mention: if you are confused why valuable contributions to
another fork are not included in 9front, and you don't know why,
please come and talk to us about it. either we didn't see it or
there's a architectural decisions or goals that don't align with
9front.

in general if you can advance plan9 9front would love to take part.
multiple people track very closely what is happening elsewhere, though
there's definitely some randomness involved, and a selection process
to prevent bad decisions from piling up.

we have a wish to stay compatible as much as possible. even
questionable changes in mainline were integrated when there was no
other way.

we have a mailing list, so it doesn't matter whether you irc or not.

Re: [9fans] There is no fork

[Ethan Grammatikidis]

So we're all putting it here?  Okay then.  I agree with pretty-much
everything hiro said this time.

Regarding differences between forks, what springs to my mind is the
fixes 9front needed to host cat-v.org.  The site was switched to a
9front server at the time of Uriel's death, news of which triggered a
huge traffic increase for a while.  It was evident that no-one had put
Plan 9 under that kind of load before, or if they had, they hadn't
released their fixes.  I remember someone saying, "Everyone who used
Plan 9 seriously must have maintained their own fork."

Hosting cat-v.org may be unusual load.  Web server and CMS are both a
lot of shell scripts, so there is a lot of pipes and new processes all
the time.  9front has received more fixes relating to hosting it over
the years.

There was also a change to factotum to prevent it deadlocking the
filesystem.  I don't remember what triggered that bug!

Plenty of other stuff, but I'm out of time to write (for once).  I
have no idea if any other forks picked up any of the changes, although
I'm sure 9atom has its own fixes particularly related to NAS work.

Re: [9fans] There is no fork

[as]

[-- Attachment #1: Type: text/plain, Size: 780 bytes --]

Ive been using 9front as a primary system ever since the one true
distribution neutered bintime and replaced it with the nsec system call.
Its nice that the 9front maintainers voulenteer to keep plan9's simplicity
alive (9atom is great too and has myriad device drivers written for modern
hardware as well). Maintaining these systems is a lot more meritable of an
endeavor than inhaling the aeresol of the Linux cloud and contributing to
an ecosystem superceeded over 3 decades ago.

On Sat, Feb 10, 2018, 02:53 Ethan Grammatikidis <eekee57@fastmail.fm> wrote:

> eeh... I cut out a bunch of stuff from my last mail because I didn't want
> to derail the thread.
>
> Anyone want a new thread on discussing the differences, or shall we just
> bung it all here?
>
>

[-- Attachment #2: Type: text/html, Size: 1052 bytes --]

Re: [9fans] There is no fork

[Giacomo Tesio]

To my knowledge this is the set of active projects based on Plan 9:

9atom and 9front are both actively maintained.
Both stick strongly to the original Plan 9 from Bell Labs design.
AFAIK, 9front introduce more innovations, both in kernel and in user
space, but what make it unique is the #cat-v community.

9legacy is not a really fork, but an organized collection of patches,
and is still actively maintained.
Another non-fork active project is Plan 9-ANTS
(http://www.9gridchan.org/ ) which also provides a 9front-based amd64
iso and a free 9P grid online.

Harvey's kernel is based on NIX, and AFAIK, it's the only project
where NIX development is active.

Forsyth's Plan-9k had some development in mid 2017.
It's 2015 version was the starting point of Jehanne's kernel, which is
my own research operating system (that also includes several of
9front's improvements).
Jehanne is the project that diverged most from the original Plan9
design, with its own set of crazy decisions, but currently it's an
unstable toy.


Giacomo

2018-02-10 3:48 GMT+01:00 Benjamin Huntsman <BHuntsman@mail2.cu-portland.edu>:
> Just curious as to the state of the union.  Is 9front pretty much the de
> facto "official" Plan 9 these days, or does anyone still use or maintain any
> of the following:
>
>
> 9atom
>
> NIX
>
> 9legacy
>
> The original Bell Labs distribution
>
>
> Thanks for your input!
>
>
> -Ben
>
>

Re: [9fans] There is no fork

[Rui Carmo]

Jehanne is something I’ve been keeping track of, in hopes that rio gets nicer defaults. You should write more about it. :)

I’ve been toying with the notion of hacking a nicer (for me) visual theme, but lack of time prevailed. But I will move my Pi to 9front as soon as possible...

R.

> On 11 Feb 2018, at 12:26, Giacomo Tesio <giacomo@tesio.it> wrote:
> 
> To my knowledge this is the set of active projects based on Plan 9:
> 
> 9atom and 9front are both actively maintained.
> Both stick strongly to the original Plan 9 from Bell Labs design.
> AFAIK, 9front introduce more innovations, both in kernel and in user
> space, but what make it unique is the #cat-v community.
> 
> 9legacy is not a really fork, but an organized collection of patches,
> and is still actively maintained.
> Another non-fork active project is Plan 9-ANTS
> (http://www.9gridchan.org/ ) which also provides a 9front-based amd64
> iso and a free 9P grid online.
> 
> Harvey's kernel is based on NIX, and AFAIK, it's the only project
> where NIX development is active.
> 
> Forsyth's Plan-9k had some development in mid 2017.
> It's 2015 version was the starting point of Jehanne's kernel, which is
> my own research operating system (that also includes several of
> 9front's improvements).
> Jehanne is the project that diverged most from the original Plan9
> design, with its own set of crazy decisions, but currently it's an
> unstable toy.
> 
> 
> Giacomo
> 
> 2018-02-10 3:48 GMT+01:00 Benjamin Huntsman <BHuntsman@mail2.cu-portland.edu>:
>> Just curious as to the state of the union.  Is 9front pretty much the de
>> facto "official" Plan 9 these days, or does anyone still use or maintain any
>> of the following:
>> 
>> 
>> 9atom
>> 
>> NIX
>> 
>> 9legacy
>> 
>> The original Bell Labs distribution
>> 
>> 
>> Thanks for your input!
>> 
>> 
>> -Ben
>> 
>> 
> 

Re: [9fans] There is no fork

[Lyndon Nerenberg]

> Forsyth's Plan-9k had some development in mid 2017.

Where did that go?  I remember there were some changes there I was quite
interested in, but I lost the reference to the repo source before I had a
chance to do anything with the updates.

Re: [9fans] There is no fork

[Benjamin Huntsman]

[-- Attachment #1: Type: text/plain, Size: 2740 bytes --]

> 9atom and 9front are both actively maintained.


It seems like 9atom is not actually actively maintained any longer.  I hope Erik sees this and refutes me, though!

I was aware of Harvey, Jehanne, and plan9-9k, though I didn't mention them because I wasn't sure how "mainstream" they were, or if there was active development in the case of plan9-9k.  Please pardon me. :)


To be honest, I was sort of hoping to hear someone say that 9atom with the NIX kernel is the way to go.  Unfortunately, I mostly use VMware and a few old-ish but still 64-bit ThinkPads, and 9atom won't so much as boot on any of them.  Anyone on here managed to get 9atom to run in VMware or on a W500-series (500, 520, 530)  ThinkPad?


Or, if one wants NIX but to stay a little closer to the original distribution, are there options, or is Harvey the only way?


Anyway, I also want to say thank you to the smart people on this list who have maintained and advanced Plan 9 in its various forms over the years!!


Thanks.


-Ben


________________________________
From: 9fans-bounces@9fans.net <9fans-bounces@9fans.net> on behalf of Giacomo Tesio <giacomo@tesio.it>
Sent: Sunday, February 11, 2018 4:26 AM
To: Fans of the OS Plan 9 from Bell Labs
Subject: Re: [9fans] There is no fork

To my knowledge this is the set of active projects based on Plan 9:

9atom and 9front are both actively maintained.
Both stick strongly to the original Plan 9 from Bell Labs design.
AFAIK, 9front introduce more innovations, both in kernel and in user
space, but what make it unique is the #cat-v community.

9legacy is not a really fork, but an organized collection of patches,
and is still actively maintained.
Another non-fork active project is Plan 9-ANTS
(http://www.9gridchan.org/ ) which also provides a 9front-based amd64
iso and a free 9P grid online.

Harvey's kernel is based on NIX, and AFAIK, it's the only project
where NIX development is active.

Forsyth's Plan-9k had some development in mid 2017.
It's 2015 version was the starting point of Jehanne's kernel, which is
my own research operating system (that also includes several of
9front's improvements).
Jehanne is the project that diverged most from the original Plan9
design, with its own set of crazy decisions, but currently it's an
unstable toy.


Giacomo

2018-02-10 3:48 GMT+01:00 Benjamin Huntsman <BHuntsman@mail2.cu-portland.edu>:
> Just curious as to the state of the union.  Is 9front pretty much the de
> facto "official" Plan 9 these days, or does anyone still use or maintain any
> of the following:
>
>
> 9atom
>
> NIX
>
> 9legacy
>
> The original Bell Labs distribution
>
>
> Thanks for your input!
>
>
> -Ben
>
>


[-- Attachment #2: Type: text/html, Size: 5426 bytes --]

Re: [9fans] There is no fork

[Giacomo Tesio]

2018-02-12 0:48 GMT+01:00 Benjamin Huntsman <BHuntsman@mail2.cu-portland.edu>:
> Or, if one wants NIX but to stay a little closer to the original
> distribution, are there options, or is Harvey the only way?

Out of curiosity, what's your use case for the NIX kernel?


@Lyndon: https://bitbucket.org/forsyth/plan9-9k

@Rui: Jehanne diverged a lot from Plan 9, in a pursuit for my vision
of simplicity.
While it's in no way a Unix, many won't even consider it a Plan 9
system. Still for anyone interested: http://jehanne.io


Giacomo

Re: [9fans] There is no fork

[Benjamin Huntsman]

[-- Attachment #1: Type: text/plain, Size: 1479 bytes --]

> Out of curiosity, what's your use case for the NIX kernel?


Use case??  My use case for NIX, and Plan 9 in general, is basically "fun" and "curiosity".  For my day job I run AIX, IBM i, and Windows when I have to (which is a lot) :)





________________________________
From: 9fans-bounces@9fans.net <9fans-bounces@9fans.net> on behalf of Giacomo Tesio <giacomo@tesio.it>
Sent: Sunday, February 11, 2018 4:20 PM
To: Fans of the OS Plan 9 from Bell Labs
Subject: Re: [9fans] There is no fork

2018-02-12 0:48 GMT+01:00 Benjamin Huntsman <BHuntsman@mail2.cu-portland.edu>:
> Or, if one wants NIX but to stay a little closer to the original
> distribution, are there options, or is Harvey the only way?

Out of curiosity, what's your use case for the NIX kernel?


@Lyndon: https://bitbucket.org/forsyth/plan9-9k
forsyth / plan9-9k — Bitbucket<https://bitbucket.org/forsyth/plan9-9k>
bitbucket.org
Source for an experimental 64-bit Plan 9 kernel, and supporting software. It features a revised memory-management system, MCS spin locks, and other changes to system ...




@Rui: Jehanne diverged a lot from Plan 9, in a pursuit for my vision
of simplicity.
While it's in no way a Unix, many won't even consider it a Plan 9
system. Still for anyone interested: http://jehanne.io
Jehanne<http://jehanne.io/>
jehanne.io
Jehanne, an operating system derived from Plan9. Introduction overview, screen shot, Joan Documentation





Giacomo


[-- Attachment #2: Type: text/html, Size: 6952 bytes --]

Re: [9fans] There is no fork

[Ethan Grammatikidis]

On Mon, Feb 12, 2018, at 12:20 AM, Giacomo Tesio wrote:
> While it's in no way a Unix, many won't even consider it a Plan 9
> system. Still for anyone interested: http://jehanne.io

on principle, i very much like jehanne's decoupling policy. it was the growth of excessive coupling between software packages which terminated all remaining fun freedom and hope i got from linux. perhaps you saw examples of my erstwhile hate for package managers. linux-style package managers and bsd-style port trees facilitate and enable coupling. it's an 'erstwhile' hate because i'm trying not to get so angry these days, i'm not thinking of going back to the packaged-for-posix world at all.

perhaps it's ironic that i'm getting interested in forth. i intend to be very careful about interfaces in the long term.

--
The lyf so short, the craft so long to lerne. -- Chaucer

Re: [9fans] There is no fork

[Giacomo Tesio]

[-- Attachment #1: Type: text/plain, Size: 2373 bytes --]

2018-02-12 2:10 GMT+01:00 Ethan Grammatikidis <eekee57@fastmail.fm>:

> linux-style package managers and bsd-style port trees facilitate and
> enable coupling.
>
>
What a package manager really facilitate is version management.

That is when you want to use/update a software at version X that depends on
libraries at version Y and Z.
The use of dynamic linking make this complex and cumbersome. Also a single
filesystem hierarchy does not help

Plan 9 does not suffer of this problems because of several reasons:
- it does not support dynamic linking
- it is developed as a whole "batteries included"
- few external packages have being ported to it, and people who use them
know their stuff very well


Plan 9 (and 9atom/9front) is developed and distributed as "a whole system":
there is conceptually only one version for all the software and libraries
included.


Technically it's the simplest and optimal solution to the versioning
problem.

Indeed 9front uses a single mercurial repository (which is a versioning
system) to manage both development and system updates.


I carefully considered this approach for Jehanne too, but decided to try an
alternative design.

Obviously no dynamic linking will ever land in Jehanne, but I want to
enable more external softwares to run on it.
This way I reduce the responsibilities of the project and size it to the
stable workforce (that is: I, me and myself).

It might seem counter intuitive to say that using gcc instead of ken-c
simplify the system.
It's true that it increase the complexity of the system during compilation,
but it reduce the scope of Jehanne itself.


So Jehanne's core system can follow the whole system development approach
of Plan 9, but it's a minimal system and an included package manager will
allow the installation of other useful software.


The problem is that the perfect package manager does not yet exists for the
Jehanne design.
Probably the nearest thing is BSD's pkgsrc, but it doesn't get advantage of
namespaces.

And which language should I use to code an alternative?
Probably C. But I wonder if a more high level language could make the job
easier without increasing too much the project scope.
So far candidates alternatives (that I still need time to evaluate deeply)
are Wirth's Oberon-07 and Obi's Myrddin.


Giacomo

[-- Attachment #2: Type: text/html, Size: 3049 bytes --]

Re: [9fans] There is no fork

[Ethan Grammatikidis]

On Mon, Feb 12, 2018, at 8:33 AM, Giacomo Tesio wrote:
> 2018-02-12 2:10 GMT+01:00 Ethan Grammatikidis <eekee57@fastmail.fm>:
>> linux-style package managers and bsd-style port trees facilitate and enable coupling.
>
> What a package manager really facilitate is version management.
> That is when you want to use/update a software at version X that depends on libraries at version Y and Z.

That's the marketing blurb, I've heard it a thousand times before. It's almost as bad as the things git fanatics say. It's taking one small part of the problem and pretending that this is the important thing which it makes easier. The problem I'm talking about is not one small corner of the situation, it's an effect of the reason package managers exist. They exist to make it easy to find and install dependencies. So, for the last 10-12 years, maybe more, mountains of software have been produced on the assumption that it will be easy to find and install all their dependencies. That's only true for users of big 'distributions' which have lots of people, a large professional team or many contributors, to create and maintain the package tree.

> The use of dynamic linking make this complex and cumbersome. Also a single filesystem hierarchy does not help

Dynamic linking is probably the largest, most visible part of the problem, but your saying this makes me think you haven't tried to compile very much software -- certainly not on anything other than Debian or a similarly large distro where, these days, you can get all the dependencies by pasting a line the package author provided. I have. Many packages weren't bad, but some were downright painful. The painful ones particularly included dependencies for otherwise nice programs. I'd get 2 or 3 levels down the dependency tree, and suddenly, chaos! I always want to cite freedesktop.org who seemed to be leaders in making it painful, but it's been 9.5 years since i had anything to do with compiling their stuff so I won't say too much.

> Plan 9 does not suffer of this problems because of several reasons:
> - it does not support dynamic linking
> - it is developed as a whole "batteries included"
> - few external packages have being ported to it, and people who use them know their stuff very well
>
> Plan 9 (and 9atom/9front) is developed and distributed as "a whole system": there is conceptually only one version for all the software and libraries included.
>
> Technically it's the simplest and optimal solution to the versioning problem.
> Indeed 9front uses a single mercurial repository (which is a versioning system) to manage both development and system updates.
>
>
> I carefully considered this approach for Jehanne too, but decided to try an alternative design.
> Obviously no dynamic linking will ever land in Jehanne, but I want to enable more external softwares to run on it.

Two or more years ago, a #cat-v regular found insurmountable difficulties running X statically linked with musl. Oh look, there's freedesktop.org again. I think it was Red Hat who had found a way to make it so hard, their name certainly came up. It's not the first time Red Hat has caused problems, they were doing it in the first release following their IPO, in 1998. My Bourne shell skills were almost permanently harmed by attempting to learn from their massively complex init scripts at the time. Looking back, the message is clear: "You can't cope with this on your own. Buy a support contract now!" Oh look, Red Hat pay Lennart Poettering's wages... and now everything depends on dbus and systemd! Supercomputer software which has no reason to do anything but compute its stuff now requires systemd's logger.

Thinking about this stuff makes me bitter, so I ought to stop now. It's possible the things you want won't intersect with the things which caused me trouble, but I think I have considerable reason for pessimism. I'd like to think there are enough people who don't want to be tied up in all this pain to create some semblance of a software ecosystem outside it, but when you consider that few people want to start from the ground up, and how poettering and fd.o have their tentacles in crucial parts of the posix-related ecosystem, it looks impossible.

I'm now sticking to systems which have nothing to do with posix, at least for hobby use. I have a couple of android devices, but almost no desire to program them directly. I've even got qemu on one of them. I do use an emulator with a 2-level dependency, but if it had taken more than a tiny bit of effort to set up, i would have dropped it and used something else.

--
The lyf so short, the craft so long to lerne. -- Chaucer

Re: [9fans] There is no fork

[Lucio De Re]

On 2/12/18, Ethan Grammatikidis <eekee57@fastmail.fm> wrote:
> [ a neat rant I agree almost to the pixel with... ]

I (mostly) manage a (very small) team of younger programmers who only
really know Linux, and then the Debian or Ubuntu distros, almost
exclusively. My sentiments and Ethan's seem very similar.

I still compile all the NetBSD packages I install, sometimes at some
cost to my sanity, fully realising that my colleagues could not even
successfully install the necessary tools to do the same on Linux (I am
pressing them to use Go, it gives me an edge where they are unlikely
to  overtake my deeper knowledge - so that gets installed from
source).

I do believe the gospel of minimalism is hitting home though, because
I refuse to act as first line of defence, so by the time I'm willing
to help, their Humpty-Dumpty world lies shattered at our feet for me
to put together again. Not often enough, sadly.

Unfortunately, the difference between their "production" world and the
Plan 9 ecosystem is simply too big, they can't conceive of such
simplicity being viable and I can understand that. But there's a hint
of envy, even though there is so much Plan 9 does not support.

The message, of course, is that one should not need hundreds of
thousands of files deployed on a workstation and that there should be
packages to remove software, rather than install it. Who knows, that
may happen, one day.

Lucio.

Re: [9fans] There is no fork

[Ethan Grammatikidis]

On Mon, Feb 12, 2018, at 1:39 PM, Lucio De Re wrote:
> On 2/12/18, Ethan Grammatikidis <eekee57@fastmail.fm> wrote:
> > [ a neat rant I agree almost to the pixel with... ]

Thanks!

> The message, of course, is that one should not need hundreds of
> thousands of files deployed on a workstation and that there should be
> packages to remove software, rather than install it. Who knows, that
> may happen, one day.

I like it when the uninstall command is "rm -r". Sadly, I think the only unixy system where that's even remotely practical any more is Mac OS X. GNUstep too, of course, but I don't know if it will automatically search for packages you move.

As well as being removable, their foo.app directories can easily contain a lot of dependencies as well as the program itself, not relying on the system to provide all dependencies. I remember concluding that's how it should be done, but don't remember all my reasoning now.

--
The lyf so short, the craft so long to lerne. -- Chaucer

Re: [9fans] There is no fork

[Giacomo Tesio]

2018-02-12 14:05 GMT+01:00 Ethan Grammatikidis <eekee57@fastmail.fm>:
> On Mon, Feb 12, 2018, at 8:33 AM, Giacomo Tesio wrote:
>> 2018-02-12 2:10 GMT+01:00 Ethan Grammatikidis <eekee57@fastmail.fm>:
>>> linux-style package managers and bsd-style port trees facilitate and enable coupling.
>>
>> What a package manager really facilitate is version management.
>> That is when you want to use/update a software at version X that depends on libraries at version Y and Z.
>
> That's the marketing blurb, I've heard it a thousand times before. [...]
> So, for the last 10-12 years, maybe more, mountains of software have been produced on the assumption that it will be easy to find and install all their dependencies. That's only true for users of big 'distributions' which have lots of people, a large professional team or many contributors, to create and maintain the package tree.

True, but part of cost here is the complexity of the package manager.

>
>> The use of dynamic linking make this complex and cumbersome. Also a single filesystem hierarchy does not help
>
> Dynamic linking is probably the largest, most visible part of the problem, but your saying this makes me think you haven't tried to compile very much software -- certainly not on anything other than Debian or a similarly large distro where, these days, you can get all the dependencies by pasting a line the package author provided.

Well, I use Debian from Potato, but I've got my headaches with
pinning, backports, conflicts and broken upgrades.

Also, I think I've compiled my amount of software.
As a rather recent example, automating the compilation of the gcc
cross-compiler for Jehanne took its time since I had to compile and
install locally specific versions of autotools and binutils, without
forcing users to install texinfo.

I think I have an idea of what I'm doing, but I'm pretty open to
suggestions and criticisms: the best time for them is now, since I did
no real work on the matter.

> The painful ones particularly included dependencies for otherwise nice programs. I'd get 2 or 3 levels down the dependency tree, and suddenly, chaos!
> [...]
> Thinking about this stuff makes me bitter, so I ought to stop now. It's possible the things you want won't intersect with the things which caused me trouble, but I think I have considerable reason for pessimism.

Well, obviously I'm naive enough to try to do something better! :-D

I think the problem is really tied to the nature of software
development... just because bugs are.

To my money you have an alternative:
- to be mostly self contained (as Plan 9/9front does), which is the
optimal solution to the problem
- to leverage outside softwares which evolve outside your control

Both solution have to cope with bugs:
- in Plan 9/9front you fix them
- in other systems you can still fix them but if you contribute back
the fix things turn "complex"...

Versioning, dependency trees (or sometime even graphs) and all these
monsters comes from this problem.

The self-contained approach is way more efficient... and simpler. Thus
it's very attractive to me.

But, my insight is that these monsters need to be faced, and defeated. :-)
Since you can't stop (or control) the evolution of software you do not
code yourself, there's no way to avoid versioning and using that
software.

But again my insight is that using static linking and namespaces,
packages can be way easier to maintain.


Still, I'd really like to know details about your concerns and your
painful experiences, since they could put me on the right track.



> I'd like to think there are enough people who don't want to be tied up in all this pain to create some semblance of a software ecosystem outside it, but when you consider that few people want to start from the ground up, and how poettering and fd.o have their tentacles in crucial parts of the posix-related ecosystem, it looks impossible.

Well, actually there are several hobby OSes that do not support posix
and package management.
(and some have interesting ideas too...)

But the problem with your approach is not just posix compliance.


For example, in Jehanne most tools you are used in Plan 9 are not part
of the core system.

For example, porting Plan 9/9front games to Jehanne is trivial (could
even be automated), but their changes should not cause the core system
to "evolve".

So the solution, again, is installing them as packages, with their own
versions. And this is the reason why there are no games in Jehanne:
they are waiting for a package manager.


The problem, as always, is to get the axes right.


An OS core system should evolve as a whole.
But since its usefulness depend on the amount of things people can do
with it, it should also be able to run exogenous software.


The Plan9/9front approach is optimal because it's perfectly useful
exactly to the people it want to be useful to.


Jehanne is useless. It's just a toy, aka a research operating system. :-)
But in it's research scope is how to enable software development to
scale more easily than in mainstream alternatives.


My insight is that, as a simpler system, Jehanne will be more powerful.
And the additional simplicity/power will make such complex problems
almost disappear.


Giacomo

Re: [9fans] There is no fork

[Chris McGee]

Thanks everyone. This thread has been a fascinating read for me.

Chris

Re: [9fans] There is no fork

[tlaronde]

2018-02-12 14:05 GMT+01:00 Ethan Grammatikidis <eekee57@fastmail.fm>:
> > On Mon, Feb 12, 2018, at 8:33 AM, Giacomo Tesio wrote:
>> 2018-02-12 2:10 GMT+01:00 Ethan Grammatikidis <eekee57@fastmail.fm>:
>>> linux-style package managers and bsd-style port trees facilitate and enable coupling.
>>
>> What a package manager really facilitate is version management.
>> That is when you want to use/update a software at version X that depends on libraries at version Y and Z.
>
> That's the marketing blurb, I've heard it a thousand times before. [...]
> So, for the last 10-12 years, maybe more, mountains of software have been produced on the assumption that it will be easy to find and install all their dependencies. That's only true for users of big 'distributions' which have lots of people, a large professional team or many contributors, to create and maintain the package tree.

>From a different point of view, the problem is also that the developers,
using some developing tools (for example the GNU automake and autoconf),
don't really know what they are using, or, since "GNU is not Unix",
don't verify that their code is POSIX compliant (and to what level etc.;
when I began using Unix by discovering Linux, I remember reading a book
explaining that for C programming, when linking, you will add always
the Glib library because "there are probably things you will need in
it!"...).

The amount of dependencies of some packages is simply appaling. (One
example is TeXlive, because using some macros involve using an amount
not necessarily kwown of "other" macros, for a lot of people it is
simpler to "take it all" just in order not to "fail"; and this is
when you need only a part of it that you discover that this "all"
depends on things that you do not have on your system---a C++
compiler and so on).

--
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                       http://www.sbfa.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] There is no fork

[Steve Simon]

rob’s sam editor for X11 circa 1993 was a revelation for me. 

beautifully written and trivial to port to a dozen different platforms. a salutatory lesson to all.

autotools is horrid, though, fgb’s config script can often get foreign stuff to build. if you want to import code rather than just port it then my mkmk (mkfile generator) can help.

-Steve


> On 12 Feb 2018, at 16:13, tlaronde@polynum.com wrote:
> 
> 2018-02-12 14:05 GMT+01:00 Ethan Grammatikidis <eekee57@fastmail.fm>:
>>>> On Mon, Feb 12, 2018, at 8:33 AM, Giacomo Tesio wrote:
>>>> 2018-02-12 2:10 GMT+01:00 Ethan Grammatikidis <eekee57@fastmail.fm>:
>>>> linux-style package managers and bsd-style port trees facilitate and enable coupling.
>>> 
>>> What a package manager really facilitate is version management.
>>> That is when you want to use/update a software at version X that depends on libraries at version Y and Z.
>> 
>> That's the marketing blurb, I've heard it a thousand times before. [...]
>> So, for the last 10-12 years, maybe more, mountains of software have been produced on the assumption that it will be easy to find and install all their dependencies. That's only true for users of big 'distributions' which have lots of people, a large professional team or many contributors, to create and maintain the package tree.
> 
> From a different point of view, the problem is also that the developers,
> using some developing tools (for example the GNU automake and autoconf),
> don't really know what they are using, or, since "GNU is not Unix",
> don't verify that their code is POSIX compliant (and to what level etc.;
> when I began using Unix by discovering Linux, I remember reading a book
> explaining that for C programming, when linking, you will add always 
> the Glib library because "there are probably things you will need in
> it!"...).
> 
> The amount of dependencies of some packages is simply appaling. (One
> example is TeXlive, because using some macros involve using an amount
> not necessarily kwown of "other" macros, for a lot of people it is
> simpler to "take it all" just in order not to "fail"; and this is
> when you need only a part of it that you discover that this "all"
> depends on things that you do not have on your system---a C++
> compiler and so on).
> 
> -- 
>        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
>                     http://www.kergis.com/
>                       http://www.sbfa.fr/
> Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C
> 

Re: [9fans] There is no fork

[Giacomo Tesio]

2018-02-12 17:13 GMT+01:00  <tlaronde@polynum.com>:
> 2018-02-12 14:05 GMT+01:00 Ethan Grammatikidis <eekee57@fastmail.fm>:
>> That's the marketing blurb, I've heard it a thousand times before. [...]
>> So, for the last 10-12 years, maybe more, mountains of software have been produced on the assumption that it will be easy to find and install all their dependencies. That's only true for users of big 'distributions' which have lots of people, a large professional team or many contributors, to create and maintain the package tree.
>
> From a different point of view, the problem is also that the developers,
> using some developing tools (for example the GNU automake and autoconf),
> don't really know what they are using, or, since "GNU is not Unix",
> don't verify that their code is POSIX compliant (and to what level etc.;
> when I began using Unix by discovering Linux, I remember reading a book
> explaining that for C programming, when linking, you will add always
> the Glib library because "there are probably things you will need in
> it!"...).

I might be proven wrong, but I doubt that developers not understanding
their tools can build useful software.

Or, if the software they build is useful, it may get enough traction
to be rewritten after learning from mistakes.

I cannot fix people linking glib just because it exists. Just like I
cannot fix people writing a new JS framework/library/wtf. In general I
cannot fix people.
But, whenever I have to hack on something that depends on cmake,
instead of autotools, I know it will take twice as much to get the
task done.

>
> The amount of dependencies of some packages is simply appaling. (One
> example is TeXlive, because using some macros involve using an amount
> not necessarily kwown of "other" macros, for a lot of people it is
> simpler to "take it all" just in order not to "fail"; and this is
> when you need only a part of it that you discover that this "all"
> depends on things that you do not have on your system---a C++
> compiler and so on).

My bet is that, when Jehanne will be the one true OS everybody will
hate, people will not install macro packages, but mount a remote file
server through a  caching file server, including the C++ compiler.
Now before going crazy about security, consider that the shell running
TeXlive will only see a limited namespace, containing only the file it
has to work with and nothing else.

But this is not going to happen soon... People do not hate Javascript
enough, yet... :-D


Giacomo

Re: [9fans] There is no fork

[Benjamin Huntsman]

[-- Attachment #1: Type: text/plain, Size: 510 bytes --]

This has been a fascinating thread.

I was kind of surprised that no one came out and said "yes, 9front all the way", nor did anyone say they had 9atom working.
Ideally, I'd like to have 9atom on VMware, but since it isn't maintained anymore either, 9front looks like the way to go.  9legacy might be truer to the original, but it doesn't work on VMware out of the box.  I know VMware isn't the favorite virtualization platform of everyone on here, but there's a lot of production on VMware...







[-- Attachment #2: Type: text/html, Size: 1035 bytes --]

Re: [9fans] There is no fork

[Ethan Grammatikidis]

On Mon, Feb 12, 2018, at 3:21 PM, Giacomo Tesio wrote:
> 2018-02-12 14:05 GMT+01:00 Ethan Grammatikidis <eekee57@fastmail.fm>:
> > On Mon, Feb 12, 2018, at 8:33 AM, Giacomo Tesio wrote:
> >> 2018-02-12 2:10 GMT+01:00 Ethan Grammatikidis <eekee57@fastmail.fm>:
> >>> linux-style package managers and bsd-style port trees facilitate and enable coupling.
> >>
> >> What a package manager really facilitate is version management.
> >> That is when you want to use/update a software at version X that depends on libraries at version Y and Z.
> >
> > That's the marketing blurb, I've heard it a thousand times before. [...]
> > So, for the last 10-12 years, maybe more, mountains of software have been produced on the assumption that it will be easy to find and install all their dependencies. That's only true for users of big 'distributions' which have lots of people, a large professional team or many contributors, to create and maintain the package tree.
>
> True, but part of cost here is the complexity of the package manager.
>
> >
> >> The use of dynamic linking make this complex and cumbersome. Also a single filesystem hierarchy does not help
> >
> > Dynamic linking is probably the largest, most visible part of the problem, but your saying this makes me think you haven't tried to compile very much software -- certainly not on anything other than Debian or a similarly large distro where, these days, you can get all the dependencies by pasting a line the package author provided.
>
> Well, I use Debian from Potato, but I've got my headaches with
> pinning, backports, conflicts and broken upgrades.
>
> Also, I think I've compiled my amount of software.
> As a rather recent example, automating the compilation of the gcc
> cross-compiler for Jehanne took its time since I had to compile and
> install locally specific versions of autotools and binutils, without
> forcing users to install texinfo.

Well done! I've only built gcc as a cross compiler once in my life, and I think that might have been gcc 2.95. I think the reason I get so grumpy about all this is because it's harder for me. I could say I never developed the mental toolset needed, but sometimes I have managed to do these things "without killing myself", so it's doubly frustrating when I fail.

On the other hand, you are talking about a c compiler, which isn't going to have a lot of uncommon dependencies. Graphical programs can be much worse, and so can some background servers for less-standard features. I had trouble with a filesystem search indexer.

>
> I think I have an idea of what I'm doing, but I'm pretty open to
> suggestions and criticisms: the best time for them is now, since I did
> no real work on the matter.

Indeed, I'm sorry I didn't offer any in my last mail. I'd forgotten about the operating system I planned last summer. I've found it now, all my notes on a computer I rarely use. I put all the thought I could into it, but of course it's not perfect. It would particularly need a lot of directories to be searched on executing programs. (I guess it would need a cache for that.)

My plan was to have each package in its own directory. Some of the subdirectories were mandated: doc; cfg (user's config, empty on installation); cfg.def (defaults); inc (include); src; and arch-dependent dirs with 'all' for scripts. the arch-dependent dirs would have subdirs: exe; lib; inc; src; test. (Like you, I wanted to change 'bin'. It's ridiculous!)

Looking at it now, I see it allows tight dependencies between packages, so I guess it doesn't solve much. I think a big part of the plan I didn't write down was to have large packages: include the dependencies in the package. WIndows programs have done this for decades, it's what ended "dll hell". It's certainly something I intend for pretty-much anything large I might develop in the future. If there's one point I'll really stand by, it's this one.

There are some odd other things in my notes, not really on topic but relevant to operating systems and software choices. "Find the right layer for the task." Okay. Then there's my wish for a single scripting language, in contrast to Plan 9's maze of little languages, none quite alike. :) "The ministry of silly walks is a bad idea," which turned out to be about unions, not
using them as a standard feature or implementing them in the kernel, because walk() is a bottleneck and can of course hit deadlocked fileservers. Even not rejecting seemingly featureful programs too quickly; there's this xgrep program which implements \{n,n\} and character classes in under 2000 lines of assembly language. Structured pipes? Sure, if you want to change the whole concept of a terminal. :)

>
> > The painful ones particularly included dependencies for otherwise nice programs. I'd get 2 or 3 levels down the dependency tree, and suddenly, chaos!
> > [...]
> > Thinking about this stuff makes me bitter, so I ought to stop now. It's possible the things you want won't intersect with the things which caused me trouble, but I think I have considerable reason for pessimism.
>
> Well, obviously I'm naive enough to try to do something better! :-D

And that's not a bad thing! :)

>
> I think the problem is really tied to the nature of software
> development... just because bugs are.

Largely, yes. It can only be partially mitigated. I do think the best idea is for package authors to include dependencies in the package, not expecting users or distributors to do that work. Some will rant and holler about insecurity, and maybe they're right, but I want the freedom to try interesting software without the slave labour of looking after those difficult packages in the dependency tree.

>
> To my money you have an alternative:
> - to be mostly self contained (as Plan 9/9front does), which is the
> optimal solution to the problem
> - to leverage outside softwares which evolve outside your control

I like this, but it does rather require a team.

>
> Both solution have to cope with bugs:
> - in Plan 9/9front you fix them
> - in other systems you can still fix them but if you contribute back
> the fix things turn "complex"...

Yup. My thought about "fixing things in the right layer" is relevant here. If you have a self-contained system, you can do that. If it's split up, it requires cooperation.

>
> Versioning, dependency trees (or sometime even graphs) and all these
> monsters comes from this problem.
>
> The self-contained approach is way more efficient... and simpler. Thus
> it's very attractive to me.
>
> But, my insight is that these monsters need to be faced, and defeated. :-)
> Since you can't stop (or control) the evolution of software you do not
> code yourself, there's no way to avoid versioning and using that
> software.

There is: use the big commercial OSs for most stuff, and keep the software you want to develop private. Rather restricting, I know. :)

>
> But again my insight is that using static linking and namespaces,
> packages can be way easier to maintain.

I haven't considered namespaces in package management for a long time. I'm not convinced about the static linking part at all. It certainly makes binary package management simpler, but the problems I complain about occurred during compilation, or sometimes configuring.

>
>
> Still, I'd really like to know details about your concerns and your
> painful experiences, since they could put me on the right track.

They're too far in the past to remember them all. Mostly they took this form: X requires Y and Z. Z's all right, but Y requires foo bar baz quux *and* syzygy, and then I'd find 3 of those had their own compilation problems. Slave labour required! The other thing was of course autohell, but that got a lot less likely some time during the last decade. It's still possible though.

>
>
>
> > I'd like to think there are enough people who don't want to be tied up in all this pain to create some semblance of a software ecosystem outside it, but when you consider that few people want to start from the ground up, and how poettering and fd.o have their tentacles in crucial parts of the posix-related ecosystem, it looks impossible.
>
> Well, actually there are several hobby OSes that do not support posix
> and package management.
> (and some have interesting ideas too...)

I've always had a problem of not looking around enough. I use FreeDOS. It has a package manager, but I use unzip and deltree instead (or rm -r, i forget which.)

>
> But the problem with your approach is not just posix compliance.
>
>
> For example, in Jehanne most tools you are used in Plan 9 are not part
> of the core system.

I have to say, as much as I like Plan 9 C and hate gcc, I understand you taking the C compilers out and replacing them with gcc. My big plan at the moment is to ditch C for a language which only requires an extremely small interpreter, and yet can be compiled too. I'm having a little bit of trouble following the indirection in a double-indirect threaded interpreter, but this is something I'm confident I can achieve. That language is Forth, but I'm starting to wonder if the same could be achieved with other languages.

>
> For example, porting Plan 9/9front games to Jehanne is trivial (could
> even be automated), but their changes should not cause the core system
> to "evolve".
>
> So the solution, again, is installing them as packages, with their own
> versions. And this is the reason why there are no games in Jehanne:
> they are waiting for a package manager.
>
>
> The problem, as always, is to get the axes right.

Oh that's similar to "put the fix in the right layer." Yup.

>
>
> An OS core system should evolve as a whole.
> But since its usefulness depend on the amount of things people can do
> with it, it should also be able to run exogenous software.

Your OS should, perhaps. :) My minimum requirements for an OS I'll consider useful are much lower, provided I have an alternative system for web browsing and maybe games. For 2 or 3 years I used 9front full time, primarily acme, telnet, and page. I was happy most of the time. Sometimes I'd play Minecraft or something like Second Life, but despite a certain amount of addiction to 3D graphics, I got almost as much out of my Plan 9 use.

>
>
> The Plan9/9front approach is optimal because it's perfectly useful
> exactly to the people it want to be useful to.
>
>
> Jehanne is useless. It's just a toy, aka a research operating system. :-)
> But in it's research scope is how to enable software development to
> scale more easily than in mainstream alternatives.
>
>
> My insight is that, as a simpler system, Jehanne will be more powerful.
> And the additional simplicity/power will make such complex problems
> almost disappear.

Additional power can come with simplification, as everyone on this list knows. I hope it works out for you! :)

>
>
> Giacomo
>


--
The lyf so short, the craft so long to lerne. -- Chaucer

Re: [9fans] There is no fork

[Erik Quanstrom]

[-- Attachment #1: Type: text/html, Size: 5692 bytes --]

Re: [9fans] There is no fork

[sl]

> On 2/10/18, Benjamin Huntsman <BHuntsman@mail2.cu-portland.edu> wrote:
>> Just curious as to the state of the union.  Is 9front pretty much the de
>> facto "official" Plan 9 these days, or does anyone still use or maintain any
>> of the following:
>
> I'm with David (legacy), nearly all the way.
>
> That said, I deem it unfortunate that there isn't a drive to
> consolidate the various flavours of Plan 9 into a single offering, or
> at least identify and discuss the differences and provide for the
> choices from a single source (pun intended).

Have you considered providing this service?

sl

Re: [9fans] There is no fork

[Lucio De Re]

On 2/13/18, sl@9front.org <sl@9front.org> wrote:
>>
>> That said, I deem it unfortunate that there isn't a drive to
>> consolidate the various flavours of Plan 9 into a single offering, or
>> at least identify and discuss the differences and provide for the
>> choices from a single source (pun intended).
>
> Have you considered providing this service?
>
> sl
>
Touche'. I'd certainly like to contribute, but herding the Plan 9 cats
is beyond any managerial skills I may have.

Actually, I think one needs to resist the temptation to write any code
until the underlying design, specially of the perimeter API/ABI has
been discussed to death. I know I find that extremely hard to do at
all times.

My own nature is one of cooperative development, but it is not the
current fashion and perhaps it suppresses the essential creative
spirit. Thankfully, I seem to have reached an  age when I no longer
believe it is up to me to make things happen: there are so many eager,
younger minds with so much more to offer.

Lucio.

Re: [9fans] There is no fork

[Rui Carmo]

> On 13 Feb 2018, at 03:06, Lucio De Re <lucio.dere@gmail.com> wrote:
> Touche'. I'd certainly like to contribute, but herding the Plan 9 cats
> is beyond any managerial skills I may have.

I think management wouldn’t be the issue. From the outside looking in, what transpires the most is that there is very little information for anyone wanting to help/contribute or even install and manage 9front if you have never been exposed to Plan9.

I get the current website and some of the in-jokes, but a step-by-step guide for installing, building and contributing would be great (I’ve been thinking of setting up a build system, but I would have to run that on Linux VMs or QEMU - the complexity doesn’t scare me, but the need to head-butt against every single detail because of the lack of documentation puts me off).

R.

Re: [9fans] There is no fork

[Lucio De Re]

On 2/13/18, Rui Carmo <rui.carmo@gmail.com> wrote:
> I get the current website and some of the in-jokes, but a step-by-step guide
> for installing, building and contributing would be great ...

It's so easy to fall into the trap of elitism, while bemoaning the
shortage of development hands needed to bring Plan 9 (or any one of
its other flavours) into the "mainstream".

What keeps Plan 9 alive and this list/group thriving is the
conversation, irrespective of the actual pertinence to the "real
world". It is knowing that the world has rejected the Plan 9 "grace"
and are therefore not deserving, blah, blah. Human natures, humoured,
harmlessly. Why not? Plan 9 is elegant, 9front presumably has some
robust features, the other flavours can handle their own niche
objectives.

I've been absent here for a long spell and came back recently to
discover most of the old hands still at it and some new blood raising,
mutatis mutandis, the same issues we've seen go past since 1995 (for
me). It is as familiar as it is reassuring.

But the reality is that Plan 9 is too good in too many ways and the
world can only absorb chunks of that at the time (disruptive
technologies, I believe they were labelled, way back) and so it
progresses very little while the few remaining contenders to the prize
of OS of the century or millennium or whatever have the resources to
track the bad engineering decisions they (the OSes) facilitate or even
demand.

Merging Plan 9 flavours would resolve many otherwise intractable
problems, but it will do nothing to improve the penetration of Plan 9
in the marketplace and no one has the funds to tackle it, even if they
felt that the result would be worth it.

But there is something in not following the fashion; I, for one,
really cherish it. Mostly because it is all so simple, once you leave
the baroque world of Windows, Linux and OSX behind.

Lucio.

Re: [9fans] There is no fork

[hiro]

Rui, please present any issues you had with the step-by-step
introductions in the fqa to us on the 9front mailinglist in a
designated thread.

Re: [9fans] There is no fork

[hiro]

Lucio, what commit are you missing in 9front that you would like to see merged?

Re: [9fans] There is no fork

[hiro]

We found a great little niche for plan9 hidden between other web
browsers^W^Woperating systems.
Nowadays it's too easy to run multiple OS, virtually and natively.
Cpu virtualization features helped, and there's so much cheap but
totally capable hardware on ebay, and it fits in your backpack.
There has been no easier time to get into plan9.

Re: [9fans] There is no fork

[Lucio De Re]

On 2/13/18, hiro <23hiro@gmail.com> wrote:
> Lucio, what commit are you missing in 9front that you would like to see
> merged?
>

Wrong person, Hiro :-)

I am a strict 9legacy user, down to only a few patches past a very old
Plan 9 release, just enough modernity to run Go plus a few of my own
tiny tweaks (notably making the cursor disappear if the mouse stands
still long enough, nothing else comes to mind right now).

I like what 9front seems to be, but I have never used it and I'm a bit
of an old dog. What little ability I have left to learn new tricks
seems to be consumed in keeping Linux Mint running.

Sad, indeed!

Still, I think I understand your question correctly: "what would I
install on Plan 9 from the 9front distribution?"

Only two things stand out: the combined audio driver (ESS and
Soundblaster) and the kernel fixes I now cinap has implemented but I
have never had occasion to use.

On a more objective level, as I know 9front has diverged significantly
from 9legacy, but it's only an estimate on my part, the following may
be worth mentioning.

These things pop up occasionally, but they are minor nits and I ignore
them. I know that I have to reset my workstation rather than just
reboot it, whereas 9atom gets that right (minor irritant, there's a
button for that) but I think that's where I would push if I knew
someone really cares about it. VESA isn't a nice alternative to
dedicated graphic drivers, but that is hell as best described by
Hieronimus Bosch (and Russ Cox), no ways would I inflict that on
anyone, I don't wish to encourage that madness.

SSH seems to have lost track, I just no longer use it. Here, Go is
wonderful, in that it has all this new package code that implements
stuff Plan 9 would never acquire (SQL drivers, LDAP interfaces, TLS
and SSL, etc.)

But , as I suggested, I'm closer to a Luddite than to a Plan 9
evangelist. I have a sharp eye for inconsistencies, but it's of
minimal value in this context.

On a positive side, I do use Plan 9 as my development platform (acme +
Go, and a very busy namespace) and I have a few hosts I can run Plan 9
on. If that helps, feel free to let me know.

Lucio.

Re: [9fans] There is no fork

[hiro]

Does our fshalt -r work for rebooting without pressing reset?
SSH has been completely rewritten by cinap, it's working much better
than any former port, aiju also integrated sftp support.
After this cinap fixed vt. Together these changes allow certain linux
management tasks to be more comfortable than even on linux.
Same with TLS/SSL, it's all fully integrated and in some cases cinap
implemented stuff faster and with higher quality than openssl.
No idea about LDAP or SQL, nothing i play with needs this :)

Re: [9fans] There is no fork

[Lucio De Re]

I have a lot of admiration for cinap, he's "deep".

But he is also the best qualified person to estimate whether
improvements in 9front are portable back to legacy and I'm sure that
is, sadly, not high on his agenda.

Conservatively, I'd like legacy to be the entry system to Plan 9 and
categorise mutually incompatible enhancements (there are a few I know
about, but can't think of any off-hand) to be well documented so
"forks" remain as close to each other as possible.

Of course, there is implicitly no incompatibility where bug fixes
occur or new developments are introduced, in my "perfect world".

Your comments, hiro, are very helpful and reassuring. My focus at
present is to continue my Go developments (not contributions,  I have
some long-term work I would not undertake in any other language - Go
is hardly perfect, but it is wonderfully productive: I'm no longer
surprised when modules work first-time after a successful
compilation), but I'll be glad to contribute to any efforts to
categorise Plan 9 updates since the demise is Bell-Labs into
compatibility classes. Taxonomy, rather than archeology, I guess. I
think it would be worthwhile, even at a hobby level.

I'll tick off your questions as I get an opportunity to test them,
report back here, or personally, as seems appropriate.

Thank you for taking the trouble to encourage me along.

Lucio.

Re: [9fans] There is no fork

[Rui Carmo]

> On 13 Feb 2018, at 11:05, hiro <23hiro@gmail.com> wrote:
> 
> Rui, please present any issues you had with the step-by-step
> introductions in the fqa to us on the 9front mailinglist in a
> designated thread.

The main issue for me is putting together a build environment on top of KVM or Linux, which isn’t covered in the FQA.
 
I can’t build 9front on a Pi (well, not in productive amounts of time), and all the machines i have available with the requisite horsepower are in the public cloud (except for my iMac and a local KVM host that is already overburdened with my Windows development VM).

Since I’m a staunch supporter of CI/CD I’d love to automate the process from committing code to building a burnable image, and dipping into 9front from “outside” to run the requisite commands is going to be a time sink.

R.

Re: [9fans] There is no fork

[Lucio De Re]

9front is not something I'm familiar with, but Plan 9 legacy is
trivial to install (I still use VMware ESXi as the host) and you can
rebuild the entire system with a handful of commands once you've got
that far.

Naturally, you may prefer a different approach, but do you need that
to be your first step? It becomes easy once you have one Plan 9 host.
No insult meant, but it seems to me you have not tried the obvious and
easy route.

Lucio.

Re: [9fans] There is no fork

[Kurt H Maier]

On Tue, Feb 13, 2018 at 03:10:34PM +0000, Rui Carmo wrote:
> 
> The main issue for me is putting together a build environment on top of KVM or Linux, which isn’t covered in the FQA.
>  

What is a "build environment"?  The FQA contains an entire chapter
(3.3.1) on installing to qemu on linux.  If a complete installation is
not sufficeint to create a "build environment," can you help us
understand what is missing?

khm

Re: [9fans] There is no fork

[Rui Carmo]

> On 13 Feb 2018, at 16:25, Kurt H Maier <khm@sciops.net> wrote:
> 
> On Tue, Feb 13, 2018 at 03:10:34PM +0000, Rui Carmo wrote:
>> 
>> The main issue for me is putting together a build environment on top of KVM or Linux, which isn’t covered in the FQA.
>> 
> 
> What is a "build environment"?  The FQA contains an entire chapter
> (3.3.1) on installing to qemu on linux.  If a complete installation is
> not sufficeint to create a "build environment," can you help us
> understand what is missing?

A full build environment (the way I’m used to having it) comprises the end-to-end automation for creating a full build, triggered by an external code repository and (when possible) doing automated testing.

I understand that you might be used to manually bootstrap things, but I tend to go for fully reproducible builds and that usually requires a minimal degree of automation. I did that for my Inferno builds for the Pi (which, alas, are now lost) and do rely on Linux tools for building, because that’s what I can host in the public cloud (which is also what I do for work).

Fortunately, I have access to machines with nested virtualisation, so I might be able to get Plan9 running inside QEMU inside a modern Linux kernel with fair performance - but that does not preclude the need to automate things.

R.

Re: [9fans] There is no fork

[Kurt H Maier]

On Tue, Feb 13, 2018 at 05:01:35PM +0000, Rui Carmo wrote:
> 
> A full build environment (the way I’m used to having it) comprises the end-to-end automation for creating a full build,

A full build of what?  It's one command to rebuild the whole OS.  Is
that the goal?

> triggered by an external code repository 

This pretty significantly reduces the scope of the problem, since only a
couple of the forks use version control.  This simplifies the task
somewhat, at least.

> and (when possible) doing automated testing.

I think this is probably the most useful part of what you describe.  Do
you intend to write the tests?

> I understand that you might be used to manually bootstrap things, 

Please don't start making assumptions.  I'm just trying to clarify what
you're after.

>but I tend to go for fully reproducible builds and that usually requires a minimal degree of automation. I did that for my Inferno builds for the Pi (which, alas, are now lost) and do rely on Linux tools for building, because that’s what I can host in the public cloud (which is also what I do for work).

Plenty of us run Plan 9 on public cloud providers.  There's even been
some success on running it with crippled providers like AWS and GCE. 
Obviously, the task is easier when you use providers that offer full KVM
services.  We've had virtio drivers for a while, and it makes the job
much easier.

> Fortunately, I have access to machines with nested virtualisation, so I might be able to get Plan9 running inside QEMU inside a modern Linux kernel with fair performance - but that does not preclude the need to automate things.

I'm still trying to understand why you'd even need nested
virtualization.

khm

Re: [9fans] There is no fork

[Rui Carmo]

> On 13 Feb 2018, at 18:12, Kurt H Maier <khm@sciops.net> wrote:
> 
> On Tue, Feb 13, 2018 at 05:01:35PM +0000, Rui Carmo wrote:
>> 
>> A full build environment (the way I’m used to having it) comprises the end-to-end automation for creating a full build,
> 
> A full build of what?  It's one command to rebuild the whole OS.  Is
> that the goal?

Yes. And to deliver an image for the Pi, built on Intel systems.

>> triggered by an external code repository 
> 
> This pretty significantly reduces the scope of the problem, since only a
> couple of the forks use version control.  This simplifies the task
> somewhat, at least.

I struggle to understand how version control is not more actively used.

>> and (when possible) doing automated testing.
> 
> I think this is probably the most useful part of what you describe.  Do
> you intend to write the tests?

At least the basic ones regarding whether the result boots, yes.

>> I understand that you might be used to manually bootstrap things, 
> 
> Please don't start making assumptions.  I'm just trying to clarify what
> you're after.
> 
>> but I tend to go for fully reproducible builds and that usually requires a minimal degree of automation. I did that for my Inferno builds for the Pi (which, alas, are now lost) and do rely on Linux tools for building, because that’s what I can host in the public cloud (which is also what I do for work).
> 
> Plenty of us run Plan 9 on public cloud providers.  There's even been
> some success on running it with crippled providers like AWS and GCE. 
> Obviously, the task is easier when you use providers that offer full KVM
> services.  We've had virtio drivers for a while, and it makes the job
> much easier.

Well, for full disclosure, I work at Microsoft. I do have extensive AWS and GCE experience, and hardly find them “crippled”. It’s just that the world has moved on and prioritised certain kinds of hardware virtualisation.

>> Fortunately, I have access to machines with nested virtualisation, so I might be able to get Plan9 running inside QEMU inside a modern Linux kernel with fair performance - but that does not preclude the need to automate things.
> 
> I'm still trying to understand why you'd even need nested
> virtualization.

For using QEMU’s virtualization features inside Hyper-V.

R.

Re: [9fans] There is no fork

[Kurt H Maier]

On Tue, Feb 13, 2018 at 06:21:42PM +0000, Rui Carmo wrote:
> 
> Yes. And to deliver an image for the Pi, built on Intel systems.

Always good to specify the deliverables.

> I struggle to understand how version control is not more actively used.

It's not particularly necessary when you have global state with
snapshots provided by a shared WORM fs.  DVCS adds a lot of complexity
for questionable gain, in that environment.  9front's adoption of
mercurial is a historical accident rather than a desired outcome.  But,
I understand that most people just want to use the tools they already
know.  It's much easier than learning a new paradigm.

> At least the basic ones regarding whether the result boots, yes.

I look forward to seeing your results.

> Well, for full disclosure, I work at Microsoft. I do have extensive
> AWS and GCE experience, and hardly find them “crippled”. It’s just that
> the world has moved on and prioritised certain kinds of hardware 
> virtualisation.

We can disagree, but AWS's recent push away from xen and toward kvm
indicates to me that they also consider their product crippled. 
Perhaps the world is moving back.

I'm sure they had excellent reasons for it, but I've never found either
Amazon or Google to be particularly capable platforms.  Perhaps I'd feel
differently if I were a web developer.

> For using QEMU’s virtualization features inside Hyper-V.

If Hyper-V is still capable of running Xen guests, you may want to look
at the code on sources for a start in that direction.  That way you
could skip linux altogether and just use the platform natively.  

Good luck,

khm

Re: [9fans] There is no fork

[Rui Carmo]

[-- Attachment #1: Type: text/plain, Size: 1360 bytes --]



> On 13 Feb 2018, at 19:10, Kurt H Maier <khm@sciops.net <mailto:khm@sciops.net>> wrote:
> 
>> For using QEMU’s virtualization features inside Hyper-V.
> 
> If Hyper-V is still capable of running Xen guests, you may want to look
> at the code on sources for a start in that direction.  That way you
> could skip linux altogether and just use the platform natively.  

I would very much like to do that. Marshaling the time to get Plan9 running on Azure would be nice, but first I need to learn enough about the internals by building the system for a platform that is already supported and that I can experiment on easily (like the Pi 3).

Also, it would have to be 64-bit, which would be an added challenge. I’d rather start with ARM and cross-compile, which I’ve been doing for Android for a few years now (can’t be much different even with the relatively ancient^Wsimpler C compilers).

Baby steps. And for me, one of those steps is setting up a DVCS (probably Mercurial, because even if I’ve left it for git seven or so years ago I’d like to give the opportunity for others to contribute, and git seems to be frowned upon here), having good tracking (and backtracking) of my experiments, and a reproducible build system that has no human intervention (so that I don’t introduce any mistakes).

Oh, and finding the time.

R.

[-- Attachment #2: Type: text/html, Size: 4579 bytes --]

Re: [9fans] There is no fork

[Steve Simon]

[-- Attachment #1: Type: text/plain, Size: 1646 bytes --]


re git frowned upon.

i think git is frowned upon because porting it would be a massive effort due to its many dependencies, whist python has been ported and mercurial just works.

-Steve




> On 13 Feb 2018, at 23:37, Rui Carmo <rui.carmo@gmail.com> wrote:
> 
> 
> 
>>> On 13 Feb 2018, at 19:10, Kurt H Maier <khm@sciops.net> wrote:
>>> 
>>> For using QEMU’s virtualization features inside Hyper-V.
>> 
>> If Hyper-V is still capable of running Xen guests, you may want to look
>> at the code on sources for a start in that direction.  That way you
>> could skip linux altogether and just use the platform natively.  
> 
> I would very much like to do that. Marshaling the time to get Plan9 running on Azure would be nice, but first I need to learn enough about the internals by building the system for a platform that is already supported and that I can experiment on easily (like the Pi 3).
> 
> Also, it would have to be 64-bit, which would be an added challenge. I’d rather start with ARM and cross-compile, which I’ve been doing for Android for a few years now (can’t be much different even with the relatively ancient^Wsimpler C compilers).
> 
> Baby steps. And for me, one of those steps is setting up a DVCS (probably Mercurial, because even if I’ve left it for git seven or so years ago I’d like to give the opportunity for others to contribute, and git seems to be frowned upon here), having good tracking (and backtracking) of my experiments, and a reproducible build system that has no human intervention (so that I don’t introduce any mistakes).
> 
> Oh, and finding the time.
> 
> R.

[-- Attachment #2: Type: text/html, Size: 5063 bytes --]

Re: [9fans] There is no fork

[Lucio De Re]

On 2/14/18, Steve Simon <steve@quintile.net> wrote:
>
> re git frowned upon.
>
> i think git is frowned upon because porting it would be a massive effort due
> to its many dependencies, whist python has been ported and mercurial just
> works.
>
It's a shame, cause GIT itself is mostly C, no doubt pretty portable.
Shame about Perl and bash, I suppose.

Lucio.

Re: [9fans] There is no fork

[hiro]

git has a bad user interface, it is not made for casual users.

Re: [9fans] There is no fork

[Ethan Grammatikidis]

On Wed, Feb 14, 2018, at 11:32 AM, hiro wrote:
> git has a bad user interface, it is not made for casual users.
>

I've been using it casually for a couple of weeks, it's been bearable. Perhaps that's because one of the repos only has occasional commits from one other person, and the other is just me pushing one way. My biggest mistake was buying into the whole pull request junk for common tasks.

Sometimes I do think a shared worm would be better, particularly when I've forgotten to commit. :) I'm a bit torn over commit messages. On the one hand, they're annotation. On the other, spam. I could do more annotation in the notes file I always keep in a project.

--
The lyf so short, the craft so long to lerne. -- Chaucer

Re: [9fans] There is no fork

[hiro]

> It’s just that the world has moved on

this has no relevance, our kvm based setups still work, regardless of
microsoft's virtualized revolutions.

Re: [9fans] There is no fork

[Steve Simon]

> I can’t build 9front on a Pi (well, not in productive amounts of time)

depends what you mean by productive. my pi3 will build a kernel in about 30 secs (i am not by it so this is from memory).

my dual 1.6 atom at home takes about 14 secs for comparison.

userspace would take much longer but i never do this. odd commands on occasion but i have never built the whole thing.

-Steve

Re: [9fans] There is no fork

[Bakul Shah]

On Tue, 13 Feb 2018 18:16:02 +0000 Steve Simon <steve@quintile.net> wrote:
Steve Simon writes:
> 
> 
> > I can't build 9front on a Pi (well, not in productive amounts of time)
> 
> depends what you mean by productive. my pi3 will build a kernel in about 30
> secs (i am not by it so this is from memory).
> 
> my dual 1.6 atom at home takes about 14 secs for comparison.
> 
> userspace would take much longer but i never do this. odd commands on occasion
> but i have never built the whole thing.

On the original Pi it took a minute for the kernel, 4 minutes
for the userland, half of which was for ghostscript.

Re: [9fans] There is no fork

[sl]

> On 2/13/18, Rui Carmo <rui.carmo@gmail.com> wrote:
> > I get the current website and some of the in-jokes, but a step-by-step guide
> > for installing, building and contributing would be great ...
>
> It's so easy to fall into the trap of elitism, while bemoaning the
> shortage of development hands needed to bring Plan 9 (or any one of
> its other flavours) into the "mainstream".
>
> What keeps Plan 9 alive and this list/group thriving is the
> conversation, irrespective of the actual pertinence to the "real
> world". It is knowing that the world has rejected the Plan 9 "grace"
> and are therefore not deserving, blah, blah. Human natures, humoured,
> harmlessly. Why not? Plan 9 is elegant, 9front presumably has some
> robust features, the other flavours can handle their own niche
> objectives.
>
> I've been absent here for a long spell and came back recently to
> discover most of the old hands still at it and some new blood raising,
> mutatis mutandis, the same issues we've seen go past since 1995 (for
> me). It is as familiar as it is reassuring.
>
> But the reality is that Plan 9 is too good in too many ways and the
> world can only absorb chunks of that at the time (disruptive
> technologies, I believe they were labelled, way back) and so it
> progresses very little while the few remaining contenders to the prize
> of OS of the century or millennium or whatever have the resources to
> track the bad engineering decisions they (the OSes) facilitate or even
> demand.
>
> Merging Plan 9 flavours would resolve many otherwise intractable
> problems, but it will do nothing to improve the penetration of Plan 9
> in the marketplace and no one has the funds to tackle it, even if they
> felt that the result would be worth it.
>
> But there is something in not following the fashion; I, for one,
> really cherish it. Mostly because it is all so simple, once you leave
> the baroque world of Windows, Linux and OSX behind.
>
> Lucio.

I think he was looking for

	http://fqa.9front.org/fqa4.html

and

	http://fqa.9front.org/fqa5.html

sl

Re: [9fans] There is no fork

[sl]

>> Rui, please present any issues you had with the step-by-step
>> introductions in the fqa to us on the 9front mailinglist in a
>> designated thread.
> 
> The main issue for me is putting together a build environment on top
> of KVM or Linux, which isn’t covered in the FQA.
> 
> I can’t build 9front on a Pi (well, not in productive amounts of
> time), and all the machines i have available with the requisite
> horsepower are in the public cloud (except for my iMac and a local KVM
> host that is already overburdened with my Windows development VM).
> 
> Since I’m a staunch supporter of CI/CD I’d love to automate the
> process from committing code to building a burnable image, and dipping
> into 9front from “outside” to run the requisite commands is going to
> be a time sink.

It sounds like you are saying you want to 1.) build Plan 9 on Linux,
using Linux tools, 2.) and test it by running the result in
QEMU/KVM/whatever hosted by Linux.

1.) is the wrong approach.  Just build inside Plan 9.

2.) is trivial and is covered in FQA3[0] and FQA5[1].  9front's fork
of drawterm[2] can run without graphics, and can be used to execute
single commands.

If this is really your aim, I think you can accomplish it with minimal
stress.

sl

[0] http://fqa.9front.org/fqa3.html

[1] http://fqa.9front.org/fqa5.html

[2] http://drawterm.9front.org

Re: [9fans] There is no fork

[Rui Carmo]

> On 14 Feb 2018, at 00:31, sl@9front.org wrote:
>
> 1.) is the wrong approach.  Just build inside Plan 9.

You missed the rest of the thread.

R.

Re: [9fans] There is no fork

[sl]

On Feb 14, 2018, at 2:18 AM, Rui Carmo <rui.carmo@gmail.com> wrote:

> On 14 Feb 2018, at 00:31, sl@9front.org wrote:
> 
>> 1.) is the wrong approach.  Just build inside Plan 9.
> 
> You missed the rest of the thread.

I read the entire thread but I didn’t see this point specifically
addressed.  From the latest posts it is still unclear where you plan
to do the compiling.

Okay, so let’s stipulate compiling on Plan 9.  Unless I missed it, the
relationship between your automated tools on the Linux host and the
build on the Plan 9 guest (for example, how they will communicate)
hasn’t been mentioned at all.  That’s why I brought up the 9front fork
of drawterm as a possible facilitator.  It can handle 9front’s new
auth scheme and it can run individual commands.  Lacking something
like this, how else do you plan to control the build on Plan 9?

It also wasn’t clear to me that you’ve spent any significant time
actually using Plan 9.  It might even be a good idea to use the system
for a while, even without all the external automation, to figure out
if any of this is even worth your time.  A lot of people find they
don’t like Plan 9 once they get here.

Anyway, good luck with whatever your ultimate goal is.

sl