-Steve

On 13 Feb 2018, at 23= :37, Rui Carmo <rui.carmo@gmail.co= m> wrote:

On 13 Feb 2018, at 19:10, Kurt H Maier <khm@sciops.net> wrote:

For using QEMU=E2=80=99s virtualizat= ion features inside Hyper-V.

If Hype= r-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 wou= ld very much like to do that. Marshaling the time to get Plan9 running on Az= ure would be nice, but first I need to learn enough about the internals by b= uilding the system for a platform that is already supported and that I can e= xperiment on easily (like the Pi 3).

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

Baby steps. And for me, one of t= hose steps is setting up a DVCS (probably Mercurial, because even if I=E2=80= =99ve left it for git seven or so years ago I=E2=80=99d like to give the opp= ortunity for others to contribute, and git seems to be frowned upon here), h= aving good tracking (and backtracking) of my experiments, and a reproducible= build system that has no human intervention (so that I don=E2=80=99t introd= uce any mistakes).

Oh, and finding the time.

R.

= --Apple-Mail-D8D2D7D5-BD05-4C24-80CE-C98D201490BD-- From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References:

<20180213162522.GB15332@wopr> <20180213181242.GA26808@wopr> <20180213191034.GB26808@wopr> <4D3A8F48-C712-48AF-B5C2-151ACBEB3D94@gmail.com> From: Lucio De Re Date: Wed, 14 Feb 2018 13:10:41 +0200 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset="UTF-8" Subject: Re: [9fans] There is no fork Topicbox-Message-UUID: d10df9d6-ead9-11e9-9d60-3106f5b1d025 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. From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References:

<20180213162522.GB15332@wopr> <20180213181242.GA26808@wopr> <20180213191034.GB26808@wopr> <4D3A8F48-C712-48AF-B5C2-151ACBEB3D94@gmail.com> From: hiro <23hiro@gmail.com> Date: Wed, 14 Feb 2018 12:32:56 +0100 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset="UTF-8" Subject: Re: [9fans] There is no fork Topicbox-Message-UUID: d116ac34-ead9-11e9-9d60-3106f5b1d025 git has a bad user interface, it is not made for casual users. From mboxrd@z Thu Jan 1 00:00:00 1970 Message-Id: <1518614226.2839083.1270434856.67A2AB28@webmail.messagingengine.com> From: Ethan Grammatikidis To: 9fans@9fans.net MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" In-Reply-To: Date: Wed, 14 Feb 2018 13:17:06 +0000 References:

