Re: [9fans] fork of a fork of Inferno that runs on Mac OS amd64

[David Leimbach via 9fans]

No problem!

It seems acme does work ok, but it uses XQuartz.

It’s been so long since I’ve used inferno I’ve forgotten how to get started!

Dave


> On Jul 30, 2021, at 12:39 PM, Joseph Stewart  wrote:
> 
> Good job friend. Thanks for doing this.
> 
> On Fri, Jul 30, 2021 at 9:26 AM leimy2k via 9fans <9fans@9fans.net> wrote:
>> 
>> https://github.com/Leimy/9ferno-leimy has the crawling phase of a port of 
>> Inferno that will run on modern Mac OS.
>> 
>> So far - no GUI as I wanted to just get it working to start, and I'm sharing 
>> it in case folks want to help out.
>> 
>> And I really mean that... I've done some things that I don't think are 
>> great, like renaming the panic function to avoid a name collision with some 
>> system headers.
>> 
>> I based the work from the OpenBSD amd64 emu port here: 
>> git://git.9front.org/plan9front/9ferno, and my intention is to get the 
>> changes cleaned up, get the GUI working (maybe port over the drawterm stuff 
>> from the 9front drawterm) etc.
>> 
>> If you try to use it now, just know that backspace/delete will exit the emu, 
>> and you'll want ctrl-h to backspace instead.
>> 
>> I did very minimal testing but ndb/dnsquery was working.
>> 
>> - Dave
>> 9fans / 9fans / see discussions + participants + delivery options Permalink

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T1bfae664a68c567a-Mf88f42997a024cb037df2c88
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] fork of a fork of Inferno that runs on Mac OS amd64

[Joseph Stewart]

Good job friend. Thanks for doing this.

On Fri, Jul 30, 2021 at 9:26 AM leimy2k via 9fans <9fans@9fans.net> wrote:
>
> https://github.com/Leimy/9ferno-leimy has the crawling phase of a port of 
> Inferno that will run on modern Mac OS.
>
> So far - no GUI as I wanted to just get it working to start, and I'm sharing 
> it in case folks want to help out.
>
> And I really mean that... I've done some things that I don't think are great, 
> like renaming the panic function to avoid a name collision with some system 
> headers.
>
> I based the work from the OpenBSD amd64 emu port here: 
> git://git.9front.org/plan9front/9ferno, and my intention is to get the 
> changes cleaned up, get the GUI working (maybe port over the drawterm stuff 
> from the 9front drawterm) etc.
>
> If you try to use it now, just know that backspace/delete will exit the emu, 
> and you'll want ctrl-h to backspace instead.
>
> I did very minimal testing but ndb/dnsquery was working.
>
> - Dave
> 9fans / 9fans / see discussions + participants + delivery options Permalink

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T1bfae664a68c567a-M3c4c67944126ef07708ce517
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] fork of a fork of Inferno that runs on Mac OS amd64

[leimy2k via 9fans]

https://github.com/Leimy/9ferno-leimy has the crawling phase of a port of 
Inferno that will run on modern Mac OS.

So far - no GUI as I wanted to just get it working to start, and I'm sharing it 
in case folks want to help out.

And I really mean that... I've done some things that I don't think are great, 
like renaming the panic function to avoid a name collision with some system 
headers.

I based the work from the OpenBSD amd64 emu port here: 
git://git.9front.org/plan9front/9ferno, and my intention is to get the changes 
cleaned up, get the GUI working (maybe port over the drawterm stuff from the 
9front drawterm) etc.

If you try to use it now, just know that backspace/delete will exit the emu, 
and you'll want ctrl-h to backspace instead.

I did very minimal testing but ndb/dnsquery was working.

- Dave
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T1bfae664a68c567a-M8a093f85ade55d681f97874a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] There is no fork

[sl]

On Feb 14, 2018, at 2:18 AM, Rui Carmo  wrote:

> On 14 Feb 2018, at 00:31, s...@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

Re: [9fans] There is no fork

[Erik Quanstrom]

I am still using and maintaining 9atom.  I just have a busy schedule so read the list less.- erikOn Feb 11, 2018 14:48, Benjamin Huntsman <bhunts...@mail2.cu-portland.edu> wrote:

> 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
>
>

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

[Ethan Grammatikidis]

On Mon, Feb 12, 2018, at 3:21 PM, Giacomo Tesio wrote:
> 2018-02-12 14:05 GMT+01:00 Ethan Grammatikidis :
> > On Mon, Feb 12, 2018, at 8:33 AM, Giacomo Tesio wrote:
> >> 2018-02-12 2:10 GMT+01:00 Ethan Grammatikidis :
> >>> 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 

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

