Re: [9fans] SCMs

[Rui Carmo]

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

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

[Lucio De Re]

On 2/13/18, Mart Zirnask  wrote:
> On 13/02/2018, Lucio De Re  wrote:
>> Stenography (short-hand)?
>>
> Yes -- "everything is a line"!
> https://www.theatlantic.com/technology/archive/2014/06/yeah-i-still-use-shorthand-and-a-smartpen/373281/
>
Thank you for that bit of present-day archaeology.

Any idea what product the author was using? I live where woman
emancipation would probably still gain some traction by going though
the short-hand cycle, I guess we're stuck in some sort of time-warp.

Personally, I'd be willing, perhaps no longer able, to move along with
the times by going back a few decades :-). Ever since the bitsy port,
I've been meaning to look into this.

Thank you, Mart.

Lucio.

Re: [9fans] SCMs

[Bakul Shah]

On Tue, 13 Feb 2018 15:13:36 -0800 Lyndon Nerenberg  wrote:
> 
> +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.

Git has far too many subcommands and impementation warts but
its underlying model has just 4 types of objects. The
distributed part of git is conceptually fairly simple too.
Over time I have used sccs, rcs, cvs, subversion, mercurial,
git and a couple other SCMs. Each has its pros and cons.  By
now I primarily use git because I can run it on all the
platform and it is quite fast. And there is an active
ecosystem around it. Things like code review systems do help
quite a bit with improving code quality (in my last job I used
gerrit to brainwash people into following good practices by
providing detailed core review comments).

Dave MacFarlane's git client (dgit) does a decent job on plan9.

Re: [9fans] SCMs

[Erik Quanstrom]

well of course a worm is only equivalent if a user can snap and name any part of the tree at any time, and creat a new tree from any historical point.- erik

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.

[9fans] SCMs

[Lyndon Nerenberg]

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

Re: [9fans] ReMarkable!

[Mart Zirnask]

On 13/02/2018, Lucio De Re  wrote:
> On 2/13/18, Daniel Camolês  wrote:
>> [ ... ]
>>
>> 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.
>>
> Stenography (short-hand)?
>
Yes -- "everything is a line"!
https://www.theatlantic.com/technology/archive/2014/06/yeah-i-still-use-shorthand-and-a-smartpen/373281/

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

[Lyndon Nerenberg]

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.


Dust off the handwriting code that was done for the bitsy.

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

[Lucio De Re]

On 2/13/18, Daniel Camolês  wrote:
> [ ... ]
>
> 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.
>
Stenography (short-hand)?

Fashion is still driving the hand-held revolution. Let's salute the
few cases of technologists bucking the trend. Specially here, where we
experience the pain of swimming upstream on a daily basis.

Lucio.

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

[Daniel Camolês]

Well because... A keyboard is very cheap and if you could pay for your
tablet, you can probably afford it? And it's an efficient way to input
text, way more efficient than any handwriting on a screen.

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.

Em 13 de fev de 2018 12:21, "Ethan Grammatikidis" 
escreveu:

On Tue, Feb 13, 2018, at 12:52 PM, Daniel Camolês wrote:

You could use, you know, a keyboard


with my ordinary tablet? sure! with a $600 tablet whose main trick is the
handwriting input? why would i buy the tablet?

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

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

[Ethan Grammatikidis]

On Tue, Feb 13, 2018, at 12:52 PM, Daniel Camolês wrote:
> You could use, you know, a keyboard

with my ordinary tablet? sure! with a $600 tablet whose main trick is
the handwriting input? why would i buy the tablet?
--
The lyf so short, the craft so long to lerne. -- Chaucer

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

[Daniel Camolês]

You could use, you know, a keyboard

Em 13 de fev de 2018 10:49, "Ethan Grammatikidis" 
escreveu:

> On Mon, Feb 12, 2018, at 2:51 PM, hiro wrote:
> > your features sound neat, but they don't solve the problem of inputing
> > longer text.
> >
>
> i imagine many would find handwriting more comfortable than tapping a lot.
> possibly more accurate too, although an osk on a screen that big isn't too
> bad for accuracy. of course, i'm assuming the art of handwriting isn't dead
> yet. i won't get one because i was never very good at handwriting. :) i
> preferred the osk on my 2.5" palm back in '01. :) it was good with its
> stylus, and it wasn't one of those ridiculous modern stylii with the fat
> squishy tips. would need an active stylus to match it today.
>
> --
> The lyf so short, the craft so long to lerne. -- Chaucer
>
>

Re: [9fans] ReMarkable!

[Ethan Grammatikidis]

On Mon, Feb 12, 2018, at 2:51 PM, hiro wrote:
> your features sound neat, but they don't solve the problem of inputing
> longer text.
> 

i imagine many would find handwriting more comfortable than tapping a lot. 
possibly more accurate too, although an osk on a screen that big isn't too bad 
for accuracy. of course, i'm assuming the art of handwriting isn't dead yet. i 
won't get one because i was never very good at handwriting. :) i preferred the 
osk on my 2.5" palm back in '01. :) it was good with its stylus, and it wasn't 
one of those ridiculous modern stylii with the fat squishy tips. would need an 
active stylus to match it today.

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

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.