<1518397859.379213.1267373104.4DD6AB1E@webmail.messagingengine.com> <1518440723.631581.1267818416.51CB1908@webmail.messagingengine.com> Subject: Re: [9fans] There is no fork Topicbox-Message-UUID: d16494b2-ead9-11e9-9d60-3106f5b1d025 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 bitter, so I ought to stop now. It's possible the things you want won't intersect with the things which caused me trouble, but I think I have considerable reason for pessimism. > > Well, obviously I'm naive enough to try to do something better! :-D And that's not a bad thing! :) > > I think the problem is really tied to the nature of software > development... just because bugs are. Largely, yes. It can only be partially mitigated. I do think the best idea is for package authors to include dependencies in the package, not expecting users or distributors to do that work. Some will rant and holler about insecurity, and maybe they're right, but I want the freedom to try interesting software without the slave labour of looking after those difficult packages in the dependency tree. > > To my money you have an alternative: > - to be mostly self contained (as Plan 9/9front does), which is the > optimal solution to the problem > - to leverage outside softwares which evolve outside your control I like this, but it does rather require a team. > > Both solution have to cope with bugs: > - in Plan 9/9front you fix them > - in other systems you can still fix them but if you contribute back > the fix things turn "complex"... Yup. My thought about "fixing things in the right layer" is relevant here. If you have a self-contained system, you can do that. If it's split up, it requires cooperation. > > Versioning, dependency trees (or sometime even graphs) and all these > monsters comes from this problem. > > The self-contained approach is way more efficient... and simpler. Thus > it's very attractive to me. > > But, my insight is that these monsters need to be faced, and defeated. :-) > Since you can't stop (or control) the evolution of software you do not > code yourself, there's no way to avoid versioning and using that > software. There is: use the big commercial OSs for most stuff, and keep the software you want to develop private. Rather restricting, I know. :) > > But again my insight is that using static linking and namespaces, > packages can be way easier to maintain. I haven't considered namespaces in package management for a long time. I'm not convinced about the static linking part at all. It certainly makes binary package management simpler, but the problems I complain about occurred during compilation, or sometimes configuring. > > > Still, I'd really like to know details about your concerns and your > painful experiences, since they could put me on the right track. They're too far in the past to remember them all. Mostly they took this form: X requires Y and Z. Z's all right, but Y requires foo bar baz quux *and* syzygy, and then I'd find 3 of those had their own compilation problems. Slave labour required! The other thing was of course autohell, but that got a lot less likely some time during the last decade. It's still possible though. > > > > > I'd like to think there are enough people who don't want to be tied up in all this pain to create some semblance of a software ecosystem outside it, but when you consider that few people want to start from the ground up, and how poettering and fd.o have their tentacles in crucial parts of the posix-related ecosystem, it looks impossible. > > Well, actually there are several hobby OSes that do not support posix > and package management. > (and some have interesting ideas too...) I've always had a problem of not looking around enough. I use FreeDOS. It has a package manager, but I use unzip and deltree instead (or rm -r, i forget which.) > > But the problem with your approach is not just posix compliance. > > > For example, in Jehanne most tools you are used in Plan 9 are not part > of the core system. I have to say, as much as I like Plan 9 C and hate gcc, I understand you taking the C compilers out and replacing them with gcc. My big plan at the moment is to ditch C for a language which only requires an extremely small interpreter, and yet can be compiled too. I'm having a little bit of trouble following the indirection in a double-indirect threaded interpreter, but this is something I'm confident I can achieve. That language is Forth, but I'm starting to wonder if the same could be achieved with other languages. > > For example, porting Plan 9/9front games to Jehanne is trivial (could > even be automated), but their changes should not cause the core system > to "evolve". > > So the solution, again, is installing them as packages, with their own > versions. And this is the reason why there are no games in Jehanne: > they are waiting for a package manager. > > > The problem, as always, is to get the axes right. Oh that's similar to "put the fix in the right layer." Yup. > > > An OS core system should evolve as a whole. > But since its usefulness depend on the amount of things people can do > with it, it should also be able to run exogenous software. Your OS should, perhaps. :) My minimum requirements for an OS I'll consider useful are much lower, provided I have an alternative system for web browsing and maybe games. For 2 or 3 years I used 9front full time, primarily acme, telnet, and page. I was happy most of the time. Sometimes I'd play Minecraft or something like Second Life, but despite a certain amount of addiction to 3D graphics, I got almost as much out of my Plan 9 use. > > > The Plan9/9front approach is optimal because it's perfectly useful > exactly to the people it want to be useful to. > > > Jehanne is useless. It's just a toy, aka a research operating system. :-) > But in it's research scope is how to enable software development to > scale more easily than in mainstream alternatives. > > > My insight is that, as a simpler system, Jehanne will be more powerful. > And the additional simplicity/power will make such complex problems > almost disappear. Additional power can come with simplification, as everyone on this list knows. I hope it works out for you! :) > > > Giacomo > -- The lyf so short, the craft so long to lerne. -- Chaucer From mboxrd@z Thu Jan 1 00:00:00 1970 Message-Id: <1518616394.2858040.1270595576.11A8A6C2@webmail.messagingengine.com> From: Ethan Grammatikidis To: 9fans@9fans.net MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" Date: Wed, 14 Feb 2018 13:53:14 +0000 In-Reply-To: References:

