Re: [9fans] SCMs

[Lucio De Re]

On 2/14/18, Dave MacFarlane  wrote:
>
> https://www.github.com/driusan/dgit/
>
> It's written in Go, which means it'll only work on platforms that Go
> supports (I think there's a list somewhere on the Go wiki, but it's some
> subset of 386/arm/amd64 depending on which fork you're using.)
>
Let's not forget  Cherry's plan9/mips64 port of Go. I seldom test it,
regrettably, but I've yet to be disappointed. I own a Lemote Yeeloong
and I'd use it more if I had a clue on how to get a disk driver
working on it. But it's OK net-wired to a file/cpu server.

Cherry's amazing development skills unfortunately seem totally consumed by Go.

Lucio.

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  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 
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 :
> 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] ReMarkable!

[Ethan Grammatikidis]

On Tue, Feb 13, 2018, at 2:58 PM, Daniel Camolês wrote:
> 
> I understand the sunken cost fallacy, but seriously, there's a reason 
> handwriting on tablets is not that much used despite the existence of 
> softwares for such. It can be useful when it comes to short annotations, but 
> it's really ridiculous for long texts. If it could be useful for tasks such 
> as writing a book and programming, we mostly likely would be doing it by now. 
> 
> Maybe it's not impossible that someone would come up with a way to input text 
> using a pen over a screen that's even more efficient and convenient than a 
> keyboard. So far, such technology just doesn't exist.
> 

Did you read the part in the article where they say writing on the ReMarkable's 
screen feels like writing on paper? Part of the problem with handwriting on 
screens was the slipperiness of the screen. This is a step forward here.

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

[Dave MacFarlane]

On Feb 14, 2018 02:22, "Rui Carmo"  wrote:



> On 14 Feb 2018, at 01:47, Bakul Shah  wrote:
>
> Dave MacFarlane's git client (dgit) does a decent job on plan9.

This interests me greatly. Last time I checked there wasn’t a good enough
got client, so I used Mercurial. Where is dgit exactly?

R.


https://www.github.com/driusan/dgit/

It's written in Go, which means it'll only work on platforms that Go
supports (I think there's a list somewhere on the Go wiki, but it's some
subset of 386/arm/amd64 depending on which fork you're using.)

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

[Steve Simon]

fyi

i spoke too soon, the labs website went a while ago, but the sources machine 
has returned, well i was able to access it last week.

last chance (i suspect) for those wanting to download the contrib dirs before 
they disappear - i got mine 

-Steve
 

On 13 Feb 2018, at 23:13, Lyndon Nerenberg  wrote:

>>> 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.
> 
> I always thought that argument was a bit suspect.  And with the loss of 
> sources.bell-labs.com, it's apparent why.  The only revision history was in 
> the venti.  Now that that is lost, so is that history.  I know that there are 
> partial mirrors of sources, but none go all the way back to the dawn of the 
> sources venti archive.  And on the mirrors, we lose the 'blame' functionality 
> fossil provided by tracking who last updated a file.
> 
> If this had been hosted in an SCM, it would have been so simple to replicate 
> that full history elsewhere.
> 
> The other bit that snapshots/dumps miss is context.  When everyone working on 
> the code was within shouting distance of the "unix room" that wasn't an 
> issue.  But now, that context has been lost.  Annotations about the "why" of 
> a commit are as important as the "what."  diffy(1) answers the "what," but 
> not the "why."
> 
>> 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.
> 
> +100 on DVCS and needless complexity.  cvs or sccs provides all the 
> functionality I've ever needed in an SCM system.  Although I confess I have 
> been seduced by git's ability to instantly create and switch between 
> branches.  It makes trying out "what if" scenarios completely painless. But 
> it's not enough to convince me to use git except on very rare occasions.
> 
> --lyndon
>