[Lucio De Re]

On 2/14/18, Steve Simon  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

[Steve Simon]

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  wrote:
> 
> 
> 
>>> On 13 Feb 2018, at 19:10, Kurt H Maier  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.

Re: [9fans] There is no fork

[Rui Carmo]

> On 14 Feb 2018, at 00:31, s...@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]

>> 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 13 Feb 2018, at 19:10, Kurt H Maier  > 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.

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

[Kurt H Maier]

On Tue, Feb 13, 2018 at 06:21:42PM +, 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

[Bakul Shah]

On Tue, 13 Feb 2018 18:16:02 + Steve Simon  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

[Rui Carmo]

> On 13 Feb 2018, at 18:12, Kurt H Maier  wrote:
> 
> On Tue, Feb 13, 2018 at 05:01:35PM +, 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

[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

[Kurt H Maier]

On Tue, Feb 13, 2018 at 05:01:35PM +, 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 16:25, Kurt H Maier  wrote:
> 
> On Tue, Feb 13, 2018 at 03:10:34PM +, 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 03:10:34PM +, 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

[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

[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

[Rui Carmo]

> On 13 Feb 2018, at 11:05, hiro <23h...@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

[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

[sl]

> On 2/13/18, Rui Carmo  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

[Ethan Grammatikidis]

On Mon, Feb 12, 2018, at 1:39 PM, Lucio De Re wrote:
> On 2/12/18, Ethan Grammatikidis  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

[Lucio De Re]

On 2/13/18, hiro <23h...@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]

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

[hiro]

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

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

[Lucio De Re]

On 2/13/18, Rui Carmo  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

[Rui Carmo]

> On 13 Feb 2018, at 03:06, Lucio De Re  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, s...@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

[sl]

> On 2/10/18, Benjamin Huntsman  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

[Benjamin Huntsman]

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...

Re: [9fans] There is no fork

[Giacomo Tesio]

2018-02-12 17:13 GMT+01:00  :
> 2018-02-12 14:05 GMT+01:00 Ethan Grammatikidis :
>> 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

[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, tlaro...@polynum.com wrote:
> 
> 2018-02-12 14:05 GMT+01:00 Ethan Grammatikidis :
 On Mon, Feb 12, 2018, at 8:33 AM, Giacomo Tesio wrote:
 2018-02-12 2:10 GMT+01:00 Ethan Grammatikidis :
 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 
> 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

[tlaronde]

2018-02-12 14:05 GMT+01:00 Ethan Grammatikidis :
> > On Mon, Feb 12, 2018, at 8:33 AM, Giacomo Tesio wrote:
>> 2018-02-12 2:10 GMT+01:00 Ethan Grammatikidis :
>>> 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 
 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

[Chris McGee]

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

Chris

Re: [9fans] There is no fork

[Giacomo Tesio]

2018-02-12 14:05 GMT+01:00 Ethan Grammatikidis :
> On Mon, Feb 12, 2018, at 8:33 AM, Giacomo Tesio wrote:
>> 2018-02-12 2:10 GMT+01:00 Ethan Grammatikidis :
>>> 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 

Re: [9fans] There is no fork

[Lucio De Re]

On 2/12/18, Ethan Grammatikidis  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 8:33 AM, Giacomo Tesio wrote:
> 2018-02-12 2:10 GMT+01:00 Ethan Grammatikidis :
>> 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

[Giacomo Tesio]

2018-02-12 2:10 GMT+01:00 Ethan Grammatikidis :

> 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

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

[Benjamin Huntsman]

> 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-boun...@9fans.net <9fans-boun...@9fans.net> on behalf of Giacomo 
Tesio <giac...@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 <bhunts...@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

Re: [9fans] There is no fork

[Giacomo Tesio]

2018-02-12 0:48 GMT+01:00 Benjamin Huntsman :
> 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]

> 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-boun...@9fans.net <9fans-boun...@9fans.net> on behalf of Giacomo 
Tesio <giac...@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 <bhunts...@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

[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  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 :
>> 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

[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 :
> 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

[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]

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  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?
>
>

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]

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]

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]

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]

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" <
bhunts...@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

[Lucio De Re]

On 2/10/18, Benjamin Huntsman  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 , it is now
. Both are still in existence (in case you wish
to make adjustments to your mailer configuration).

[9fans] There is no fork

[Benjamin Huntsman]

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