<20180213162522.GB15332@wopr> <20180213181242.GA26808@wopr> <20180213191034.GB26808@wopr> <4D3A8F48-C712-48AF-B5C2-151ACBEB3D94@gmail.com> Subject: Re: [9fans] There is no fork Topicbox-Message-UUID: d17ee826-ead9-11e9-9d60-3106f5b1d025 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Wed, 14 Feb 2018 04:57:36 -0900 Message-ID: <42cec790-19d7-440e-945b-3be042547dda@email.android.com> In-Reply-To: From: Erik Quanstrom To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> MIME-Version: 1.0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Subject: Re: [9fans] There is no fork Topicbox-Message-UUID: d186dc7a-ead9-11e9-9d60-3106f5b1d025 PGRpdiBkaXI9J2F1dG8nPkkgYW0gc3RpbGwgdXNpbmcgYW5kIG1haW50YWluaW5nIDlhdG9tLiZu YnNwOyBJIGp1c3QgaGF2ZSBhIGJ1c3kgc2NoZWR1bGUgc28gcmVhZCB0aGUgbGlzdCBsZXNzLjxk aXYgZGlyPSJhdXRvIj48YnI+PC9kaXY+PGRpdiBkaXI9ImF1dG8iPi0gZXJpazwvZGl2PjwvZGl2 PjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnI+PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9u IEZlYiAxMSwgMjAxOCAxNDo0OCwgQmVuamFtaW4gSHVudHNtYW4gJmx0O0JIdW50c21hbkBtYWls Mi5jdS1wb3J0bGFuZC5lZHUmZ3Q7IHdyb3RlOjxiciB0eXBlPSJhdHRyaWJ1dGlvbiI+PGJsb2Nr cXVvdGUgY2xhc3M9InF1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6 MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+PGRpdiBkaXI9Imx0ciI+DQo8ZGl2IHN0 eWxlPSJmb250LXNpemU6MTJwdDtjb2xvcjojMDAwMDAwO2ZvbnQtZmFtaWx5OiYjMzk7Y2FsaWJy aSYjMzk7ICwgJiMzOTtoZWx2ZXRpY2EmIzM5OyAsIHNhbnMtc2VyaWYiIGRpcj0ibHRyIj4NCjxw IHN0eWxlPSJtYXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRvbTowIj4mZ3Q7wqA8c3BhbiBzdHlsZT0i Zm9udC1zaXplOjE0LjY2NjY2Njk4NDU1ODEwNXB4Ij45YXRvbSBhbmQgOWZyb250IGFyZSBib3Ro IGFjdGl2ZWx5IG1haW50YWluZWQuPC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tdG9wOjA7 bWFyZ2luLWJvdHRvbTowIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjY2NjY2Njk4NDU1ODEw NXB4Ij48YnIgLz4NCjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLXRvcDowO21hcmdpbi1i b3R0b206MCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC42NjY2NjY5ODQ1NTgxMDVweCI+SXQg c2VlbXMgbGlrZSA5YXRvbSBpcyBub3QgYWN0dWFsbHkgYWN0aXZlbHkgbWFpbnRhaW5lZCBhbnkg bG9uZ2VyLiDCoEkgaG9wZSBFcmlrIHNlZXMgdGhpcyBhbmQgcmVmdXRlcyBtZSwgdGhvdWdoITwv c3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLXRvcDowO21hcmdpbi1ib3R0b206MCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxNC42NjY2NjY5ODQ1NTgxMDVweCI+SSB3YXMgYXdhcmUgb2bCoEhh cnZleSzCoEplaGFubmUsIGFuZCBwbGFuOS05azwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjE0LjY2NjY2Njk4NDU1ODEwNXB4Ij4sIHRob3VnaCBJIGRpZG4mIzM5O3QgbWVudGlvbiB0aGVt IGJlY2F1c2XCoEkgd2FzbiYjMzk7dCBzdXJlIGhvdyAmIzM0O21haW5zdHJlYW0mIzM0OyB0aGV5 DQogd2VyZSwgb3IgaWYgdGhlcmUgd2FzIGFjdGl2ZSBkZXZlbG9wbWVudCBpbiB0aGUgY2FzZSBv ZiBwbGFuOS05ay4gwqBQbGVhc2UgcGFyZG9uIG1lLiA6KTwvc3Bhbj48L3A+DQo8cCBzdHlsZT0i bWFyZ2luLXRvcDowO21hcmdpbi1ib3R0b206MCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC42 NjY2NjY5ODQ1NTgxMDVweCI+PGJyIC8+DQo8L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi10 b3A6MDttYXJnaW4tYm90dG9tOjAiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQuNjY2NjY2OTg0 NTU4MTA1cHgiPlRvIGJlIGhvbmVzdCwgSSB3YXMgc29ydCBvZiBob3BpbmcgdG8gaGVhciBzb21l b25lIHNheSB0aGF0IDlhdG9tIHdpdGggdGhlIE5JWCBrZXJuZWwgaXMgdGhlIHdheSB0byBnby4g wqBVbmZvcnR1bmF0ZWx5LCBJIG1vc3RseSB1c2UgVk13YXJlIGFuZCBhIGZldyBvbGQtaXNoIGJ1 dCBzdGlsbCA2NC1iaXTCoFRoaW5rUGFkcywNCiBhbmQgOWF0b20gd29uJiMzOTt0IHNvIG11Y2gg YXMgYm9vdCBvbiBhbnkgb2YgdGhlbS4gwqBBbnlvbmUgb24gaGVyZSBtYW5hZ2VkIHRvIGdldCA5 YXRvbSB0byBydW4gaW4gVk13YXJlIG9yIG9uIGEgVzUwMC1zZXJpZXMgKDUwMCwgNTIwLCA1MzAp wqDCoFRoaW5rUGFkPzwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLXRvcDowO21hcmdpbi1i b3R0b206MCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC42NjY2NjY5ODQ1NTgxMDVweCI+PGJy IC8+DQo8L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi10b3A6MDttYXJnaW4tYm90dG9tOjAi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQuNjY2NjY2OTg0NTU4MTA1cHgiPk9yLCBpZiBvbmUg d2FudHMgTklYIGJ1dCB0byBzdGF5IGEgbGl0dGxlIGNsb3NlciB0byB0aGUgb3JpZ2luYWwgZGlz dHJpYnV0aW9uLCBhcmUgdGhlcmUgb3B0aW9ucywgb3IgaXMgSGFydmV5IHRoZSBvbmx5IHdheT88 L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi10b3A6MDttYXJnaW4tYm90dG9tOjAiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTQuNjY2NjY2OTg0NTU4MTA1cHgiPjxiciAvPg0KPC9zcGFuPjwv cD4NCjxwIHN0eWxlPSJtYXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRvbTowIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjE0LjY2NjY2Njk4NDU1ODEwNXB4Ij5Bbnl3YXksIEkgYWxzbyB3YW50IHRvIHNh eSB0aGFuayB5b3UgdG8gdGhlIHNtYXJ0IHBlb3BsZSBvbiB0aGlzIGxpc3Q8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxNC42NjY2NjY5ODQ1NTgxMDVweCI+IHdobyBoYXZlIG1haW50YWlu ZWQgYW5kIGFkdmFuY2VkwqBQbGFuIDkgaW4gaXRzDQogdmFyaW91cyBmb3JtcyBvdmVyIHRoZSB5 ZWFycyEhPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQuNjY2NjY2OTg0NTU4MTA1cHgi Pjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLXRvcDowO21hcmdpbi1ib3R0b206MCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxNC42NjY2NjY5ODQ1NTgxMDVweCI+PGJyIC8+DQo8L3NwYW4+ PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi10b3A6MDttYXJnaW4tYm90dG9tOjAiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTQuNjY2NjY2OTg0NTU4MTA1cHgiPlRoYW5rcy48L3NwYW4+PC9wPg0KPHAg c3R5bGU9Im1hcmdpbi10b3A6MDttYXJnaW4tYm90dG9tOjAiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTQuNjY2NjY2OTg0NTU4MTA1cHgiPjxiciAvPg0KPC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJt YXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRvbTowIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjY2 NjY2Njk4NDU1ODEwNXB4Ij4tQmVuPC9zcGFuPjwvcD4NCjxiciAvPg0KPGJyIC8+DQo8ZGl2IHN0 eWxlPSJjb2xvcjpyZ2IoIDAgLCAwICwgMCApIj4NCjxociBzdHlsZT0iZGlzcGxheTppbmxpbmUt YmxvY2s7d2lkdGg6OTglIiAvPg0KPGRpdiBkaXI9Imx0ciI+PGZvbnQgZmFjZT0iQ2FsaWJyaSwg c2Fucy1zZXJpZiIgc3R5bGU9ImZvbnQtc2l6ZToxMXB0IiBjb2xvcj0iIzAwMDAwMCI+PGI+RnJv bTo8L2I+IDlmYW5zLWJvdW5jZXMmIzY0OzlmYW5zLm5ldCAmbHQ7OWZhbnMtYm91bmNlcyYjNjQ7 OWZhbnMubmV0Jmd0OyBvbiBiZWhhbGYgb2YgR2lhY29tbyBUZXNpbyAmbHQ7Z2lhY29tbyYjNjQ7 dGVzaW8uaXQmZ3Q7PGJyIC8+DQo8Yj5TZW50OjwvYj4gU3VuZGF5LCBGZWJydWFyeSAxMSwgMjAx OCA0OjI2IEFNPGJyIC8+DQo8Yj5Ubzo8L2I+IEZhbnMgb2YgdGhlIE9TIFBsYW4gOSBmcm9tIEJl bGwgTGFiczxiciAvPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbOWZhbnNdIFRoZXJlIGlzIG5vIGZv cms8L2ZvbnQ+DQo8ZGl2PsKgPC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGZvbnQgc2l6ZT0iMiI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0Ij4NCjxkaXY+VG8gbXkga25vd2xlZGdlIHRoaXMgaXMg dGhlIHNldCBvZiBhY3RpdmUgcHJvamVjdHMgYmFzZWQgb24gUGxhbiA5OjxiciAvPg0KPGJyIC8+ DQo5YXRvbSBhbmQgOWZyb250IGFyZSBib3RoIGFjdGl2ZWx5IG1haW50YWluZWQuPGJyIC8+DQpC b3RoIHN0aWNrIHN0cm9uZ2x5IHRvIHRoZSBvcmlnaW5hbCBQbGFuIDkgZnJvbSBCZWxsIExhYnMg ZGVzaWduLjxiciAvPg0KQUZBSUssIDlmcm9udCBpbnRyb2R1Y2UgbW9yZSBpbm5vdmF0aW9ucywg Ym90aCBpbiBrZXJuZWwgYW5kIGluIHVzZXI8YnIgLz4NCnNwYWNlLCBidXQgd2hhdCBtYWtlIGl0 IHVuaXF1ZSBpcyB0aGUgI2NhdC12IGNvbW11bml0eS48YnIgLz4NCjxiciAvPg0KOWxlZ2FjeSBp cyBub3QgYSByZWFsbHkgZm9yaywgYnV0IGFuIG9yZ2FuaXplZCBjb2xsZWN0aW9uIG9mIHBhdGNo ZXMsPGJyIC8+DQphbmQgaXMgc3RpbGwgYWN0aXZlbHkgbWFpbnRhaW5lZC48YnIgLz4NCkFub3Ro ZXIgbm9uLWZvcmsgYWN0aXZlIHByb2plY3QgaXMgUGxhbiA5LUFOVFM8YnIgLz4NCig8YSBocmVm PSIiPjwvYT5odHRwOi8vd3d3LjlncmlkY2hhbi5vcmcvICkgd2hpY2ggYWxzbyBwcm92aWRlcyBh IDlmcm9udC1iYXNlZCBhbWQ2NDxiciAvPg0KaXNvIGFuZCBhIGZyZWUgOVAgZ3JpZCBvbmxpbmUu PGJyIC8+DQo8YnIgLz4NCkhhcnZleSYjMzk7cyBrZXJuZWwgaXMgYmFzZWQgb24gTklYLCBhbmQg QUZBSUssIGl0JiMzOTtzIHRoZSBvbmx5IHByb2plY3Q8YnIgLz4NCndoZXJlIE5JWCBkZXZlbG9w bWVudCBpcyBhY3RpdmUuPGJyIC8+DQo8YnIgLz4NCkZvcnN5dGgmIzM5O3MgUGxhbi05ayBoYWQg c29tZSBkZXZlbG9wbWVudCBpbiBtaWQgMjAxNy48YnIgLz4NCkl0JiMzOTtzIDIwMTUgdmVyc2lv biB3YXMgdGhlIHN0YXJ0aW5nIHBvaW50IG9mIEplaGFubmUmIzM5O3Mga2VybmVsLCB3aGljaCBp czxiciAvPg0KbXkgb3duIHJlc2VhcmNoIG9wZXJhdGluZyBzeXN0ZW0gKHRoYXQgYWxzbyBpbmNs dWRlcyBzZXZlcmFsIG9mPGJyIC8+DQo5ZnJvbnQmIzM5O3MgaW1wcm92ZW1lbnRzKS48YnIgLz4N CkplaGFubmUgaXMgdGhlIHByb2plY3QgdGhhdCBkaXZlcmdlZCBtb3N0IGZyb20gdGhlIG9yaWdp bmFsIFBsYW45PGJyIC8+DQpkZXNpZ24sIHdpdGggaXRzIG93biBzZXQgb2YgY3JhenkgZGVjaXNp b25zLCBidXQgY3VycmVudGx5IGl0JiMzOTtzIGFuPGJyIC8+DQp1bnN0YWJsZSB0b3kuPGJyIC8+ DQo8YnIgLz4NCjxiciAvPg0KR2lhY29tbzxiciAvPg0KPGJyIC8+DQoyMDE4LTAyLTEwIDM6NDgg R01UJiM0MzswMTowMCBCZW5qYW1pbiBIdW50c21hbiAmbHQ7Qkh1bnRzbWFuJiM2NDttYWlsMi5j dS1wb3J0bGFuZC5lZHUmZ3Q7OjxiciAvPg0KJmd0OyBKdXN0IGN1cmlvdXMgYXMgdG8gdGhlIHN0 YXRlIG9mIHRoZSB1bmlvbi7CoCBJcyA5ZnJvbnQgcHJldHR5IG11Y2ggdGhlIGRlPGJyIC8+DQom Z3Q7IGZhY3RvICYjMzQ7b2ZmaWNpYWwmIzM0OyBQbGFuIDkgdGhlc2UgZGF5cywgb3IgZG9lcyBh bnlvbmUgc3RpbGwgdXNlIG9yIG1haW50YWluIGFueTxiciAvPg0KJmd0OyBvZiB0aGUgZm9sbG93 aW5nOjxiciAvPg0KJmd0OzxiciAvPg0KJmd0OzxiciAvPg0KJmd0OyA5YXRvbTxiciAvPg0KJmd0 OzxiciAvPg0KJmd0OyBOSVg8YnIgLz4NCiZndDs8YnIgLz4NCiZndDsgOWxlZ2FjeTxiciAvPg0K Jmd0OzxiciAvPg0KJmd0OyBUaGUgb3JpZ2luYWwgQmVsbCBMYWJzIGRpc3RyaWJ1dGlvbjxiciAv Pg0KJmd0OzxiciAvPg0KJmd0OzxiciAvPg0KJmd0OyBUaGFua3MgZm9yIHlvdXIgaW5wdXQhPGJy IC8+DQomZ3Q7PGJyIC8+DQomZ3Q7PGJyIC8+DQomZ3Q7IC1CZW48YnIgLz4NCiZndDs8YnIgLz4N CiZndDs8YnIgLz4NCjxiciAvPg0KPC9kaXY+DQo8L3NwYW4+PC9mb250PjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KDQo8L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPjwvZGl2Pg== From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <7D7DD795FCACD03C69AD16416271610F@5ess.inri.net> Date: Wed, 14 Feb 2018 09:37:12 -0500 From: sl@9front.org To: 9fans@9fans.net In-Reply-To: D3CB83A6-32DB-4D5B-B358-BC6A098F85BD@gmail.com MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] There is no fork Topicbox-Message-UUID: d18db90a-ead9-11e9-9d60-3106f5b1d025 On Feb 14, 2018, at 2:18 AM, Rui Carmo wrote: > On 14 Feb 2018, at 00:31, sl@9front.org wrote: >=20 >> 1.) is the wrong approach. Just build inside Plan 9. >=20 > You missed the rest of the thread. I read the entire thread but I didn=E2=80=99t see this point specifically addressed. From the latest posts it is still unclear where you plan to do the compiling. Okay, so let=E2=80=99s 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=E2=80=99t been mentioned at all. That=E2=80=99s why I brought up th= e 9front fork of drawterm as a possible facilitator. It can handle 9front=E2=80=99s ne= w 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=E2=80=99t clear to me that you=E2=80=99ve spent any signific= ant 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=E2=80=99t like Plan 9 once they get here. Anyway, good luck with whatever your ultimate goal is. sl