Re: [9fans] V Programming Language (vlang)

[Bakul Shah via 9fans]

In spite of this early drama it seems to be coming along fine. It feels more 
like go but with some different choices. Compiles itself in seconds (tcc or 
system c compiler as backend). I’ve written small programs in it and like it so 
far. It supports *BSD, linux, macos, windows, etc. but not plan9. Some folks 
are writing vinix, a linux like os in it + reimplementing a lot of unix 
programs in v.

Play with it and see what you think. Will it survive long term? Who knows but I 
enjoy playing with it! Toys don’t have to last forever:-)

> On Oct 2, 2024, at 1:18 PM, Willow Liquorice  wrote:
> 
> I did a bit of digging around on the internet about this after Noam's email, 
> because it piqued my curiosity. I'd always dismissed V as basically being 
> Zig, but without any of Zig's evolutionary ideas about memory management and 
> comptime execution.
> 
> When V was a young project, the lead dev made a lot of wild claims about its 
> capabilities and performance that turned out to be misleading or nonsensical, 
> while it was a closed-source project.[1]_[2]_[3]_
> 
> The project's credibility was, AFAICT, irreparably damaged in its infancy. 
> The cited pages (and the links therein) could serve as a foundation for a 
> personal judgement on the matter.
> 
>   - Willow
> 
> .. [1] https://github.com/vlang/v/issues/35
> .. [2] https://news.ycombinator.com/item?id=39492680
> .. [3] https://news.ycombinator.com/item?id=35550803
> 
>> On 02/10/2024 20:39, Don A. Bailey wrote:
>> Why? (Not being flip. This is the first I’ve heard of it and I’d like your 
>> thoughts.)
>> D
 On Oct 2, 2024, at 3:31 PM, Noam Preil  wrote:
>>> 
>>> V is a scam.
>>> 
>>> - Noam Preil

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T9d57d40811a8ec5d-M5b93508adce40db8b1930571
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Bug: Acme: Multiple running programs fight each other for visible area

[Bakul Shah via 9fans]

The plan9port-dev mailing list may be a better place for most of your
bug reports. Also, you can create "issues" on github.com/9fans/plan9port.

> On Sep 30, 2024, at 3:06 PM, kalter...@gmail.com wrote:
> 
> Expected behavior
> 
> Acme automatically allocates enough space to make the tip of running
> commands' output visible.
> 
> The allocation must happen deterministically or more predictably, so
> that multiple programs do not fight each other for visible area.
> 
> Unexpected behavior
> 
> Unfortunately, they do fight with each other, especially if there is a
> dozen of them.
> 
> Steps to reproduce the problem
> 
> Run the following in any three distinct directories:
> 
> (while () {
> sleep 1
> fortune
> })
> 
> Three +Errors windows open in the right column.
> 
> Make sure there is at least two windows above them. Expand the first
> in the column, so that all windows below it collapse. Now watch three
> last windows fighting each other for available space.
> 
> If you're still confused, you could watch the demo:
> https://imgur.com/a/zhSPBxS
> 
> plan9port version
> 
> a2567fcac9851e5cc965a236679f568b0e79cff2
> 
> OS version
> 
> macOS 14.5 (23F79)
> 
> 9fans / 9fans / see discussions + participants + delivery options Permalink

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T11a1c56500abf76a-M0f37d1899fc826c20b08bf44
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Where can I find active Plan 9 communities for support and collaboration?

[Bakul Shah via 9fans]

On Aug 4, 2024, at 10:33 PM, o...@eigenstate.org wrote:
> 
> Quoth Bakul Shah via 9fans <9fans@9fans.net>:
>> 
>> Looks like an opportunity to update upas (or Erik Quanstrom's nupas) :-)
>> AFAIK neither has support for filtering on the "From" line.
> 
> take a look at upas/filter -- you could do something like:
> 
>/bin/upas/filter -h $1 $2 'From: kalona.ayeli...@fastmail.us' /dev/null
> 
> in your pipeto file

I stand corrected. Thanks! [I never got around to using upas seriously].


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T9804faa2e50a80d8-M1255b2346bff5bd0618be841
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Where can I find active Plan 9 communities for support and collaboration?

[Bakul Shah via 9fans]

On Aug 4, 2024, at 4:40 PM, Michael Grunditz  wrote:
> 
> I wonder if there is a email client  with some kind of killfile like many old 
> usenet clients have.

Looks like an opportunity to update upas (or Erik Quanstrom's nupas) :-)
AFAIK neither has support for filtering on the "From" line.

But since you use gmail, you can set up a filter for this on the
https://mail.google.com/mail/u/0/#settings/filters
page. Not as easy as a killfile though!

Or you can just ride out this storm in a teacup.


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T9804faa2e50a80d8-M2ee1f86ac98791b87a5e3920
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Where can I find active Plan 9 communities for support and collaboration?

[Bakul Shah via 9fans]

As we used to say in the Usenet era,

 \|||/
 (o o)
,ooO--(_)---.
| Please|
|   don't feed the  |
| TROLL's ! |
'--Ooo--'
|__|__|
ooO Ooo

Deny them attention and they will go away eventually.

On Aug 3, 2024, at 3:40 PM, o...@eigenstate.org wrote:
> 
> In light of the low quality of posts on this list, the p9f set up
> a new, moderated, 9users list, and sent initial invites to people
> who attended iwp9.
> 
> Anyone currently on the list can propose new invites.
> 
> AI slop will not be tolerated there.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T9804faa2e50a80d8-M9228726d2782fc0a9005796c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] VCS on Plan9

[Bakul Shah via 9fans]

On Apr 18, 2024, at 2:48 PM, Shawn Rutledge  wrote:
> 
> Just another reason to eventually have Rust on Plan 9…

Yeah. Compiles are too damn fast; no time to make masala chai :-)


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tab2715b0e6f3e0a5-M56e1b18e4d67c6281934993d
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] VCS on Plan9

[Bakul Shah via 9fans]

On Apr 18, 2024, at 1:41 PM, Dan Cross  wrote:
> 
> Culturally, there was a feeling that source revision a la RCS, SCCS,
> etc, were unnecessary because the dump filesystem gave you snapshots
> already. Moreover, those were automatic and covered more than one file
> at a time; RCS/SCCS required some discipline in that one had to
> remember to check in a new revision. And as Paul said, the idea of an
> atomic, multi-file changeset was revolutionary at the time.

Readers here may be interested in our experience (circa 1982!)

At Fortune Systems, in 1982, Dave Yost come up with "cloned
tree" system for source code control. The idea was, each
developer gets their own src tree where all the files are
initally hard linked with the mastr tree (& are readonly). We
modified vi to always save the old file foo as ,foo and write
out a new file foo. [Note that the Rand editor e which many
of us used already did this.] This makes it easy to see that
files with link count == 1 are modified locally.  When some
feature / bugix is complete, someone would manually "commit"
changes to the "master" branch using diff to review them.
Dave wrote a paper about this called "A Rich Man's SCCS" in
Usenix Summer 1985.

Looking back, we had some (fuzzy) idea of a change set. But
we didn't have a way to keep a log of what changed and why.
And we didn't automate "commit". We did have a way of naming
top level trees ("frozen" ones by the date of the latest
modified file, development ones by the version we were
working on + developer name). We also modified tar to allow
saving and restoring a set of trees (recreating links for
identical files).
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tab2715b0e6f3e0a5-Me7d866a5dbc8db8e84dd93be
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] VCS on Plan9

[Bakul Shah via 9fans]

Did anyone try to port sccs to plan9?

> On Apr 18, 2024, at 9:11 AM, Paul Lalonde  wrote:
> 
> The Bell Labs approach to source control was, I'm, weak.  It relied on 
> snapshots of the tree and out-of-band communication.  Don't forget how small 
> and tight-knit that development team was, and how valuable perfect historic 
> snapshots were.
> 
> Add that 40 years ago source code revision control systems were incredibly 
> primitive.  The idea of an atomic change set (in Unix land at least) was 
> revolutionary in the early 90s.
> 
> This is one place where 35 years of evolution in software practices has very 
> much improved.
> 
> Paul
> 
> On Thu, Apr 18, 2024, 8:55 a.m. certanan via 9fans <9fans@9fans.net 
> > wrote:
>> Hi,
>> 
>> is there any more "organic/natural" way to do source control on today's 
>> Plan9 (9front specifically), other than Ori's Git?
>> 
>> In other words, how (if at all) did people at Bell Labs and the community 
>> alike originally manage their contributions in a way that would allow them 
>> to create patches without much hassle?
>> 
>> Was it as simple as backing a source tree up, making some changes, and then 
>> comparing the two? Venti? Replica?
>> 
>> tom
> 
> 9fans  / 9fans / see discussions 
>  + participants 
>  + delivery options 
> Permalink 
> 

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tab2715b0e6f3e0a5-M65f0bf5f4f88547e7f42ac54
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] troll paper

[Bakul Shah via 9fans]

On Apr 15, 2024, at 1:50 PM, Charles Forsyth  wrote:
> 
> And, if I hear about it being
> “declarative” as a virtue, I point to the 81,000+ lines (and
> growing) of YAML, that I defy any one human to comprehend.
> 
> You might find help in culang.org

Not sure how much the Cue language will help when the
underlying model of Kubernetes is quite complex (pods,
containers, deployments, nodes, schedulers, controllers,
clusters, services, load balancing, tasks, kubelets,
kube-proxies, api-servers, multi-tenancy, replicas,
namespaces and so on). May be all you can do is push this
complexity around but not conquer it.

In any new design, at the start you often overbuild
because you don't quite know what will work but soon you
have to sense what is scaffolding and can be removed vs
what is essential and must be left in.
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T51f7f5a8927e1271-M532d92757e5a02a419f67eac
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] openat()

[Bakul Shah via 9fans]

Faster for any command that operates on dir trees such as diff, du, rm, tar.When I first looked at plan9, I was a bit surprised its open *didn’t* workthis way! May be because of this earlier thread on comp.unix.wizardshttps://groups.google.com/g/comp.unix.wizards/c/i8vapj9BAqs/m/FlNUK705I0UJ (which has nothing to do with plan9 but people explored some researchy ideas)On Apr 6, 2024, at 10:37 AM, ron minnich  wrote:openat gives you the effect of 'cd path; open file' without having to cd. I don't see a lot of benefit to it unless you're opening a lot of files at that path.

9fans
  / 9fans / see
discussions
  +
participants
  +
delivery options
Permalink

Re: [9fans] openat()

[Bakul Shah via 9fans]

To me this sounds very similar to open() given a path relative to your current 
working directory.

> On Apr 5, 2024, at 2:22 PM, ron minnich  wrote:
> 
> not so much what I want, I'm curious about ideas people have about 
> implementing it that I would not think of.
> 
> On Fri, Apr 5, 2024 at 1:38 PM Gorka Guardiola  > wrote:
>> Hmm sorry. Now I see what you want. Not to rewalk. You can use the chan of 
>> the dirfd and walk just the remainder cloning it and creating a new one. 
>> That way the openat provides the guarantees you want.
>> 
>> On Fri, Apr 5, 2024, 22:15 Gorka Guardiola > > wrote:
>>> I mean, if you want a new syscall jus copy or call the implementation of 
>>> these.
>>> 
>>> 
>>> On Fri, Apr 5, 2024, 22:12 Gorka Guardiola >> > wrote:
 ¿Isn't that fd2path, strcat and open?
 Or am I misunderstanding something?
 
 On Fri, Apr 5, 2024, 21:51 ron minnich >>> > wrote:
> One of the folks I worked with, when we pulled a big chunk of plan 9 into 
> akaros, commented that he had implemented openat on akaros. 
> 
> I don't want this to turn into a debate on the merits of openat; I am 
> more curious: if you went to implement openat on Plan 9, how would you go 
> about it? I have a few ideas but I'm more interested in your ideas.
> 
> Thanks
> 
> 9fans  / 9fans / see discussions 
>  + participants 
>  + delivery options 
> Permalink 
> 

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T675e737e776e5a9c-M0efc38028930341e0db8f794
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: Charting the Future: Envisioning Plan 9 Release 5 for the 9fans Community. [Was:Re: [9fans] Supported Notebooks]

[Bakul Shah]

On Jan 25, 2024, at 8:44 AM, Don Bailey  wrote:
> 
> I'm not sure what all this was, so I didn't read most of it. 
> 
> If 9front becomes the "mainline" 9, I will stop using 9 altogether. Both as a 
> user and a developer. 
> 
> I trust the sources that come from 9legacy/9pio but I don't have any interest 
> in the mess of whatever 9front is supposed to be.

9front is eminently usable. May be you are rejecting it for the wrong reasons?


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T42f11e0265bcfa18-Mb71d859edbb24de170bf2c71
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Plan9 multi-core support

[Bakul Shah]

In addition to the papers Ori pointed out, you may wish to read Francisco J 
Ballesteros' Notes on the Plan9 3rd edition kernel:
https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.75.5409

I don't know how obsolete this is for the current versions of plan9. 
https://github.com/Plan9-Archive/plan9-3e
supposedly has the version described in the above notes but I haven't verified. 

> On Aug 26, 2023, at 12:33 PM, dusan3...@gmail.com wrote:
> 
> Does plan9 have multi-core support? If it does, how does it manage it (what 
> files/man pages/docs do I read). If it doesn't have, how would I implement 
> it. 
> 9fans  / 9fans / see discussions 
>  + participants 
>  + delivery options 
> Permalink 
> 

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T912e4838cb1a371f-M2a931aa9ad094e9ae670cfaa
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] [PATCH] fossil: fix a deadlock in the caching logic

[Bakul Shah]

Things like wear leveling are done by the FTL (flash translation layer) in the 
firmware. Other things it does: erase before write, logical to physical 
mapping, erasing blocks, garbage collection (moving live data around to free up 
whole blocks) etc. Typically ease blocks are 128KB or larger but seem to be 
treated as a secret by the SSD companies! At least NVMe SSDs provide at least 
64 request queues, each can hold lots of requests. There is enough buffering to 
be  able to flush all data to the Flash in case of power failure but not sure 
if that is exposed to the user (apart from a flush command).

Apart from not doing seek related optimizations and placement, you’d probably 
want to minimize unnecessary writes as SSD lifetime is limited by the amount 
you write (seems to be about at least 600 times the capacity so a TB disk will 
have 600TBW lifetime). That means avoiding metadata updates if you can, 
Deduplication may also help. I have heard that you can never really erase data 
even if you do a secure erase so the FS should have an encryption layer. On the 
flip side it may *lose* data if left unpowered for a long time (this period 
goes down fast with increased temperature). JEDEC says 1 year retention at 30°C 
for consumer and 3 month retention at 40°C for enterprise SSDs. So may be a FS 
driver should do a background scrub on reconnect if the device was not powered 
on for a long time.

> On Apr 8, 2023, at 8:12 AM, Dan Cross  wrote:
> 
> On Sat, Apr 8, 2023 at 10:37 AM Charles Forsyth
>  wrote:
>> It was the different characteristics of hard drives, even decent SATA, 
>> compared to SSD and nvme that I had in mind.
> 
> Since details have been requested about this. I wouldn't presume to
> speak from Charles, but some of those differences _may_ include:
> 
> 1. Optimizing for the rotational latency of spinning media, and its effects 
> vis:
>  a. the layout of storage structures on the disk,
>  b. placement of _data_ on the device.
> 2. Effects with respect to things that aren't considerations for rotating 
> disks
>  a. Wear-leveling may be the canonical example here
> 3. Effects at the controller level.
>  a. Caching, and the effect that has on how operations are ordered to
> ensure consistency
>  b. Queuing for related objects written asynchronously and
> assumptions about latency
> 
> In short, when you change storage technologies, assumptions that were
> made with, say, a filesystem was initially written may be invalidated.
> Consider the BSD FFS for example: UFS was written in an era of VAXen
> and slow, 3600 RPM spinning disks like RA81s attached to relatively
> unintelligent controllers; it made a number of fundamental design
> decisions based on that, trying to optimize placement of data and
> metadata near each other (to minimize head travel--this is the whole
> cylinder group thing), implementation that explicitly accounted for
> platter rotation with respect to scheduling operations for the
> underlying storage device, putting multiple copies of the superblock
> in multiple locations in the disk to maximize the chances of recovery
> in the event of the (all-too-common) head crashes of the era, etc.
> They also did very careful ordering of operations for soft-updates in
> UFS2 to ensure filesystem consistency when updating metadata in the
> face of a system crash (or power failure, or whatever). It turns out
> that many of those optimizations become pessimizations (or at least
> irrelevant) when you're all of a sudden writing to a solid-state
> device, nevermind battery-backed DRAM on a much more advanced
> controller.
> 
> - Dan C.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T354fe702e1e9d5e9-M30011df66797d8263cd1bf6c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] plan 9 and lisp

[Bakul Shah]

s9fes code is easy to read but there are lots of choices on unix platforms which are better than s9fes in many respects. I usually use gambit or chez scheme. But most of them depend on unix or tools available on unix. While creating a scheme interpreter is relatively easy, what is missing is an industrial strength scheme “with batteries included” (Go is a good example of this). And no, IMHO Racket is not it. On Jan 23, 2023, at 3:34 AM, Nick LaForge  wrote:Not Plan 9, but lately I've been working in Chicken, which is a lovely pragmatic Scheme for *nix: https://www.call-cc.org/ . Perhaps I should give s9fes a shot as well!NickOn Fri, Jan 20, 2023 at 11:47 AM Bakul Shah <ba...@iitbombay.org> wrote:Thanks!Nick Nickolov's k comes with solutions to ~150  AoC-{2015..2022} puzzles. All run when you make k! As an example, here is aoc/21/25.k (Game of Sea Cucumbers, which Russ vlogged about): #!../../kn:#'1*:\x:".>v"?0:"i/25"(l;d;r;u):n/'n!'/:(!n)+/:3(|1 -1*)\!2 /left down right upi:0;{i+:1;x:a[r]+x*~a:(1=x)>x l;(2*a d)+x*~a:(2=x)>x u}/,/x;i[Of course, the real fun is in solving these puzzles but it helps to know what others do!]Unfortunately no plan9 port as it relies on mmap.https://codeberg.org/ngn/khttps://xpqz.github.io/kbook/Introduction.htmlhttps://github.com/razetime/ngn-k-tutorialIt is also one of the fastest (~0.5 sec to generate and add a billion numbers on a Ryzen 2700).On Jan 19, 2023, at 9:07 AM, Skip Tavakkolian <skip.tavakkol...@gmail.com> wrote:Regarding Ivy, rsc has some fantastic example code in the form ofsolutions to the Advent of Code 2021 puzzles:https://www.youtube.com/@rscgolang/videosOn Thu, Jan 19, 2023 at 7:48 AM Bakul Shah <ba...@iitbombay.org> wrote:On Jan 19, 2023, at 7:57 AM, mkf9 <m...@riseup.net> wrote:Lassi Kortela wrote:Chibi-Scheme has run on Plan 9.and also S9, which Bakul Shah ported to Plan 9,https://github.com/bakul/s9fes.Nils M Holm, the author of s9fes, did the originalport with some help from me. He didn't want tomaintain plan9 related changes which is why I ammaintaining it. Nils also has a book on it butAFAIK it doesn't cover anything specific to plan9.Speaking of little languagesNils also ported his klong array programming languageto plan9 & has a book on it! Slightly more verbosethan k (roughly k3 from kx.com)Then there is https://github.com/ktye/i which supportsa dialect of k. Not sure which, probably k6 or k7. Andthere is minimal help in the form of readme.txt but itcompiles & runs on 9front:% git/clone https://github.com/ktye/i% git/clone https://github.com/ktye/wg% cd i% go build '-buildvcs=false'% ./kktye/k!100 1 2 3 4 5 6 7 8 9+\!100 1 3 6 10 15 21 28 36 45d:`a`b`c!(1 2;3 4;5 6)d`a|1 2`b|3 4`c|5 6+da b c-1 3 52 4 6\\There is of course Rob Pike's ivy.--9fans: 9fansPermalink: https://9fans.topicbox.com/groups/9fans/T7b0afbefb53189b6-Mfc5857d5dc8b7c9e5c3f2194Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

9fans
  / 9fans / see
discussions
  +
participants
  +
delivery options
Permalink

Re: [9fans] plan 9 and lisp

[Bakul Shah]

Thanks!

Nick Nickolov's k comes with solutions to ~150  AoC-{2015..2022} puzzles. All 
run when you make k! As an example, here is aoc/21/25.k (Game of Sea Cucumbers, 
which Russ vlogged about): 

#!../../k
n:#'1*:\x:".>v"?0:"i/25"
(l;d;r;u):n/'n!'/:(!n)+/:3(|1 -1*)\!2 /left down right up
i:0;{i+:1;x:a[r]+x*~a:(1=x)>x l;(2*a d)+x*~a:(2=x)>x u}/,/x;i

[Of course, the real fun is in solving these puzzles but it helps to know what 
others do!]
Unfortunately no plan9 port as it relies on mmap.

https://codeberg.org/ngn/k
https://xpqz.github.io/kbook/Introduction.html
https://github.com/razetime/ngn-k-tutorial

It is also one of the fastest (~0.5 sec to generate and add a billion numbers 
on a Ryzen 2700).

> On Jan 19, 2023, at 9:07 AM, Skip Tavakkolian  
> wrote:
> 
> Regarding Ivy, rsc has some fantastic example code in the form of
> solutions to the Advent of Code 2021 puzzles:
> https://www.youtube.com/@rscgolang/videos
> 
> On Thu, Jan 19, 2023 at 7:48 AM Bakul Shah  wrote:
>> 
>> On Jan 19, 2023, at 7:57 AM, mkf9  wrote:
>>> 
>>> Lassi Kortela wrote:
>>>> Chibi-Scheme has run on Plan 9.
>>> and also S9, which Bakul Shah ported to Plan 9,
>>> https://github.com/bakul/s9fes.
>> 
>> Nils M Holm, the author of s9fes, did the original
>> port with some help from me. He didn't want to
>> maintain plan9 related changes which is why I am
>> maintaining it. Nils also has a book on it but
>> AFAIK it doesn't cover anything specific to plan9.
>> 
>> Speaking of little languages
>> Nils also ported his klong array programming language
>> to plan9 & has a book on it! Slightly more verbose
>> than k (roughly k3 from kx.com)
>> 
>> Then there is https://github.com/ktye/i which supports
>> a dialect of k. Not sure which, probably k6 or k7. And
>> there is minimal help in the form of readme.txt but it
>> compiles & runs on 9front:
>> 
>> % git/clone https://github.com/ktye/i
>> % git/clone https://github.com/ktye/wg
>> % cd i
>> % go build '-buildvcs=false'
>> % ./k
>> ktye/k
>> !10
>> 0 1 2 3 4 5 6 7 8 9
>> +\!10
>> 0 1 3 6 10 15 21 28 36 45
>> d:`a`b`c!(1 2;3 4;5 6)
>> d
>> `a|1 2
>> `b|3 4
>> `c|5 6
>> +d
>> a b c
>> -
>> 1 3 5
>> 2 4 6
>> \\
>> 
>> There is of course Rob Pike's ivy.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T7b0afbefb53189b6-M28a9059decf39a3bacc5e4c6
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] plan 9 and lisp

[Bakul Shah]

> On Jan 19, 2023, at 8:01 AM, Dan Cross  wrote:
> 
> On Thu, Jan 19, 2023 at 10:48 AM Bakul Shah  wrote:
>> [snip]
>> Nils M Holm, the author of s9fes, did the original
>> port with some help from me. He didn't want to
>> maintain plan9 related changes which is why I am
>> maintaining it. Nils also has a book on it but
>> AFAIK it doesn't cover anything specific to plan9.
> 
> I thought that Ozan Yigit had done a small scheme that ran on plan9 at
> one point, but I can't find a pointer to it on his page at York at the
> moment. Maybe I'm misremembering, but I definitely remember running a
> scheme repl under rio, which was actually quite pleasant. Someone
> (Russ?) had also ported mosml, which is also interesting to play
> around with.

Ozan did Portable Scheme Interpreter (psi). I had it running on
some BSD in mid '90s.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T7b0afbefb53189b6-M6d073270593ca2d9516d06c5
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] plan 9 and lisp

[Bakul Shah]

On Jan 19, 2023, at 7:57 AM, mkf9  wrote:
> 
> Lassi Kortela wrote:
>> Chibi-Scheme has run on Plan 9.
> and also S9, which Bakul Shah ported to Plan 9,
> https://github.com/bakul/s9fes.

Nils M Holm, the author of s9fes, did the original
port with some help from me. He didn't want to
maintain plan9 related changes which is why I am
maintaining it. Nils also has a book on it but
AFAIK it doesn't cover anything specific to plan9.

Speaking of little languages
Nils also ported his klong array programming language
to plan9 & has a book on it! Slightly more verbose
than k (roughly k3 from kx.com)

Then there is https://github.com/ktye/i which supports
a dialect of k. Not sure which, probably k6 or k7. And
there is minimal help in the form of readme.txt but it
compiles & runs on 9front:

% git/clone https://github.com/ktye/i
% git/clone https://github.com/ktye/wg
% cd i
% go build '-buildvcs=false'
% ./k
ktye/k
!10
0 1 2 3 4 5 6 7 8 9
+\!10
0 1 3 6 10 15 21 28 36 45
d:`a`b`c!(1 2;3 4;5 6)
d
`a|1 2
`b|3 4
`c|5 6
+d
a b c
-
1 3 5
2 4 6
\\

There is of course Rob Pike's ivy.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T7b0afbefb53189b6-Ma405fc042ed723067725c40e
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Error when running >spell

[Bakul Shah]

On Jan 13, 2023, at 5:00 AM, revr...@mweb.co.za wrote:
> 
> I successfully installed plan9port on Ubuntu.
> 
> It created an acme-home folder for me when I ran acme.
> 
> Most commands are working fine except that when I try to run >spell on a 
> selection or |rot13 I get these errors:
> 
> "Sh":fail:'./spell.dis' file does not exist
> 
> sh: rot13: './rot13' file does not exist

Looks like it is not looking into $PLAN9/bin

Make sure you run acme with  env. variable SHELL=$PLAN9/bin/rc

with PLAN9 set to /usr/local/plan9 or wherever you have installed p9p.




--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T776880ea45b5218a-M8e908badd19e6bb5be6db62c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] 9p server to multiply 9p messages?

[Bakul Shah]

On May 31, 2022, at 9:14 AM, ron minnich  wrote:
> 
> On Mon, May 30, 2022 at 12:21 AM Bakul Shah  wrote:
>> 9p itself is low performance but that is a separate issue.
> 
> Bakul, what are the units? It might be helpful to quantify this
> statement. Are you possibly conflating Plan 9 file systems being slow
> and 9p being slow?

I did a quick test:

>From a 9front VM to another machine I get about 11.7 MBps
caching. The first time around it was close to 7.3 MBps).

>From an Ubuntu VM to another machine I get about 111 MBps
(cached. The first time around it was close to 62 MBps).

Both VMs run on the same host. Test copies to the same target
machine. I used 9p read for 9front, scp for Linux, copy to
/dev/null. The target machine is freebsd. The VMs talk to
the target over a 1Gbps ethernet (so 111 MBps is the wirespeed
limit).

9front uses hjfs. Ubuntu uses ext4. On the host I give a file
as the guest "disk", using 'nvme' type device on bhyve to each
VM. Both 9front and ubuntu are 64 bit kernels.

This is a very rough measurement as there are many differences
between the systems. The filesystem overhead is clearly an issue
but 10 times worse?
-
Looking at the protocol:

For read/write 9p uses 4 byte for size so in theory you can send
very large packets but then you have to buffer up a lot of data.
Ideally you want streaming (some sort of sliding window). May be
you can use the tag field to do something more intelligent. Not
sure any implementations do so. You also have head of line blocking
if you can have only one TCP connection to a server.

> As Rob pointed out in 2013, "If go install is slow on Plan 9, it's
> because Plan 9's file system is
> slow (which it is and always has been)", so slowness in Plan 9 file
> systems is to be expected.
> 
> 9p itself does have its limits, which is why Bell Labs Antwerp started
> an effort in 2011 to replace it, but the new work never went very far.
> 
> I also know of a number of efforts in the virtualization world where
> 9p was discarded for performance reasons. It's hard to argue with the
> 100x performance improvement that comes with virtiofs, for example.


Why is virtiofs 100x faster? Just lot of hardwork and tuning?
May be that is good place to look to learn what needs to change
(in case someone wants to replace 9p with something else)?
 
> Gvisor is replacing 9p: https://github.com/google/gvisor/milestone/6.
> Although, in the latter case, I would argue the problem is more with
> Linux limitations than 9p limitations -- linux can't seem to walk more
> than one pathname component at a time, for example, since it has the
> old school namei loop.
> 
> But I'm wondering if you have a measurement with numbers.
> 
> For rough order of magnitude, HPC file systems can deliver 10 Gbytes/
> second for file reads nowadays, but getting there took 20 years of
> work. When we ran Plan 9 on Blue Gene, with the 6 Gbyte/second
> toroidal mesh connect for each node, we never came remotely close to
> that figure.

Given that experience, why do you need "numbers"? :-)

Running 10Gbps links even @ home is quite doable now. With TCP you
can achieve decent performance if not quite wirespeed. NVMe "disks"
are pretty damn fast - you can easily get 2-4 GBps. But I think at
remote filesystem protocol level you'd have to optimize multiple
things in order to get close to wirespeed performance. Minimize
copying, increase concurrency, reduce overhead in frequently used
common path code, reduce user/kernel crossings etc. I think rdma and
mmap will probably get used a lot too (obviously on non-plan9 OSes!).
May be if you pushed 9p knowledge down to a smart NIC, it can map a
tag value to compute location where the data needs to go.

But all this is just handwaving. Without a real project and funding
it is hard to get sufficiently motivated to do more.



--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T769854fafd2b7d35-Mf37a0689afc5c54c9aba65d7
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] 9p server to multiply 9p messages?

[Bakul Shah]

On May 29, 2022, at 10:01 PM, o...@eigenstate.org wrote:
> 
> the challenge is that 9p is stateful, so all servers must
> replay the same messages in the same order; this means that
> if one of the replicas fails or returns a result that is not
> the same as the other, the front falls off.
> 
> this means mirroring messages naïvely reduces reliability
> and performance, rather than increasing it.

I was not thinking of mirroring.

I was thinking of ckustered or distributed systems like
CephFS, IPFS, GlusterFS etc but thinking a cleaner &
simpler design might be possible. But it is quite possible
my brainstorm/pipedream is not realistic!

9p itself is low performance but that is a separate issue.
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T769854fafd2b7d35-M356e62122d1f1d87bf554dca
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] 9p server to multiply 9p messages?

[Bakul Shah]

On May 28, 2022, at 9:02 AM, fge...@gmail.com wrote:
> 
> Has anybody considered (or maybe even implemented) a 9p server to
> multiply incoming 9p messages to 2 or more 9p servers?
> Maybe with 2 different strategies for responding to the original request?
> 1. respond as soon as at least 1 response from one of the 9p servers
> is received,
> 2. respond only after all responses had been received.

Some variation of this would be interesting for a clustered
or distributed filesystem. The challenge would be doing this
in an understandable way, cleanly and with good performance.
Probably using separate namespaces for control & management
operations.

[Just brainstorming here...]
May be think about this using a clean slate approach.
Features that can be of use:

- fault tolerance (more than one node storing the same bits)
- scalable (in capacity, throughput, clients and server nodes)
- consistent view of the "same" FS by its clients
- file migration (transparent to a client e.g. to reduce latency)
- controlled sharing
- file size that can exceed the capacity of a single node
- allow storing files bigger than can fit on a node
- nodes can show up/go away dynamically
- provide multiple security domains (one bank, many customers!)
- access to older snapshots
- allow use of any local FS for storage
- easy to provision & manage




--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T769854fafd2b7d35-M30f1ef13e6748428ffc79346
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] void*

[Bakul Shah]

I can see some use of void* arithmetic for malloc/free or
when you’re doing your own allocation for various object
types, where a size of 1 would be handy.

I wonder what a FarC would like!

> On May 15, 2022, at 11:27 PM, Skip Tavakkolian  
> wrote:
> 
> 
> If void can have a size, why not 4, 8 or 16?
> 
> P.S. I discovered Gholami Rudi's work a little while ago. I was especially 
> intrigued by Farsi support in neatroff (intro in Farsi produced by Neatroff 
> and Neatpost: https://litcave.rudi.ir/neatfarsi.pdf 
> )  Cool stuff.
> 
> 
> On Sun, May 15, 2022, 9:09 AM adr mailto:a...@sdf.org>> wrote:
> In case someone is asking why this guy is suddenly so thoughtful
> about void pointers, it is because I'm porting Ali Gholami Rudi's
> neatroof, and he uses a lot of arithmetics with void* in neatmkfn.
> I got rid of ape, and this troff looks really easy to port and has
> a lot of features. I'll share it when it's working in case someone
> is interested.
> 
> --
> 9fans: 9fans
> Permalink: 
> https://9fans.topicbox.com/groups/9fans/Tecaea3b9ec8e7066-M683ed8fb049de7a5d4457cbf
>  
> 
> Delivery options: https://9fans.topicbox.com/groups/9fans/subscription 
> 
> 9fans  / 9fans / see discussions 
>  + participants 
>  + delivery options 
> Permalink 
> 
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tecaea3b9ec8e7066-M5831ffd0a329bdcb8294ee6b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] void*

[Bakul Shah]

> On May 15, 2022, at 8:23 AM, Dan Cross  wrote:
> 
> On Sun, May 15, 2022 at 9:16 AM adr  wrote:
> On Sun, 15 May 2022, adr wrote:
> > What I mean is if we are going to follow C99 in the use of void*,
> > we should allow arithmetic on them.
> 
> Let me be clear, I know that C99 requires the pointer to be a
> complete object type to do arithmetic, and I like that, is consistent.
> But then I don't see the point to use void* as a generic pointer.
> 
> I confess that I am confused about what, precisely, you are asking for.
> 
> You are correct that standard C only allows arithmetic on pointers to 
> complete object types. But `void *` is not a pointer to a complete object 
> type, and so therefore pointer arithmetic on pointers of type `void *` is 
> illegal. So in that sense, Plan 9 C is already following C99.
> 
> - Dan C.

Can't quote chapter and verse but AFAIK standard C allows +/- on void*.
So for example the following is legal:

void*f(void*x){return x+1;}

The returned value will be one more than the arg.


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tecaea3b9ec8e7066-M57ca9f2db655438f69c42dbf
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Plan 9 applying to GSoC

[Bakul Shah]

On Feb 19, 2022, at 3:02 AM, sirjofri  wrote:
> (4) A filesystem that filters a namespace, but the file contents and not the 
> namespace.
> 
> The idea is to have a filesystem like exportfs, however, it doesn't just 
> represent the files as is, but applies user-defined filters to the 
> filenames/paths as well as the file contents.
> 
> Imagine you have a namespace which contains markdown files that end with .md. 
> Using this overlay filesystem you can present the same namespace, but convert 
> the filenames using sed (from .md to .html) and when reading, the file 
> contents (from markdown syntax to html syntax).
> 
> The filesystem would be very powerful for exposing plain text data as html, 
> encapsulating data into some predefined layout, and much more. It could 
> essentially make any plain text filesystem available as regular web-friendly 
> html files, convert troff source to postscript, convert plan 9 images to png, 
> and much more. You can even present device files as json for modern web 
> applications.

May be create a generic filter-fs that can be controlled with a script that can 
be updated via a control interface? Almost a mkfile like script so if a rule 
exists for .md -> .html, any listing will show foo.html instead of foo.md. 
Reading foo.html will transparently invoke a conversion program. You can get 
pretty clever and may be even install a src dir under /bin this way to build 
binaries on the fly! Or even just the presence of a mkfile in a filtered 
directory would be enough for this behavior. Taking this further, an 
installation of a new machine can be made instantaneous! Just use a local cache 
for all the binaries as they get built! Obviously this should be called mkfs :-)



--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T745cda5087701a0d-Me5af03b18c19111f8ced87fb
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] licence question

[Bakul Shah]

Note that djvu would compress things very nicely. A full page
300dpi magazine color page that may be 25MB uncompressed will
compress down to 40K-80K or so and be very legible, much more
so compared a similar sized jpeg compressed image.

The current OSS djvu library is GPL but as far as I know the
original AT&T patent on the djvu technology has expired. If
anyone wants to reimplement it with a more permissive
license! The benefit is that there are a lot of existing djvu
encoded documents.

[Note: if anyone does decide to reimplement djvu, they should
not just take my word for it but verify that the djvu
patent(s) have indeed expired]

> On Jan 29, 2022, at 6:08 AM, ibrahim via 9fans <9fans@9fans.net> wrote:
> 
> A great amount of this size is caused by hand written sample solution scans 
> for past exams provided as 300dpi images (png or ppm). Most of my notes are 
> handwritten cause this way to provide solutions for exam questions is faster 
> and simpler.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T3e07bfdf263a83c8-Mdd199b934b9106c8bef6df07
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] licence question

[Bakul Shah]

If there is no programming to be done by the kiosk users, why do you need
any compilers? Similarly you can remove many other things from your
kiosk image. In fact you should have a script that prepares the image.

xorg needs llvm only for *building* mesa-dri.  If you are just using prebuilt
freebsd packages, you don't need it. Even if you are compiling some things
inside the kiosk, you can probably make do with tcc, which is much much
smaller and faster (though it won't generate as fast code as llvm or gcc).
tcc is LGPL so your code is not infected. Just by cutting out the two copies
of llvm, your image size will shrink by about 400-500MB.

Also note that plan9 c compilers are likely no faster than tcc. And there will
be other challenges.

Not to dissuade you from switching to plan9 but just pointing out
there are ways to reduce the image size while staying with FreeBSD.

> On Jan 29, 2022, at 5:03 AM, ibrahim via 9fans <9fans@9fans.net 
> > wrote:
> 
> On Friday, 28 January 2022, at 10:59 PM, hiro wrote:
>> why should it be closed source? you're gonna seriously put the effort to 
>> remove all the traces of source files?
> 
> This kiosk app is meant for students in math, electrotechnics, mechanics ... 
> its a closed area network where only registered students can connect. This 
> plattform is only meant for exchange of data and informations. The app is 
> distributed as an iso to be run from bare hardware or qemu (virtual box). The 
> current version is running based on FreeBSD and has a size caused by X11 
> necessity and accompanying programs of 800 MB. I'm trying to reduce the size 
> and increasing the performance by using plan9. My plattform generates form 
> many simulation tasks, symbolic calculations, plotting, ... intermediate C 
> code and translates this to programs which are called as child processes and 
> generate their output for rendering. LLVM is needed two times in the FreeBSD 
> installation once for X11 and once as a system compiler. By using plan9 I can 
> reduce the size of this kiosk application to estimated 300 MB. I gave plan9 a 
> try a few years ago and was fascinated but the licence wasn't attractive at 
> that time. But now it's ideal for such tasks.
> 
> Some sources are part of this installment inside a loop file those are 
> provided internally with a ramfs so in time compilation gets possible. The 
> moment I include GPL licensed code into this ramfs this would infect my own 
> licence. My plattform is BSD 2 claused the students can distribute it freely 
> but the mechanics for connecting to the closed area network are hidden. The 
> MIT licence, zlib, Ogg Vorbis license are compatible with BSD 2 license and 
> require proper acknowlegdement but GPL can't be used in such a manner. 
> 
> Plan9 with its new license is optimal for such applications. I think that 
> plan9 would have been more wide spread if this new license would have been 
> applied from the beginning. And I believe that the reason why NetBSD, 
> OpenBSD, FreeBSD are not as wide spread as Linux was the lack of a compiler 
> suite conforming to the BSD license. Some time ago the BSD project asked for 
> a license change for plan9 to integrate the C compiler which didn't happen at 
> that time. But I'm sure that in the near future their will be some BSD forks 
> which will take more ideas and tools from Plan9 (especially the compiler 
> suite). Plan9 has more advantages besides those - nearly direct access to the 
> hardware and a simplified way to enhancements due to its namespaces and 9fs. 
> 
> I'm using BSD systems since 1991 and I think its important to follow a strict 
> licensing scheme otherwise many years later as it happened in NetBSD, FreeBSD 
> and OpenBSD you start to search for alternative implementations cause at some 
> point your code is not accompanied by incompatible licensed code but is 
> depending on those so it is infected. If you decide to distribute a system 
> with a non infecting open source license than its important to do this in a 
> consistent form. The more time passes the more you depend on parts and the 
> less gets the chance to exchange those parts. 
> 
> I am consequently avoiding infecting licenses in my projects and my 
> distributions for decades now and those parts of plan9 (9front) which are not 
> conforming are not a big deal to throw away. diff, patch are available in 
> conforming licensed versions. I prefer ogg vorbis to mp3 due to its patent 
> problems in the past. There are dozens of truetype fonts with better quality 
> and distributable. The only problematic part not only to plan9 but also all 
> BSD systems is ghostscript but I have an existing translater from postscript 
> to svg and a closed source svg library for rendering for other projects where 
> I would perhaps need page and the dependency to ghostscript. No need for lzip 
> and xen ...
> 
> The reason why this reply was this long is simple :
> 
> My experience from the past a

Re: [9fans] building blocks speaking 9p

[Bakul Shah]

Thanks! Quite an interesting paper. I vaguely recall reading
this a long time ago. 

I think the key will be to figure out how to make this a very
easy to use component. It is not rocket science but will
probably require a few iterations to smooth out any rough
edges and to see what evolves.

Good to see there is interest in the community!

> On Jan 28, 2022, at 11:01 AM, Charles Forsyth  
> wrote:
> 
> https://www.cs.york.ac.uk/rts/static/papers/R:N.C.:Audsley:2006.pdf 
> <https://www.cs.york.ac.uk/rts/static/papers/R:N.C.:Audsley:2006.pdf> might 
> be of interest.
> 
> They turned up at an embedded systems show at Birmingham NEC about that time.
> I was attending independently, but it was interesting to see,.
> Wandering about some boring other stands, I found one that was showing off a 
> small embedded device running a remarkable system.
> There was source code on the screen.
> "Hmm", I asked, "what's the language it's running?"
> Lars Bok [for it was he], proudly, "It is SmallTalk!" in 64k [I think] on a 
> micro with a real-time garbage collector and in-service code updating on the 
> fly.
> Just fantastic. We bemoaned the boring nature of most of the stands. I 
> mentioned Styx-on-a-Chip and he wandered off to have a look, returning to say 
> it was also interesting.
> I forget the name of the system, but eventually the company was sold on or 
> got different investors in, who turned it into a Java thing. As usual.
> 
> On Fri, 28 Jan 2022 at 10:18, Lucio De Re  <mailto:lucio.d...@gmail.com>> wrote:
> On 1/28/22, Bakul Shah mailto:ba...@iitbombay.org>> 
> wrote:
> >
> > Think of really simple, low power, low cost devices.
> > USB can also provide power. USB+ATtiny85 devel boards
> > cost ~$3 even at Amazon. And FPGA boards can be
> > pretty inexpensive too. If you can find them.
> >
> I've recommended olimex.com <http://olimex.com/> in the past. They specialise 
> in Open
> Architecture Hardware. Their prices are very reasonable and product
> range quite broad.
> 
> Lucio.
> 
> --
> 9fans: 9fans
> Permalink: 
> https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-M84956412e025f516e7cd
>  
> <https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-M84956412e025f516e7cd>
> Delivery options: https://9fans.topicbox.com/groups/9fans/subscription 
> <https://9fans.topicbox.com/groups/9fans/subscription>
> 9fans <https://9fans.topicbox.com/latest> / 9fans / see discussions 
> <https://9fans.topicbox.com/groups/9fans> + participants 
> <https://9fans.topicbox.com/groups/9fans/members> + delivery options 
> <https://9fans.topicbox.com/groups/9fans/subscription>Permalink 
> <https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-Mc901f3049ed9f148d9ee00e7>

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-M3c9ced3c7ccb25fd4918537c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] building blocks speaking 9p

[Bakul Shah]

On Jan 27, 2022, at 7:31 PM, Lucio De Re  wrote:
> 
> On 1/28/22, Bakul Shah  wrote:
> 
>> This will probably have to ride on USB first. A verilog
>> implementation would be useful in an FPGA!
>> 
> I never understood why USB receives so much attention (but thanks to
> all those who valiantly tried to tame that wild beast!). What does it
> do that PoE doesn't do infinitely better?

Think of really simple, low power, low cost devices.
USB can also provide power. USB+ATtiny85 devel boards
cost ~$3 even at Amazon. And FPGA boards can be
pretty inexpensive too. If you can find them.

But note these are just preliminary ideas.

>> Would this be a useful component? If such a thing were
>> available, what would you want to build with it?
>> 
> What I would want from such a tool is its availability within
> educational institutions so we stop teaching greed technology to
> learners and lower the knowledge entry bar that Intel and Microsoft -
> and their allies - have created (that, I make no apologies for, is
> Politics, the Politics of Technological Domination).


Let us first build a few before worrying about such things.


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-M7612c07b44c6a417cec5c3ba
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] acme and sam - mouse suggestions?

[Bakul Shah]

Mine says MO09BOA. It has a Lenovo logo
and the scroll thingy is lighted blue.  It is not
a wheel, more like a single axis trackpoint.

> On Jan 27, 2022, at 8:47 PM, Rob Pike  > wrote:
> 
> I have one mouse still in the original unopened box, just to be safe. The 
> label reads
> 
> 31P7405 Lenovo Scrollpoint Mouse Model MO098OA
> 
> And I have now opened it to be sure, and it is the true blue (literally) 
> 3-button version. It is labeled Lenovo, although the ones I use are all 
> labeled IBM.
> 
> -rob
> 
> 
> On Fri, Jan 28, 2022 at 3:44 PM Kurt H Maier via 9fans <9fans@9fans.net 
> > wrote:
> On Thu, Jan 27, 2022 at 08:39:09PM -0800, Kurt H Maier via 9fans wrote:
> > The Scrollpoint Rob mentioned was made
> > with both IBM and Lenovo branding, and was also available in a sculpted
> > Pro model with a thumb-actuated fourth button.
> 
> I should specify:  the Scrollpoint mouse technically only has two
> buttons and a round pointing device in between.  The Scrollpoint II is
> the one Rob describes (with either a blue or red oval pointing stick
> behind a middle mouse button), and it was available in both optical and
> mechanical configurations.  The Scrollpoint Pro ergonomic mouse was also
> available in both optical and mechanical setups; the mechanical version
> is absolutely miserable, but the optical version was great.
> 
> khm
> 
> 
> --
> 9fans: 9fans
> Permalink: 
> https://9fans.topicbox.com/groups/9fans/T49f3cceea70d2b61-M8953d5544698cff773fd66cf
>  
> 
> Delivery options: https://9fans.topicbox.com/groups/9fans/subscription 
> 
> 9fans  / 9fans / see discussions 
>  + participants 
>  + delivery options 
> Permalink 
> 

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T49f3cceea70d2b61-M5eb32bc2fbf0376944cbd7f5
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] building blocks speaking 9p

[Bakul Shah]

The idea:
- make it very easy to create hardware gadgets by
  providing a firmware/hardware building block that
  talks 9p on the host interface side & interfaces
  with device specific hardware.

- use a "universal" 9p driver on the host side that
  allows access to any such 9p device even from a shell.

- provide a standard way to find out device capabilities.

- together they provide a plug-and-play setup.

Example: connect an LED and a current sensor to this
9p device, other necessary hardware, add a few config
bits and plug this device kn]]into a host. Now you should
be able to turn on/off the light or sense its state.

Similarly you should be able to control a stepper motor
servo, cameras, microphones, other actuators, sensors,
IO etc. Eventually you should be able to snap together
enough of these components to build larger assemblies
such as a 3D printer.

Another example: a "hub" to multiplex such downstream
devices and make them available to a host.

This will probably have to ride on USB first. A verilog
implementation would be useful in an FPGA!

Would this be a useful component? If such a thing were
available, what would you want to build with it?

Do you think 9p is the right protocol for this?

Ideally
- connect anything to anything
- authenticated connections
- drive the device through a shell script
- no new low level drivers
- self-identifying devices with help and command syntax
- signicantly eases the task of creating new h/w devices.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-M35165d4278d95e41fd95b8f7
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Boot CD chokes

[Bakul Shah]

On Dec 28, 2021, at 9:35 AM, Duke Normandin  wrote:
> 
> On Tue, 28 Dec 2021 09:28:52 -0800
> Eli Cohen  wrote:
> 
>> if you're not accustomed to plan 9
> 
> Worst than that! I don't know squat about it. Just manage to
> install it 10 minutes ago. I know Unix though and that's where I'm
> getting hung up.

I think there is a webpage somewhere describing the differences
between Unix and Plan9.

You may find https://pspodcasting.net/dan/blog/2019/plan9_desktop.html
useful. The FQA on 9front site is pretty good if you have specific
questions. plan9 man pages are agood but they tend to be concise.
You have to read carefully.

One suggestion: as you read a manpage, try out the command and its 
options and try to figure out what happens. Check the man page in
the "See Also" section. If you screw something up, in the worst,
but not very likely, case you may have to reinstall (and that is
not a big deal in plan9).

One more suggestion: *write* down your experience as you encounter
issues and solve them. Write down things that may have helped you.
And publish it or at least stick it on github to help the next person!


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T5888591114a7cf34-M246346f6f2af65729e995db1
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] v9fs vs mmap (not quite SOLVED)

[Bakul Shah]

On Oct 27, 2021, at 3:55 AM, Richard Miller <9f...@hamnavoe.com> wrote:
>> Skip, did you specify -o cache=mmap when mounting diod service
>> for the go build experiment?
> 
> I tried it myself using local diod and cache=mmap. I get a similar
> SIGBUS on instruction fetch again. Conclusion: as Bakul says, now
> I'm debugging linux. Not going there, thanks.

Looks like you are going there? :-)

> Going further off-topic for 9fans, sorry:
> 
> I thought it would be clever to update the linux client to a newer
> kernel (4.19 was the latest I could find for debian 9). That
> didn't go well: booting the new kernel fails with the message
>  Failed to find cpu0 device node
> 
> Does anyone know if it's feasible to do an out-of-tree build
> of v9fs kernel modules (9p, 9pnet?) from current source [where
> is it?] and use them with my old 4.9 kernel?

May be this will help?
https://itnext.io/a-standalone-linux-kernel-module-df54283d4803

Though may you first want to start looking at the output of
git log github.com/torvalds/linux/fs/9p/vfs_file.c
grep for mmap related changes and check the code around changes
to see if you can spot the bug. The last mmap mention in the log
makes me wonder whether you see a difference in a 32 bit wordsize
machine vs 64 bit. May also be worth just talking to the folks
who worked on this feature.

A long time ago I wrote an mmap example C program that works on
anonymous maps (just steps through memory given some stride and
allocates memory in the signal handler on page faults). Something
similar can be written to access an mmapped file and tweaked
until your bug appears. Currently my program compiles on freebsd
but not linux (ubuntu). I will see if I can make it work.


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tb065f4df67a8bab9-M30a0d7f933429868ec22fdd7
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Getting to my dos USB drive on plan9 VMWARE (Windows 10)

[Bakul Shah]

On Sep 13, 2021, at 4:02 AM, revcomni...@gmail.com wrote:
> 
> I have succeeded in installing plan9 on qemu but so far have not had any 
> success in getting via plan9 to the USB fat drive that contains my data. If I 
> go into /dev/ I cannot see the device listed there. Any ideas would be 
> appreciated.

https://unix.stackexchange.com/questions/452934/can-i-pass-through-a-usb-port-via-qemu-command-line

-- Bakul


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tddd6ef89c1e17f3a-Mc4b42b653cb050e06a73c025
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Drawterm GPU (was: Software philosophy)

[Bakul Shah]

Don't high end GPUs have thousands of "cores"? Even high end CPUs don't have 
more than a few dozen cores to 128 or so. While each kind's cores are very 
different, seems to me GPU/CPU paths have diverged for good. Or we need some 
massive shift in programming languages + compilers. I lack imagination how. 
Still, the thought of the CPUs gaining the complexity of the graphics engine 
scares me!

-- Bakul

> On Aug 22, 2021, at 12:09 PM, Paul Lalonde  wrote:
> 
> I'm pretty sure we're still re-inventing, though it's the CPU's turn to gain 
> some of the complexity of the graphics engine.
> 
> Paul
> 
> On Sun, Aug 22, 2021, 12:05 PM Bakul Shah  <mailto:ba...@iitbombay.org>> wrote:
> Thanks. Looks like Sutherland's "Wheel of Reincarnation 
> <https://www2.cs.arizona.edu/~cscheid/reading/myer-sutherland-design-of-display-processors.pdf>"
>  has not only stopped but exploded :-) Or stopped being applicable.
> 
> -- Bakul
> 
>> On Aug 22, 2021, at 9:23 AM, Paul Lalonde > <mailto:paul.a.lalo...@gmail.com>> wrote:
>> 
>> It got complicated because there's no stable interface or ISA.  The hardware 
>> evolved from fixed-function to programmable in a commercial environment 
>> where the only meaningful measure was raw performance per dollar at many 
>> price points.  Every year the hardware spins and becomes more performant, 
>> usually faster than Moore's law.  With 3D APIs hiding the hardware details 
>> there is no pressure to make the hardware interface uniform, pretty, or 
>> neat.  And with the need for performance there are dozens of fixed function 
>> units that effectively need their own sub-drivers while coordinating at high 
>> performance with the other units. 
>> The system diagrams for GPUs look complex, but they are radical 
>> simplifications of what's really on the inside.
>> 
>> Intel really pioneered the open driver stacks, but performance generally 
>> wasn't there.  That might be changing now, but I don't know if their 
>> recently announced discrete product line will be driver-compatible.
>> 
>> Paul
>> 
>> 
>> On Sun, Aug 22, 2021 at 8:48 AM Bakul Shah > <mailto:ba...@iitbombay.org>> wrote:
>> The FreeBSD amdgpu.ko is over 3Mbytes of compiled code. Not counting the 
>> "firmware" that gets loaded on the GPU board. drm/amd/amdgpu has 200K+ lines 
>> of source code. drm/amd over 2M lines of code. Intel's i915 seems to be 
>> about 1/10th the amd size. AIUI, this is linux GPU driver code, more or less 
>> unchanged (FreeBSD has shim code to use it). How did the interface to an 
>> SIMD processor get so complicated?
>> 
>>> On Aug 22, 2021, at 6:44 AM, Paul Lalonde >> <mailto:paul.a.lalo...@gmail.com>> wrote:
>>> 
>>> I'd love to see  GPU support for Plan9.  This discussion falls right into 
>>> my professional capacity.  I'll say that people generally *grossly* 
>>> underestimate the complexity of a modern GPU and of its supporting software 
>>> stack.  The GPU driver is effectively a second operating system with shared 
>>> memory and DMA interfaces to the host.  Even bringing up a modern GPU for 
>>> just compute tasks is a very large endeavour.
>>> 
>>> That being said, if you want real hardware support, the best place to start 
>>> is currently AMD's open-source stack.  Ignoring the Vulkan bit, 
>>> understanding their platform abstraction layer (PAL) and shader ISA 
>>> (https://developer.amd.com/wp-content/resources/Vega_Shader_ISA_28July2017.pdf
>>>  
>>> <https://developer.amd.com/wp-content/resources/Vega_Shader_ISA_28July2017.pdf>)
>>>  is the base.  The lower hardware levels are reasonably well-described in 
>>> linux's libdrm and its AMD support in amdgpu.
>>> 
>>> Opinions on how to bring this to Plan9?  I don't really have any - it's a 
>>> huge pile of work with minimal benefit.  If you're looking for lightweight 
>>> graphics, WebGL is a doable path, and almost certainly the right way to 
>>> experiment with Plan9-like interfaces to graphics hardware.
>>> 
>>> Paul
>>> 
>>> 
>>> 
>>> On Sun, Aug 22, 2021 at 5:30 AM sirjofri >> <mailto:sirjofri%2bml-9f...@sirjofri.de>> wrote:
>>> 
>>> 22.08.2021 14:10:20 Stuart Morrow >> <mailto:morrow.stu...@gmail.com>>:
>>> > Also:
>>> >> people have discussed that for years
>>> >
>>> > They ha

Re: [9fans] Drawterm GPU (was: Software philosophy)

[Bakul Shah]

Thanks. Looks like Sutherland's "Wheel of Reincarnation 
<https://www2.cs.arizona.edu/~cscheid/reading/myer-sutherland-design-of-display-processors.pdf>"
 has not only stopped but exploded :-) Or stopped being applicable.

-- Bakul

> On Aug 22, 2021, at 9:23 AM, Paul Lalonde  wrote:
> 
> It got complicated because there's no stable interface or ISA.  The hardware 
> evolved from fixed-function to programmable in a commercial environment where 
> the only meaningful measure was raw performance per dollar at many price 
> points.  Every year the hardware spins and becomes more performant, usually 
> faster than Moore's law.  With 3D APIs hiding the hardware details there is 
> no pressure to make the hardware interface uniform, pretty, or neat.  And 
> with the need for performance there are dozens of fixed function units that 
> effectively need their own sub-drivers while coordinating at high performance 
> with the other units. 
> The system diagrams for GPUs look complex, but they are radical 
> simplifications of what's really on the inside.
> 
> Intel really pioneered the open driver stacks, but performance generally 
> wasn't there.  That might be changing now, but I don't know if their recently 
> announced discrete product line will be driver-compatible.
> 
> Paul
> 
> 
> On Sun, Aug 22, 2021 at 8:48 AM Bakul Shah  <mailto:ba...@iitbombay.org>> wrote:
> The FreeBSD amdgpu.ko is over 3Mbytes of compiled code. Not counting the 
> "firmware" that gets loaded on the GPU board. drm/amd/amdgpu has 200K+ lines 
> of source code. drm/amd over 2M lines of code. Intel's i915 seems to be about 
> 1/10th the amd size. AIUI, this is linux GPU driver code, more or less 
> unchanged (FreeBSD has shim code to use it). How did the interface to an SIMD 
> processor get so complicated?
> 
>> On Aug 22, 2021, at 6:44 AM, Paul Lalonde > <mailto:paul.a.lalo...@gmail.com>> wrote:
>> 
>> I'd love to see  GPU support for Plan9.  This discussion falls right into my 
>> professional capacity.  I'll say that people generally *grossly* 
>> underestimate the complexity of a modern GPU and of its supporting software 
>> stack.  The GPU driver is effectively a second operating system with shared 
>> memory and DMA interfaces to the host.  Even bringing up a modern GPU for 
>> just compute tasks is a very large endeavour.
>> 
>> That being said, if you want real hardware support, the best place to start 
>> is currently AMD's open-source stack.  Ignoring the Vulkan bit, 
>> understanding their platform abstraction layer (PAL) and shader ISA 
>> (https://developer.amd.com/wp-content/resources/Vega_Shader_ISA_28July2017.pdf
>>  
>> <https://developer.amd.com/wp-content/resources/Vega_Shader_ISA_28July2017.pdf>)
>>  is the base.  The lower hardware levels are reasonably well-described in 
>> linux's libdrm and its AMD support in amdgpu.
>> 
>> Opinions on how to bring this to Plan9?  I don't really have any - it's a 
>> huge pile of work with minimal benefit.  If you're looking for lightweight 
>> graphics, WebGL is a doable path, and almost certainly the right way to 
>> experiment with Plan9-like interfaces to graphics hardware.
>> 
>> Paul
>> 
>> 
>> 
>> On Sun, Aug 22, 2021 at 5:30 AM sirjofri > <mailto:sirjofri%2bml-9f...@sirjofri.de>> wrote:
>> 
>> 22.08.2021 14:10:20 Stuart Morrow > <mailto:morrow.stu...@gmail.com>>:
>> > Also:
>> >> people have discussed that for years
>> >
>> > They have?  I mean I might have seen occasionally someone vaguely
>> > going "some sort of GPU support would be cool to have".  That isn't
>> > discussion.
>> 
>> I've even heard of someone actually making GPU stuff work on plan 9. I've 
>> only heard from their partner, who made a cute glenda thing on a piece of 
>> cloth. I chatted with her a little and told her she should encourage her 
>> partner for some discussion about this in our channels. It looked like 
>> it's some academic work, but I don't know any details about it.
>> 
>> Worst case, someone already has a proper and good GPU implementation for 
>> Plan 9 and nobody knows about it.
>> 
>> sirjofri
>> 
>> Btw if the said person reads this: it would be nice to learn some 
>> details.
>> 
>> --
>> 9fans: 9fans
>> Permalink: 
>> https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-Md3d5cd693c1

Re: [9fans] Drawterm GPU (was: Software philosophy)

[Bakul Shah]

The FreeBSD amdgpu.ko is over 3Mbytes of compiled code. Not counting the 
"firmware" that gets loaded on the GPU board. drm/amd/amdgpu has 200K+ lines of 
source code. drm/amd over 2M lines of code. Intel's i915 seems to be about 
1/10th the amd size. AIUI, this is linux GPU driver code, more or less 
unchanged (FreeBSD has shim code to use it). How did the interface to an SIMD 
processor get so complicated?

> On Aug 22, 2021, at 6:44 AM, Paul Lalonde  > wrote:
> 
> I'd love to see  GPU support for Plan9.  This discussion falls right into my 
> professional capacity.  I'll say that people generally *grossly* 
> underestimate the complexity of a modern GPU and of its supporting software 
> stack.  The GPU driver is effectively a second operating system with shared 
> memory and DMA interfaces to the host.  Even bringing up a modern GPU for 
> just compute tasks is a very large endeavour.
> 
> That being said, if you want real hardware support, the best place to start 
> is currently AMD's open-source stack.  Ignoring the Vulkan bit, understanding 
> their platform abstraction layer (PAL) and shader ISA 
> (https://developer.amd.com/wp-content/resources/Vega_Shader_ISA_28July2017.pdf
>  
> )
>  is the base.  The lower hardware levels are reasonably well-described in 
> linux's libdrm and its AMD support in amdgpu.
> 
> Opinions on how to bring this to Plan9?  I don't really have any - it's a 
> huge pile of work with minimal benefit.  If you're looking for lightweight 
> graphics, WebGL is a doable path, and almost certainly the right way to 
> experiment with Plan9-like interfaces to graphics hardware.
> 
> Paul
> 
> 
> 
> On Sun, Aug 22, 2021 at 5:30 AM sirjofri  > wrote:
> 
> 22.08.2021 14:10:20 Stuart Morrow  >:
> > Also:
> >> people have discussed that for years
> >
> > They have?  I mean I might have seen occasionally someone vaguely
> > going "some sort of GPU support would be cool to have".  That isn't
> > discussion.
> 
> I've even heard of someone actually making GPU stuff work on plan 9. I've 
> only heard from their partner, who made a cute glenda thing on a piece of 
> cloth. I chatted with her a little and told her she should encourage her 
> partner for some discussion about this in our channels. It looked like 
> it's some academic work, but I don't know any details about it.
> 
> Worst case, someone already has a proper and good GPU implementation for 
> Plan 9 and nobody knows about it.
> 
> sirjofri
> 
> Btw if the said person reads this: it would be nice to learn some 
> details.
> 
> --
> 9fans: 9fans
> Permalink: 
> https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-Md3d5cd693c12f948ad4720bc
>  
> 
> Delivery options: https://9fans.topicbox.com/groups/9fans/subscription 
> 
> 9fans  / 9fans / see discussions 
>  + participants 
>  + delivery options 
> Permalink 
> 


-- Bakul


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-M8658a330dbb6ca9a6e216777
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] amd64 bootstrap file fo go1.16.3

[Bakul Shah]

On Apr 21, 2021, at 2:41 AM, Richard Miller <9f...@hamnavoe.com> wrote:
> 
> 
>> go tool dist: Failed: exit status: 'go 6839: 1'
>> all.rc 165: go 6566: 1
>> ===to here==
>> It took about half a day to accomplish!
> 
> Some things that can make go tools and test suite quicker:
> - use ramfs for /tmp
> - use a local file server, with local disk or aoe on a fast connection
> - make sure you have lots of RAM, or swap to a local disk

I saw a lot of failures in go’s own test suite run via all.rc. This was
on 9front/amd64 under the bhyve hypervisor on freebsd. I gave
the VM 4GB and two cores so resource constraint should not be an
issue. Is there a list of known to fail tests? Thanks.
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T75ee4ccd407669dd-Mf8ae307dfd776ec0fe3cbed2
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Transfer of Plan 9 to the Plan 9 Foundation

[Bakul Shah]

Are you suggesting either getting an explicit permission from the authors or 
excising such code included in plan9?

I assume any code  in contrib/ has its author’s copyright unless there is an 
explicit copyright.

> On Mar 31, 2021, at 9:29 AM, Anonymous AWK fan via 9fans <9fans@9fans.net> 
> wrote:
> 
> The issue is that there is some code in Plan 9 not written at Bell Labs which
> doesn't explicitly specify any license.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tf20bce89ef96d4b6-M5ef85911378e86bc8561f1e9
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Transfer of Plan 9 to the Plan 9 Foundation

[Bakul Shah]

On Mar 23, 2021, at 6:06 AM, a...@9srv.net wrote:
> 
> We are thrilled to announce that Nokia has transferred the copyright of
> Plan 9 to the Plan 9 Foundation. This transfer applies to all of the
> Plan 9 from Bell Labs code, from the earliest days through their final
> release.
> 
> The most exciting immediate effect of this is that the Plan 9 Foundation
> is making the historical 1st through 4th editions of Plan 9 available
> under the terms of the MIT license. These are the releases as they
> existed at the time, with minimal changes to reflect the above.

Congratulations and many thanks to all involved for making this happen!

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tf20bce89ef96d4b6-M7a1a2f5ebccb9a3a6f538eeb
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] No signal on some monitors with Raspberry Pi 400

[Bakul Shah]

On Mar 10, 2021, at 8:53 AM, Richard Miller <9f...@hamnavoe.com> wrote:
>> That is, if I plug into a ~10 year old Vizio television
>> everything works fine at a reasonable resolution (1280x1024?  I haven't yet 
>> figured
>> out which utility to use to query display properties)
> 
> Here's a simple way:
> 
> term% echo `{dd -if /dev/screen -bs 64 -count 1}
> 
>> , but if I plug it into a Dell
>> S2817Q the monitor says "No signal detected."
> 
> That's a 4k monitor, I think. The native resolution is probably too big
> to fit in the virtual area allowed for the kernel frame buffer. (Lack of
> foresight - monitors were smaller when 9pi was first done.)
> 
> I'll see about fixing that soon. Meanwhile, you should be able to use
> hdmi_group and hdmi_mode settings in config.txt to request a lower resolution.
> Or add something like "vgasize=1600x1200x16" to the command line in 
> cmdline.txt -
> either method should work.

Not sure how things are different in pi4+pi9 but I was able to get 4K@20Hz
under plan9 back in 2014 on the original pi. Not sure I can find that
SDcard now but the settings were based on what I gleaned from this thread: 
https://www.raspberrypi.org/forums/viewtopic.php?t=79330
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T295835c4cafb6d4f-M855b50cfb52355dd9a906ae2
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] APL

[Bakul Shah]

> On Feb 22, 2021, at 8:41 PM, o...@eigenstate.org wrote:
> 
> Quoth Lyndon Nerenberg (VE7TFX/VE6BBM) :
>> Steffen Nurpmeso writes:
>> 
>>> It can even be as small as 
>>> 
>>>  #?0|kent:unix-hist$ du -sh .
>>>  179M.
>>> 
>>> when not including all the new FreeBSD things (for which i at
>>> least track the FreeBSD git repository directly):
>> 
>> Okay, so what's the magic incantation to clone just that subset
>> of branches?  git-clone(1) is not helpful ...
>> 
>> --lyndon
> 
> On unix, this should do it:
> 
>git clone --single-branch \
>--branch Research-V4-Snapshot-Development \
>https://github.com/dspinellis/unix-history-repo
> 
> On plan 9, hot off the press:
> 
>git/clone -b $branch \
>https://github.com/dspinellis/unix-history-repo
> 
> Unfortunately, git9 has no fetch specs, so keeping a
> *set* of branches will be a bit clunky

For multiple branches try something like the following:

git clone https://github.com/dspinellis/unix-history-repo.git --depth 1 -b Epoch

Without the --depth 1 flag git insists on fetching all 1.9GB of git objects!
But +fetch= lines in .git/config's are not fixed up. As these branches are not
likely to change, that is probably ok.

Next run the following, editing out the branches you don't want.
This list is everything except FreeBSD branches. Amounts to 188MB.

git fetch origin 
386BSD-0.0-Snapshot-Development:386BSD-0.0-Snapshot-Development\
 386BSD-0.1-Snapshot-Development:386BSD-0.1-Snapshot-Development\
 386BSD-0.1-patchkit:386BSD-0.1-patchkit\
 386BSD-0.1-patchkit-Import:386BSD-0.1-patchkit-Import\
 386BSD-Release:386BSD-Release\
 BSD-1-Snapshot-Development:BSD-1-Snapshot-Development\
 BSD-2-Snapshot-Development:BSD-2-Snapshot-Development\
 BSD-3-Snapshot-Development:BSD-3-Snapshot-Development\
 BSD-4-Snapshot-Development:BSD-4-Snapshot-Development\
 BSD-4_1_snap-Snapshot-Development:BSD-4_1_snap-Snapshot-Development\
 BSD-4_1c_2-Snapshot-Development:BSD-4_1c_2-Snapshot-Development\
 BSD-4_2-Snapshot-Development:BSD-4_2-Snapshot-Development\
 BSD-4_3-Snapshot-Development:BSD-4_3-Snapshot-Development\
 BSD-4_3_Net_1-Snapshot-Development:BSD-4_3_Net_1-Snapshot-Development\
 BSD-4_3_Net_2-Snapshot-Development:BSD-4_3_Net_2-Snapshot-Development\
 BSD-4_3_Reno-Snapshot-Development:BSD-4_3_Reno-Snapshot-Development\
 BSD-4_3_Tahoe-Snapshot-Development:BSD-4_3_Tahoe-Snapshot-Development\
 BSD-4_4-Snapshot-Development:BSD-4_4-Snapshot-Development\
 BSD-4_4_Lite1-Snapshot-Development:BSD-4_4_Lite1-Snapshot-Development\
 BSD-4_4_Lite2-Snapshot-Development:BSD-4_4_Lite2-Snapshot-Development\
 BSD-Release:BSD-Release BSD-SCCS:BSD-SCCS\
 Bell-32V-Snapshot-Development:Bell-32V-Snapshot-Development\
 Bell-Release:Bell-Release 
Research-PDP7-Snapshot-Development:Research-PDP7-Snapshot-Development\
 Research-Release:Research-Release\
 Research-V1-Snapshot-Development:Research-V1-Snapshot-Development\
 Research-V2-Snapshot-Development:Research-V2-Snapshot-Development\
 Research-V3-Snapshot-Development:Research-V3-Snapshot-Development\
 Research-V4-Snapshot-Development:Research-V4-Snapshot-Development\
 Research-V5-Snapshot-Development:Research-V5-Snapshot-Development\
 Research-V6-Snapshot-Development:Research-V6-Snapshot-Development\
 Research-V7-Snapshot-Development:Research-V7-Snapshot-Development\
 usr/src/BSD-SCCS-Import:usr/src/BSD-SCCS-Import
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T476a1d7b83269775-M164190580e3d2b269501e9f0
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] APL

[Bakul Shah]

Clearly someone ran lint on the ucb code :-) Both have the iline variable
(char* on Cain's version, unsigned char* in ucb).

> On Feb 22, 2021, at 3:56 PM, Charles Forsyth  
> wrote:
> 
> It's more interesting that one is immediate by inspection. But why?
> 
> On Mon, Feb 22, 2021 at 11:10 PM Bakul Shah  <mailto:ba...@iitbombay.org>> wrote:
> Spinellis has put together a browsable repo based on various source 
> distributions
> which I find useful. I keep a local copy as it is under 2GB. All I had to do 
> was 
> 
> git log | less -ip "ross harvey"
> 
> Michael Cain's version on sigapl.org <http://sigapl.org/> site seems to be a 
> different fork. Also worked
> over quite a bit.
> 
>> On Feb 22, 2021, at 2:43 PM, Charles Forsyth > <mailto:charles.fors...@gmail.com>> wrote:
>> 
>> It's amusing that the github has "42 years ago".
>> 
>> You can tell instantly that the line
>>  if (TERMtype == 0)c = (int)*iline++;
>> wasn't written by Thompson.
>> 
>> On Mon, Feb 22, 2021 at 10:02 PM Bakul Shah > <mailto:ba...@iitbombay.org>> wrote:
>> On Feb 22, 2021, at 10:28 AM, tlaro...@polynum.com 
>> <mailto:tlaro...@polynum.com> wrote:
>> > 
>> > There are various versions of an APL interpreter and, amongst these,
>> > a version by Ken Thompson, Ross Harvey, Douglas Lanam.
>> 
>> This can be found in Diomidis Spinellis' unix history repo @
>> 
>> https://github.com/dspinellis/unix-history-repo/tree/BSD-3/usr/src/cmd/apl 
>> <https://github.com/dspinellis/unix-history-repo/tree/BSD-3/usr/src/cmd/apl>
>> 
>> Synthesized from 3bsd, which you can find it here:
>> 
>> https://www.tuhs.org/Archive/Distributions/UCB/3bsd.tar.gz 
>> <https://www.tuhs.org/Archive/Distributions/UCB/3bsd.tar.gz>
>> 
>> --
>> 9fans: 9fans
>> Permalink: 
>> https://9fans.topicbox.com/groups/9fans/T476a1d7b83269775-M6b93af6ab332e6cbfb8ca7c7
>>  
>> <https://9fans.topicbox.com/groups/9fans/T476a1d7b83269775-M6b93af6ab332e6cbfb8ca7c7>
>> Delivery options: https://9fans.topicbox.com/groups/9fans/subscription 
>> <https://9fans.topicbox.com/groups/9fans/subscription>
> 
> 9fans <https://9fans.topicbox.com/latest> / 9fans / see discussions 
> <https://9fans.topicbox.com/groups/9fans> + participants 
> <https://9fans.topicbox.com/groups/9fans/members> + delivery options 
> <https://9fans.topicbox.com/groups/9fans/subscription>Permalink 
> <https://9fans.topicbox.com/groups/9fans/T476a1d7b83269775-Ma78673da48df4053820043fa>

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T476a1d7b83269775-M908b018371372b7d51ca53bb
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] APL

[Bakul Shah]

Spinellis has put together a browsable repo based on various source 
distributions
which I find useful. I keep a local copy as it is under 2GB. All I had to do 
was 

git log | less -ip "ross harvey"

Michael Cain's version on sigapl.org site seems to be a different fork. Also 
worked
over quite a bit.

> On Feb 22, 2021, at 2:43 PM, Charles Forsyth  
> wrote:
> 
> It's amusing that the github has "42 years ago".
> 
> You can tell instantly that the line
>   if (TERMtype == 0)c = (int)*iline++;
> wasn't written by Thompson.
> 
> On Mon, Feb 22, 2021 at 10:02 PM Bakul Shah  <mailto:ba...@iitbombay.org>> wrote:
> On Feb 22, 2021, at 10:28 AM, tlaro...@polynum.com 
> <mailto:tlaro...@polynum.com> wrote:
> > 
> > There are various versions of an APL interpreter and, amongst these,
> > a version by Ken Thompson, Ross Harvey, Douglas Lanam.
> 
> This can be found in Diomidis Spinellis' unix history repo @
> 
> https://github.com/dspinellis/unix-history-repo/tree/BSD-3/usr/src/cmd/apl 
> <https://github.com/dspinellis/unix-history-repo/tree/BSD-3/usr/src/cmd/apl>
> 
> Synthesized from 3bsd, which you can find it here:
> 
> https://www.tuhs.org/Archive/Distributions/UCB/3bsd.tar.gz 
> <https://www.tuhs.org/Archive/Distributions/UCB/3bsd.tar.gz>
> 
> --
> 9fans: 9fans
> Permalink: 
> https://9fans.topicbox.com/groups/9fans/T476a1d7b83269775-M6b93af6ab332e6cbfb8ca7c7
>  
> <https://9fans.topicbox.com/groups/9fans/T476a1d7b83269775-M6b93af6ab332e6cbfb8ca7c7>
> Delivery options: https://9fans.topicbox.com/groups/9fans/subscription 
> <https://9fans.topicbox.com/groups/9fans/subscription>
> 9fans <https://9fans.topicbox.com/latest> / 9fans / see discussions 
> <https://9fans.topicbox.com/groups/9fans> + participants 
> <https://9fans.topicbox.com/groups/9fans/members> + delivery options 
> <https://9fans.topicbox.com/groups/9fans/subscription>Permalink 
> <https://9fans.topicbox.com/groups/9fans/T476a1d7b83269775-Mae4997e3e15481dbbab01024>

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T476a1d7b83269775-M281c649ebf07b0d790f318f5
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] APL

[Bakul Shah]

On Feb 22, 2021, at 10:28 AM, tlaro...@polynum.com wrote:
> 
> There are various versions of an APL interpreter and, amongst these,
> a version by Ken Thompson, Ross Harvey, Douglas Lanam.

This can be found in Diomidis Spinellis' unix history repo @

https://github.com/dspinellis/unix-history-repo/tree/BSD-3/usr/src/cmd/apl

Synthesized from 3bsd, which you can find it here:

https://www.tuhs.org/Archive/Distributions/UCB/3bsd.tar.gz

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T476a1d7b83269775-M6b93af6ab332e6cbfb8ca7c7
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] APL

[Bakul Shah]

On Feb 21, 2021, at 2:33 PM, Lyndon Nerenberg (VE7TFX/VE6BBM) 
 wrote:
> I would really like to have a native APL (even an ancient one like above).

Not quite what you asked for but ktye’s APL seems promising. Written in Go,
uses unicode APL characters, etc. 

https://github.com/ktye/iv
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T476a1d7b83269775-M5235bd6a10294f6240eca7bb
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Whats the default font in Acme?

[Bakul Shah]

On Feb 18, 2021, at 10:32 PM, Mark van Atten  wrote:
> 
> On Thu, 18 Feb 2021 at 10:04, Skip Tavakkolian
>  wrote:
>> 
>> Plan9port has fontsrv. Any truetype you have on your system is usable.
>> man fontsrv for details.
> 
> On my system (Arch 5.10.16) using fontsrv introduces 2-3 second delays
> whenever a program needs to know about the font,
> e.g. when opening acme the window first turns all black and then all
> white before the columns appear; similarly, lc always takes about
> 2 seconds before the listing appears.
> 
> Do others observe this, too?

Even running acme on a FreeBSD host & displaying it on a MBP screen
there was no perceptible delay. May be you have a slow disk? You can
do "strace -r fontsrv" to see where time is being spent.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Td0ab6c3112c95493-M8dcd2309bc3456de4dce079c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Whats the default font in Acme?

[Bakul Shah]

On Feb 19, 2021, at 7:47 PM, Bakul Shah  wrote:
> 
> On Feb 19, 2021, at 4:58 PM, cigar562hfsp952f...@icebubble.org wrote:
>> 
>> Skip Tavakkolian  writes:
>> 
>>> Plan9port has fontsrv. Any truetype you have on your system is usable.
>>> man fontsrv for details.
>> 
>> Unfortunately, man fontsrv doesn't provide the details.  More
>> specifically, it doesn't describe how to configure fontsrv.  On my
>> system:
>> 
>> $ fontsrv &
>> $ 9p ls font
>> $ 
>> 
>> Nothing shows up.
> 
> Works fine on my macbook pro.
> 
> $ 9p ls font | wc
> 822 822   15179
> 
> Note this from the fontsrv man page:
> 
>   Fontsrv has no support for X11 fonts; on X11 systems, it
>   will serve an empty top-level directory.

I just tried fontsrv on FreeBSD system and it certainly finds .ttf
format fonts installed on the system.


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Td0ab6c3112c95493-Ma88797ac18075c7d47ed409c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Whats the default font in Acme?

[Bakul Shah]

On Feb 19, 2021, at 4:58 PM, cigar562hfsp952f...@icebubble.org wrote:
> 
> Skip Tavakkolian  writes:
> 
>> Plan9port has fontsrv. Any truetype you have on your system is usable.
>> man fontsrv for details.
> 
> Unfortunately, man fontsrv doesn't provide the details.  More
> specifically, it doesn't describe how to configure fontsrv.  On my
> system:
> 
> $ fontsrv &
> $ 9p ls font
> $ 
> 
> Nothing shows up.

Works fine on my macbook pro.

$ 9p ls font | wc
 822 822   15179

Note this from the fontsrv man page:

Fontsrv has no support for X11 fonts; on X11 systems, it
will serve an empty top-level directory.



--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Td0ab6c3112c95493-M0e834b3d42b50eab4bb3d12c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Plan 9 Applying to GSoC 2021

[Bakul Shah]

 On Jan 31, 2021, at 4:36 PM, ~vidak  wrote:
> 
> There are various languages we were thinking of doing the implementation
> in, ultimately some flavour of scheme. Perhaps one that could compile to
> C.

There is Nils Holm’s s9fes Scheme. It is strictly an interpreter but easy to 
extend
with C code. See https://github.com/bakul/s9fes. I had added some support for
plan9 specific syscalls — more may be needed depending on what you want to do.

Chibi-Scheme supposedly works on plan9 though I haven’t played with it in years.

I imagine by socialFS you want to see your connections, posts, feeds, likes etc.
as files or directories? Everything but the actual content display? Sounds like 
a
fun project!
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T00b3dc89a8df295a-Maa171945b0f52c8946a6d2ff
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Definitinon list of the # filesystems

[Bakul Shah]

On Jan 21, 2021, at 11:10 PM, Dworkin Muller  wrote:
> 
> On Thu, 21 Jan 2021 23:51:24 -0700, Don Bailey  wrote:
> don.bailey> Grep the source code not the man pages :>
> 
> Well, yes, but I was hoping for something a little less tedious than
> wading through 137,124 hits for `#'.  Removing `#include' admittedly
> brings that down to 109,636, but that's still a bit on the heavy side.

Try something like this:

cd /sys/src/9
awk '/^Dev /,/,/'  */*.c
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tc21478a4dc8e2df1-Mdef3db0e100b3dfb6c5cfdd5
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Plan9 on Raspberry Pi 400?

[Bakul Shah]

I believe all it takes is the presence of recover.bin file on the dos partition.
You still need an updated eeprom image for it to flash the real eeprom with
 but preparing this image doesn't require any h/w access. Unless things
have changed in the last year.

> On Jan 16, 2021, at 1:24 PM, Skip Tavakkolian  
> wrote:
> 
> regarding /dev/serial, this should be helpful for anyone wanting to set up 
> netboot.
> 
> If you have a number of RPI's that netboot, the way that the common 
> config.txt is segmented for each board is by using the '[serial number in 
> hex]' section headers. Unfortunately, netboot also requires changing the 
> BOOT_ORDER parameter in EEPROM, which requires access to /dev/mmcblk* and 
> some way of generating the proper .bin format. So Linux is still needed for 
> the initial setup.
> 
> On Sat, Jan 16, 2021 at 9:13 AM Richard Miller <9f...@hamnavoe.com 
> > wrote:
> > I didn't realise the 9pi image was not up to date.
> > I'll put a new one on 9p.io  today.
> 
> I've done that. Sorry for letting it get out of sync with the kernel source.
> 
> The new contrib/miller/9pi.img.gz has
> - the latest firmware files from the raspberry pi github
> - the update to initialise xhci firmware for pi400 and recent pi4 boards
> - a tweak to the pi4 gigabit ethernet driver to allow jumbo packets
> - a new /dev/serial device from which you can read the board serial number (I 
> forget why)
> 
> Nothing outside the kernel has changed from the previous image.
> 
> 
> 
> 
> --
> 9fans: 9fans
> Permalink: 
> https://9fans.topicbox.com/groups/9fans/Tfcf12cca3a14dc8a-M6d02f52b317dd7989854d801
>  
> 
> Delivery options: https://9fans.topicbox.com/groups/9fans/subscription 
> 
> 9fans  / 9fans / see discussions 
>  + participants 
>  + delivery options 
> Permalink 
> 

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tfcf12cca3a14dc8a-M4df905923fb217a0834ea1f0
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Plan9 on Raspberry Pi 400?

[Bakul Shah]

USB boot is supposed to work on pi400 as well so I thought there would be no 
need for any firmware loading

> On Jan 15, 2021, at 2:52 PM, Michael Engel  wrote:
> 
> I assume loading the firmware via Linux first won't help since a PCIe reset 
> probably also 
> resets the USB controller.
> 
> However, I just checked Richard's kernel source and it seems the firmware 
> loading functionality
> is already included, there is a call to
> 
>xhcireset(BUSBNO(hp->tbdf)<<20 | BUSDNO(hp->tbdf)<<15 | 
> BUSFNO(hp->tbdf)<<12);
> 
> in http://9p.io/sources/contrib/miller/9/bcm/usbxhci.c 
> <http://9p.io/sources/contrib/miller/9/bcm/usbxhci.c>
> 
> The comment for xhcireset in 
> http://9p.io/sources/contrib/miller/9/bcm/vcore.c 
> <http://9p.io/sources/contrib/miller/9/bcm/vcore.c> confirms this:
> /*
> * Notify gpu that xhci firmware might need loading. This is for some
> * pi4 board versions which are missing the eeprom chip for the vl805,
> * requiring its firmware to come from the boot eeprom instead.
> */
> 
> It seems that this source code is more recent than the images for the SD card 
> and kernel in 
> http://9p.io/sources/contrib/miller/ <http://9p.io/sources/contrib/miller/> - 
> I'll try building a kernel based on the updated sources.
> 
> - Michael
> 
> 
>> On 15 Jan 2021, at 23:32, Bakul Shah  wrote:
>> 
>> Can you netboot Linux followed by netbooting Paln9 and have a working USB?
>> 
>>> On Jan 15, 2021, at 1:17 PM, Michael Engel  wrote:
>>> 
>>> Hi,
>>> 
>>> I didn't test Plan 9 on my RPi 400 so far, but I think the reason for the 
>>> USB problems 
>>> is the following:
>>> 
>>> The Raspberry Pi 400 (along with the Compute Module 4 and the 8 GB RAM 
>>> version 
>>> of the RPI4) uses a new stepping C0 of the BCM2711. This version does not 
>>> have a 
>>> dedicated EEPROM for the firmware of the xHCI USB controller and needs an 
>>> additional property mailbox call for loading the xHCI firmware after PCIe 
>>> reset. 
>>> 
>>> Some code to load the firmware can be found in the circle bare-metal 
>>> library (l. 88ff):
>>> https://github.com/rsta2/circle/blob/Step42.1/lib/usb/xhcidevice.cpp
>>> 
>>> -- Michael
>>> 
>>> 
>>>> On 15 Jan 2021, at 20:54, Mack Wallace  wrote:
>>>> 
>>>> I took that microSD card that has the bootable image without USB and put 
>>>> it into a traditional Pi4. It boots on that without a problem and has 
>>>> mouse and keyboard. I notices that after the additional CPU cores are 
>>>> detected, that is mentions usb/hub… usb/kbd….  The image when booting on 
>>>> the Pi 400 never provides those messages.
>>>> 
>>>> Regards,
>>>> 
>>>> Mack 
>>>> 
>>>>> On Jan 15, 2021, at 1:44 PM, Mack Wallace  wrote:
>>>>> 
>>>>> Dear Skip,
>>>>> 
>>>>> That pushed the ball forward significantly, but I still have issues. (But 
>>>>> thank you, every little advancement helps.) So with that flag, I was able 
>>>>> to get Richard’s port to boot into Glenda’s account (showing acme, faces, 
>>>>> stats, etc). However, I do not seem to have any USB; no mouse; nor 
>>>>> keyboard. Stats is moving on the screen, so things are not too locked up. 
>>>>> I did try rebooting with an external keyboard and another mouse. Still 
>>>>> nothing. The external keyboard doesn’t respond to anything (no caps lock 
>>>>> nor num lock.) One mouse is in the USB 2.0 port, another and the external 
>>>>> keyboard are in the USB 3.0 ports. 
>>>>> 
>>>>> on boot, I see the following:
>>>>> usbxhci: 0x1106 0x3483 port 6 size 0x1000 irq0
>>>>> #u/usb/ep1.0: xhci port 0x0 irq 0
>>>>> 
>>>>> The line before is #l for the network,
>>>>> The line after is the detection of the other three cores.
>>>>> 
>>>>> The changing of the enable_gic=1 on the 9front image seemed to have to 
>>>>> effect.
>>>>> 
>>>>> Thanks again!
>>>>> 
>>>>> Mack
>>>>> 
>>>>> 
>>>>> On Jan 14, 2021, at 8:15 PM, Skip Tavakkolian 
>>>>>  wrote:
>>>>>> 
>>>>>> I'm using a RPi400 with Richard's port. I'

Re: [9fans] Plan9 on Raspberry Pi 400?

[Bakul Shah]

Can you netboot Linux followed by netbooting Paln9 and have a working USB?

> On Jan 15, 2021, at 1:17 PM, Michael Engel  wrote:
> 
> Hi,
> 
> I didn't test Plan 9 on my RPi 400 so far, but I think the reason for the USB 
> problems 
> is the following:
> 
> The Raspberry Pi 400 (along with the Compute Module 4 and the 8 GB RAM 
> version 
> of the RPI4) uses a new stepping C0 of the BCM2711. This version does not 
> have a 
> dedicated EEPROM for the firmware of the xHCI USB controller and needs an 
> additional property mailbox call for loading the xHCI firmware after PCIe 
> reset. 
> 
> Some code to load the firmware can be found in the circle bare-metal library 
> (l. 88ff):
> https://github.com/rsta2/circle/blob/Step42.1/lib/usb/xhcidevice.cpp
> 
> -- Michael
> 
> 
>> On 15 Jan 2021, at 20:54, Mack Wallace  wrote:
>> 
>> I took that microSD card that has the bootable image without USB and put it 
>> into a traditional Pi4. It boots on that without a problem and has mouse and 
>> keyboard. I notices that after the additional CPU cores are detected, that 
>> is mentions usb/hub… usb/kbd….  The image when booting on the Pi 400 never 
>> provides those messages.
>> 
>> Regards,
>> 
>> Mack 
>> 
>>> On Jan 15, 2021, at 1:44 PM, Mack Wallace  wrote:
>>> 
>>> Dear Skip,
>>> 
>>> That pushed the ball forward significantly, but I still have issues. (But 
>>> thank you, every little advancement helps.) So with that flag, I was able 
>>> to get Richard’s port to boot into Glenda’s account (showing acme, faces, 
>>> stats, etc). However, I do not seem to have any USB; no mouse; nor 
>>> keyboard. Stats is moving on the screen, so things are not too locked up. I 
>>> did try rebooting with an external keyboard and another mouse. Still 
>>> nothing. The external keyboard doesn’t respond to anything (no caps lock 
>>> nor num lock.) One mouse is in the USB 2.0 port, another and the external 
>>> keyboard are in the USB 3.0 ports. 
>>> 
>>> on boot, I see the following:
>>> usbxhci: 0x1106 0x3483 port 6 size 0x1000 irq0
>>> #u/usb/ep1.0: xhci port 0x0 irq 0
>>> 
>>> The line before is #l for the network,
>>> The line after is the detection of the other three cores.
>>> 
>>> The changing of the enable_gic=1 on the 9front image seemed to have to 
>>> effect.
>>> 
>>> Thanks again!
>>> 
>>> Mack
>>> 
>>> 
>>> On Jan 14, 2021, at 8:15 PM, Skip Tavakkolian  
>>> wrote:
 
 I'm using a RPi400 with Richard's port. I'm netbooting without issues and 
 up for days.  The only issue I had was forgetting to set 'enable_gic=1' as 
 Richard instructed in the sources. Pi4 works ok without it, pi400 doesn't.
 
 
 On Thu, Jan 14, 2021, 3:39 PM Mack Wallace  wrote:
 Thank you for the reply Stuart, but no luck.
 
 I did download Mr. Miller’s image. It would not boot at all until I 
 replaced the files that you mention, but the kernel in that image locks up 
 after detecting the fourth core of the CPU. However, from that failure I 
 learned that those files, (start_cd.elf, start4cd.elf, fixup_cd.dat, 
 fixup4cd.dat) are necessary for the Pi to boot, and that those with the 
 bootcode.bin and presumably, but it doesn’t seem to matter whether I use 
 bcm2711-rpi-4-b.dtb or bcm2711-rpi-400.dtb - the dtbs are vital to the 
 process. - and that all those files simply need to be copied into the fat 
 partition/boot directory.
 
 So I burned another image (actually many, trying different SD cards, and 
 different configurations, older kernels, etc) and replaced all the files 
 I’ve mentioned with the ones from 
 https://github.com/raspberrypi/firmware/tree/master/boot (hopefully that’s 
 where I should get them). My most recent iteration just has the single 
 error repeated:
 
 sdhc: read error intr 2008002 stat 1fff
 
 This occurs many times. In the middle of these errors is 
 
 /dev/sdM0: BCM SD Host Controller 02 Version 10
 
 then the error repeats itself over 50 times before printing out the lines
 /dev/sdM0/data
 bootargs is (tcp, tls, il, local!device)[]
 
 At no time during this process is the keyboard or mouse responsive. Though 
 the mouse icon did become visible during the boot process. 
 
 I am hoping I am wrong, but I am thinking there is some sort of driver 
 issue. At the very least, checking what media there is to mount, or 
 reading the SD card. And then possibly for other things, but the former 
 could be gumming up the works for everything else.
 
 
> On Jan 14, 2021, at 6:05 PM, Stuart Morrow  
> wrote:
> 
> Try copying the .dtb *and* the start4 and fixup4.
>> 
>> 9fans / 9fans / see discussions + participants + delivery options Permalink

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T0178132f3d2ed689-Mc6cc9a0f86241492f9879a53
Delivery options: https://9fans.

Re: [9fans] Plan 9 announcements on twitter

[Bakul Shah]

In his Turing Award lecture "The Humber Programmer" he expresses this sentiment.

"the tools we are trying to use and the language or notation we are using to 
express or record our thoughts, are the major factors determining what we can 
think or express at all!"

You all may enjoy listening to him!

https://youtu.be/jDvaEiK__B8?list=PL99C1C9F94FB8FA4B&t=127

The above clip is positioned at "Now for the fifth argument." if you just want 
to read the
relevant paragraph in the transcription below:

https://www.cs.utexas.edu/users/EWD/transcriptions/EWD03xx/EWD340.html

Finally, I very much doubt he would have liked C!


> On Dec 3, 2020, at 12:50 AM, Lucio De Re  wrote:
> 
> ewd498 - should suffice for a search.
> cs.utexas.edu/users/EWD/index00xx.html seems an interesting place to look.
> 
> And I may have paraphrased Dijkstra more strongly than he would have
> intended, but I'm sure he'll forgive me.
> 
> Lucio.
> 
> On 12/3/20, Mart Zirnask  wrote:
>>> PS: I concur with the late Dijkstra that the programming language(s)
>>> you learn shape(s) your ability to construct abstractions in your
>>> mind. We're kind of safe for as long as C remains the base language
>>> for development. All bets are off when Objective C takes over.
>> 
>> Would you mind posting a link to the manuscript/transcript of the
>> essay where he discusses this?
>> 
>> Thanks,
>> Mart
> 
> 
> --
> Lucio De Re
> 2 Piet Retief St
> Kestell (Eastern Free State)
> 9860 South Africa
> 
> Ph.: +27 71 471 3694
> Cell: +27 83 251 5824

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T3fd028fcf2eeb24c-M1128d932a79d53537e8d3e73
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] venti sealed arenas and ondisk format

[Bakul Shah]

11 years ago Russ posted a program called ventino that keeps
its index in RAM. May be you can use it as a starting point?

http://mail.9fans.net/pipermail/9fans/2011-August/020604.html


> On Nov 25, 2020, at 11:13 AM, Steve Simon  wrote:
> 
> Hi,
> 
> I have a pile of sealed venti arenas on an a usb stick, and the last fossil 
> score.
> 
> is there any reasonable way I can view the dump filesystem from these with a 
> readonly
> filesystem without:
>formatting a filesystem to take them
>building indexes
>running venti
>finally running vacfs
> 
> what I would like is a vacfs like tool that can read the arenas, build the 
> index in RAM and provide a 9p interface.
> 
> any chance?
> 
> -Steve

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Taa8f31933c21889b-M6f951d0f3f0721300ad11b8a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] node-red

[Bakul Shah]

I saw a comment on Hackaday by someone who uses 25 Pis (all running node-red) 
on a manufacturing line 24/7, producing ~60K parts a day. Another commenter 
talked about a setup involving 100 or so Pis on shop floor. Lots of people 
using pi+node-red combination for all sorts of things. Looks like one can work 
around Pi's shortcomings if there is a real app!

Something like node-red would be a fun project for plan9. With a graph editor 
as a frontend - I suspect sure such a thing doesn't exist for plan9. 

https://www.youtube.com/watch?v=GeN7g4bdHiM
https://en.wikipedia.org/wiki/Node-RED
https://nodered.org/

> On Nov 22, 2020, at 2:48 AM, hiro <23h...@gmail.com> wrote:
> 
> i should not have said anything
> 
> [11561053.235151] xhci_hcd :01:00.0: @1ed0c6e0 
>  0e00 02048000
> [11572206.218075] Under-voltage detected! (0x00050005)
> [11572207.738154] bcmgenet fd58.genet eth0: Link is Down
> [11572211.898285] bcmgenet fd58.genet eth0: Link is Up -
> 1Gbps/Full - flow control off
> [11572212.458226] Voltage normalised (0x)
> [11585621.202242] xhci_hcd :01:00.0: ERROR Transfer event for
> disabled endpoint slot 2 ep 3
> 
> gonna move back to my seagate dockstar (kirkwood) for this thing :(
> at least then the rpi is free for a stateless 9front terminal again
> (easier to reboot when there's problems like the above :()
> 
> On 11/14/20, hiro <23h...@gmail.com <mailto:23h...@gmail.com>> wrote:
>> well they have FCC compliance, so i'd hope it's just internal
>> interference due to lack of rf separation on the board. unless the fcc
>> test is so busted that they were able to activate a less-problematic
>> pixel clock and never tried the full possible range? :D
>> 
>> since i don't have a github account i don't think they will listen to
>> me about my issues with the device.
>> 
>> but anyway they should hire an RF engineer and not me. if they tried
>> the common combinations at all they should have noticed themselves, no
>> ?
>> 
>> i have been using 4k@60hz when i experienced my problem, bluetooth
>> cannot be switched to 5ghz.
>> 
>> i'm just happy it works at all, i was just gonna return it otherwise
>> like i did with the earlier rpi version. don't have time to make
>> bug-wishlists for future raspberry christmas trees (took them 8 years
>> already to make the first rpi with working ethernet+usb).
>> 
>> On 11/14/20, Bakul Shah  wrote:
>>> There were reports of 2560x1440 res generating RF noise in the 2.4GHz
>>> band
>>> wifi channel 1. The proposed solution (by Eben Upton) was to use channel
>>> 4
>>> or higher or use 5GHz wifi band at this res. And supposedly there is a
>>> firmware fix for this. No idea about the bluetooth issue. You should
>>> report
>>> these issues either on their forum or one of their github repos.
>>> 
>>>> On Nov 14, 2020, at 7:14 AM, hiro <23h...@gmail.com> wrote:
>>>> 
>>>> well, for me hdmi reliably stops working when i turn on the bluetooth
>>>> keyboard and versa.
>>>> clearly RF interference was none of their concern when they made this
>>>> chip.
>>>> if your monitor suggests a different pixel clock you might get lucky
>>>> and it's just good enough, but your signal quality is gonna suffer no
>>>> matter what
> 
> --
> 9fans: 9fans
> Permalink: 
> https://9fans.topicbox.com/groups/9fans/Te91377223453b8c0-M3206bd878f444f406e0fb927
>  
> <https://9fans.topicbox.com/groups/9fans/Te91377223453b8c0-M3206bd878f444f406e0fb927>
> Delivery options: https://9fans.topicbox.com/groups/9fans/subscription 
> <https://9fans.topicbox.com/groups/9fans/subscription>

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T44e63b084a86351b-Md515e2e941ef3e09ff71e1ff
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Raspberry Pi 4 stability dependent in RAM

[Bakul Shah]

There were reports of 2560x1440 res generating RF noise in the 2.4GHz band wifi 
channel 1. The proposed solution (by Eben Upton) was to use channel 4 or higher 
or use 5GHz wifi band at this res. And supposedly there is a firmware fix for 
this. No idea about the bluetooth issue. You should report these issues either 
on their forum or one of their github repos.

> On Nov 14, 2020, at 7:14 AM, hiro <23h...@gmail.com> wrote:
> 
> well, for me hdmi reliably stops working when i turn on the bluetooth
> keyboard and versa.
> clearly RF interference was none of their concern when they made this chip.
> if your monitor suggests a different pixel clock you might get lucky
> and it's just good enough, but your signal quality is gonna suffer no
> matter what

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Te91377223453b8c0-Mcf9b9e5189fa9b42b00a6193
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Screen rotation on the Raspberry Pi 4?

[Bakul Shah]

On Oct 9, 2020, at 10:36 AM, a...@9srv.net wrote:
> 
> Yes; no difference. 

https://github.com/raspberrypi/documentation/blob/master/configuration/display_rotation.md

uses the word "default" for graphics drivers so I was hoping it meant
there was a choice! One more thing to try (just in case there is
indeed a real choice) is to put the command under a conditional filter:

[HDMI:0]
  hdmi_group=2  // <== just an example
  display_hdmi_rotate=..

Though I very much doubt this will work. Your best bet is to ask on their forum.



--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T4c0ea2725cb1abdf-Mfb9154f60987a3a956fdf1a0
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Screen rotation on the Raspberry Pi 4?

[Bakul Shah]

On Oct 8, 2020, at 9:40 PM, a...@9srv.net wrote:
> 
> It looks like graphics on the Pi 4 have changed more than I'd
> realized. As far as I can tell, the "legacy" driver (what's
> used on the 0-3) no longer offers screen rotation via the
> display_rotate directive in config.txt. 
> 
> Does anyone have rotation working on the Pi 4? If so, how?

Have you tried display_hdmi_rotate?


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T4c0ea2725cb1abdf-Mc8b9b6ac85a5e6c4c4c8dd4b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Forcing display size on Pi4

[Bakul Shah]

> On Dec 17, 2019, at 1:31 PM, Richard Miller <9f...@hamnavoe.com> wrote:
> 
>> I have a 2K display that Plan9 forces to 1920x1080 resolution.
>> Poking around 9/bcm/screen.c indicates that setting vgasize=WxHxD
>> should force the size, but adding a suitable entry in cmdline.txt
>> just gives me a blank display.
>> 
>> Before I dig deeper, is this expected to work?
> 
> Possibly not.  I haven't tried vgasize= for years and there have been a
> lot of changes to the firmware & videocore mailbox interface since then.
> 
> Plan 9 should accept whatever resolution comes from the gpu, so it
> may be the firmware which "forces" 1920x1080.  Maybe gpu_mem needs
> to be bigger than the usual 16, or some other config.txt adjustment
> is needed?

I was able run earlier pis with a 4K@30Hz display but haven't tried this
with pi4. I had to use some custom parameters.

https://www.raspberrypi.org/documentation/configuration/hdmi-config.md

says to use hdmi_enable_4kp60=1 in config.txt if you have a 4k@60hz display.
You can choose custom modes as well. There is a config_hdmi_boost parameter
to increase HDMI drive strength but this doesn't work for pi4.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T83b43600a3d592d7-Md2bdaab4daa0c8cdfef4f1ec
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] dc(1) exponent limits

[Bakul Shah]

On Mon, 16 Dec 2019 18:28:35 -0800 Bakul Shah  wrote:
> On Tue, 17 Dec 2019 09:46:52 +1100 Rob Pike  wrote:
> > % ivy
> > 652342**52342
> > 1.85475753442e+304341
> >
> > )cpu
> > 8.291ms
> >
> > (652342**52342)/34232342
> > 9.27378767209e+304340/17116171
> >
> > )cpu
> > 9.217ms
> >
> > float _
> > 5.41814385477e+304333
>
> On plan9/pi4 I get
> % ivy
> (652342**52342)/34232342
> 9.27378767209e+304340/17116171
>
> )cpu
> 181.842ms
>
> Somewhat surprisingly this is better than on linux/pi4:
>
> $ ivy
> (652342**52342)/34232342
> 9.27378767209e+304340/17116171
>
> )cpu
> 247.783ms
>
> For comparison, gambit-scheme (on linux) takes 126ms.
> $ gsi
> ...
> > (time (begin (/ (expt 652342 52342) 34232342) #f))
> (time (begin (/ (expt 652342 52342) 34232342) #f))
> 128 ms real time
> 126 ms cpu time (116 user, 10 system)
> 3 collections accounting for 3 ms real time (3 user, 0 system)
> 545796 bytes allocated
> 1051 minor faults
> 1 major fault
> #f
>
> But it doesn't have big floats so exact->inexact conversion
> returns +inf and takes 15 seconds to do so!
>
> > 50 minutes feels excessive; dc seems to work very hard.
>
> The excessive slow down is dc using nothing fancier than the
> grade-school multiplication algorithm that has an O(n^2)
> complexity. For large numbers Go's math/big package uses the
> Karatsuba algorithm which has is approx.  O(n^1.58).
> Gambit-Scheme uses the Schönhage–Strassen algorithm for really
> large numbers (in addition to Karatsuba where it is better)
> but that doesn't matter much for this computation.

Forgot to add that dc's "bignum" representation is base 100
(each 0..99 "digit" can be stored in a byte).  Go's math/big
seems to use a number base that is machine word size (2^32 or
2^64). This means dc has a bigger constant multiplier (the big
O notation hides this).

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Te871fd8fbfd16f42-M0d9a711e58134a1c951a65d4
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] dc(1) exponent limits

[Bakul Shah]

On Tue, 17 Dec 2019 09:46:52 +1100 Rob Pike  wrote:
> % ivy
> 652342**52342
> 1.85475753442e+304341
>
> )cpu
> 8.291ms
>
> (652342**52342)/34232342
> 9.27378767209e+304340/17116171
>
> )cpu
> 9.217ms
>
> float _
> 5.41814385477e+304333

On plan9/pi4 I get
% ivy
(652342**52342)/34232342
9.27378767209e+304340/17116171

)cpu
181.842ms

Somewhat surprisingly this is better than on linux/pi4:

$ ivy
(652342**52342)/34232342
9.27378767209e+304340/17116171

)cpu
247.783ms

For comparison, gambit-scheme (on linux) takes 126ms.
$ gsi
...
> (time (begin (/ (expt 652342 52342) 34232342) #f))
(time (begin (/ (expt 652342 52342) 34232342) #f))
128 ms real time
126 ms cpu time (116 user, 10 system)
3 collections accounting for 3 ms real time (3 user, 0 system)
545796 bytes allocated
1051 minor faults
1 major fault
#f

But it doesn't have big floats so exact->inexact conversion
returns +inf and takes 15 seconds to do so!

> 50 minutes feels excessive; dc seems to work very hard.

The excessive slow down is dc using nothing fancier than the
grade-school multiplication algorithm that has an O(n^2)
complexity. For large numbers Go's math/big package uses the
Karatsuba algorithm which has is approx.  O(n^1.58).
Gambit-Scheme uses the Schönhage–Strassen algorithm for really
large numbers (in addition to Karatsuba where it is better)
but that doesn't matter much for this computation.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Te871fd8fbfd16f42-M93b3c86354d1f280767a8c49
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] ARM hardware and SATA

[Bakul Shah]

With a USB3 SSD I have been able to get over 200MB/s sequential (under linux, 
on RPI4).
You can get a TB SSD for under $150 that can theoretically do 540MB/s (on a 
USB3.1 but
pi4 is usb3 so half the peak throughput). For a venti server your bottleneck 
will be the GBe.

I haven't been able to run Richard's latest image (may have to do with eeprom 
updates I did)
so no idea what 9pi does as yet.

> On Dec 12, 2019, at 12:30 AM, Dan Cross  wrote:
> 
> We had 9legacy running on Intel NUCs at Google for our internal development. 
> It worked well enough, though of course wasn't an ARM based machine. Getting 
> it going was a little hacky, but not too bad. We were using raspberry pi's as 
> terminals.
> 
> I haven't looked in depth, but I suspect there's relatively little support 
> for SATA interfaces in Richard's BCM code. Targeting something like the 
> BananaPi W2 as a small server would probably be doable and the delta from 
> Richard's code would be smaller than an ersatz port.
> 
> - Dan C.
> 
> 
> On Thu, Dec 12, 2019, 12:02 PM Lucio De Re  > wrote:
> I'd like suggestions for some hardware on which to run Plan 9, almost
> certainly expandable SSD capacity will be a must (Venti service).
> Price and quality will be the biggest factors, as always.
> 
> Ideally, storage is where the value will reside, the actual processor
> could be expendable.
> 
> ARM would allow me to start with Richard Miller's release, which I
> believe to be a very sound foundation.
> 
> Thanks for any and all comments.
> 
> Lucio.
> 
> --
> 9fans: 9fans
> Permalink: 
> https://9fans.topicbox.com/groups/9fans/Tfa3a09b0e78ea56b-M6bc9d051ece7ae7925fb6867
>  
> 
> Delivery options: https://9fans.topicbox.com/groups/9fans/subscription 
> 
> 9fans  / 9fans / see discussions 
>  + participants 
>  + delivery options 
> Permalink 
> 

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tfa3a09b0e78ea56b-M18ce43e9fc6208a912b329e5
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Is the vanilla Plan 9 still alive?

[Bakul Shah]

On Nov 23, 2019, at 9:25 PM, greemngr...@gmail.com wrote:
> 
> I was just curious if it had any chances of coming back or were 9legacy and 
> 9front the only options.

Ah. :-) But why? It is just out of idle curiosity, such
as wondering about an old friend you haven't seen in
decades or you actually wanted to use plan9?

Personally I'd recommend 9pi. Raspi + 9pi is a great
combination and there is plenty to explore, plenty of real
world things to control. There are a lot of pi "hats" that
would be fun to play with or use.



--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tb6b3aefeebeb526d-Mf52a06269beb23f06f90d404
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Is the vanilla Plan 9 still alive?

[Bakul Shah]

On Nov 21, 2019, at 10:29 PM, greemngr...@gmail.com wrote:
> 
> The site hasn't been updated since 2014-2015. If it's dead, is there any 
> chance of it coming back into development?

Why do you ask? What do you want to do?
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tb6b3aefeebeb526d-M7e448fa254695b6b7ab5b32c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] plan9port on osx

[Bakul Shah]

On Thu, 21 Nov 2019 08:49:32 +0100 fge...@gmail.com wrote:
fge...@gmail.com writes:
> On 11/21/19, fge...@gmail.com  wrote:
> > On 11/21/19, arn...@skeeve.com  wrote:
> >> "Ethan Gardener"  wrote:
> >>
> >>> > i cannot find a plan9port maillist, so i am asking here.
> >>>
> >>> it's called plan9port-dev and it's on google groups:
> >>>
> >>> https://groups.google.com/forum/#!forum/plan9port-dev
> >>
> >> Clicking on the link tells me I don't have access to the group.
> >>
> >> I reported something directly to Russ a few days ago, but didn't
> >> hear back...
> >>
> >> Thanks,
> >>
> >> Arnold
> >
> > https://groups.google.com/forum/?utm_medium=3Demail&utm_source=3Dfooter#!=
> forum/plan9port-dev
> > should look more friendly.
>
> I'm not sure what's happening. I've tried this ^ again in incognito
> mode and it was (probably) the same error page Arnold reported. After
> several browser restarts and checks later sometimes the result is the
> topic list as expected, but sometimes it's the error page.

It is a private group.
Ask to subscribe by sending email to plan9port-dev+subscr...@googlegroups.com

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Teef4e32e6f6c10de-M8df6cedc9e671cafd146fea9
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] go under plan9 on the radpberry pi?

[Bakul Shah]

See https://www.flexense.com/usb3_vs_sata_disk_performance_comparison.html
Here local SATA3 vs USB3 comparison is done. While not directly comparable,
the only case where throughput is below what you can push through GbE is
single threaded small file copying. For every other case tested, GbE will
be the bottleneck.

> On Sep 21, 2019, at 5:32 AM, hiro <23h...@gmail.com> wrote:
> 
> yeah, but check small blocksize random read/write vs. AoE or 9p over
> ethernet. I'm not sure how efficient usb3 in terms of latency :)
> 
> On 9/21/19, Bakul Shah  wrote:
>> On Fri, 20 Sep 2019 09:53:07 +0100 Richard Miller <9f...@hamnavoe.com>
>> wrote:
>>> 
>>>> Another option worth exploring may
>>>> be AOE as pi4 has a GbE (I haven't tried this yet).
>>> 
>>> My go test builders are running with "local" fossil on a slice
>>> of disk provided over AoE from an atom server.  I tried various
>>> configurations and this gave me the best performance.  This is
>>> with 3B+ machines on "gigabit" ethernet throttled by rubbish usb.
>>> 
>>> Pi4 has proper GbE, but also has usb3 so a local ssd drive might
>>> be a practical alternative.  More experiments to do.
>> 
>> On linux/pi4 I get about 230MB/s for seq. read on a $10 USB3.1
>> Samsung flash drive. Time to get a new SSD!
>> 
>> 
> 

Re: [9fans] go under plan9 on the radpberry pi?

[Bakul Shah]

On Fri, 20 Sep 2019 09:53:07 +0100 Richard Miller <9f...@hamnavoe.com> wrote:
>
> > Another option worth exploring may
> > be AOE as pi4 has a GbE (I haven't tried this yet).
>
> My go test builders are running with "local" fossil on a slice
> of disk provided over AoE from an atom server.  I tried various
> configurations and this gave me the best performance.  This is
> with 3B+ machines on "gigabit" ethernet throttled by rubbish usb.
>
> Pi4 has proper GbE, but also has usb3 so a local ssd drive might
> be a practical alternative.  More experiments to do.

On linux/pi4 I get about 230MB/s for seq. read on a $10 USB3.1
Samsung flash drive. Time to get a new SSD!

Re: [9fans] go under plan9 on the radpberry pi?

[Bakul Shah]

On Fri, 20 Sep 2019 06:29:31 +0100 Steve Simon  wrote:
>
> my plan was to build and run/debug go on a raspberry pi 4 running plan9, not
>  to cross compile.

If you mean go programs, the compile speed is tolerable
provided you are not building very large programs.

If you mean the go compiler itself, hopefully the 2GB VM you
get on 9p/pi4 is enough to compile the compiler using a
cross-compiled bootstrap compiler.  If the build does work, it
will be slow because sdcards are slow. Root mounted from a
decent fileserver may help. Another option worth exploring may
be AOE as pi4 has a GbE (I haven't tried this yet).

Re: [9fans] go under plan9 on the radpberry pi?

[Bakul Shah]

On Thu, 19 Sep 2019 22:41:48 +0100 Steve Simon  wrote:
>
> does go run under plan9 on the radpberry pi or only on x86?

I haven't tried a native build but cross-compiling with

cd `go env GOROOT`/src
GOOS=plan9 GOARCH=arm ./bootstrap.bash

seems to work. bunzip2 the resulting .tbz file in $home & then
bind -a $home/go-plan9-arm-bootstrap/bin /bin

Only lightly tested.

Re: [9fans] aux/timesync -n doesn't work

[Bakul Shah]

May be you can try ru.pool.ntp.org. 

> On Sep 10, 2019, at 3:40 PM, Олег Бахарев  wrote:
> 
> I can ping. Russian ntp2 stratix server
> 
> вт, 10 сент. 2019 г., 18:55 Richard Miller <9f...@hamnavoe.com 
> >:
> > aux/timesync doesnt work in raspberry pi 2
> 
> What ntp server are you naming in the timesync -n command?
> Can you ip/ping it?
> 
> 

Re: [9fans] raspberry pi 4 arm64 test image

[Bakul Shah]

On Thu, 22 Aug 2019 01:58:39 +0200 cinap_len...@felloff.net wrote:
> new kernel that should be able to deal with the two regions:
>
> http://felloff.net/usr/cinap_lenrek/9pi4
>
> sha1sum:
>
> 0222a824ec04c672955560ea120fa4d8de848e79

cat '#ec/*maxmem'
0x3e60 0x4000 0xfc00

Ethernet and sdcard worked fine. Haven't tried usb3 yet.
Nice job!

Re: [9fans] raspberry pi 4 arm64 test image

[Bakul Shah]

On Wed, 21 Aug 2019 21:53:42 +0200 cinap_len...@felloff.net wrote:
cinap_len...@felloff.net writes:
> thank you!
>
> i believe its just starting rio so you dont get any more output.
>
> interestingly, the framebuffer was set up without error as
> far as the kernel is concerned. otherwise we would get an
> error when trying to attach devdraw.

The display shows an error "not support" on the screen.
bc2708_fb.fbheight is 1280 and fbwidth 1920 which don't seem
to work on my display. Removing gpu_mem=16 didn't help.  I
didn't get any output - not even the first line.

Re: [9fans] raspberry pi 4 arm64 test image

[Bakul Shah]

On Wed, 21 Aug 2019 23:59:28 +0200 cinap_len...@felloff.net wrote:
cinap_len...@felloff.net writes:
> > The firmware on a pi4 with 2GB or 4GB RAM will only report 1GB.
> > I believe you need to look at the board id (or probe for invalid
> > addresses as in the teg2 kernel) to find out the real amount.
>
> oh dear. i dont even know the expected physical memory map...
> i guess that ram is continuous block at [0-0xfc00). but
> some memory might be reserved...
>
> on what method does it report only 1GB?
>
> i know of 3 methods so far:
>
> - atags
> - device tree /memory/reg property
> - firmware property request (getramsize() in vcore.c)
>
> for me getramsize() returns zero for both base and limit so its
> completely useless.
>
> i'm currently using device tree method, but the code assumes that
> there is a single block entry. lets see if that lies as well with
> the debug kernel.

The device tree has two entries.

offset:0
lenght:0x3c40

offset:0x4000
length:0xbc00

Re: [9fans] raspberry pi 4 arm64 test image

[Bakul Shah]

On Wed, 21 Aug 2019 21:05:20 +0100 Richard Miller <9f...@hamnavoe.com> wrote:
> > ba...@bitblocks.com>:
> >  Trying this on pi4B4GB
> > 
> > - no display
>
> The display does come up for me (using HDMI0 socket).

It is an early 4k Seiki TV/Monitor. It works fine on a pi3
(running your kernel) in 1440x900 res. On pi4 with 9front, it
says "Not support" on the screen so likely some invalid
parameter.

Re: [9fans] raspberry pi 4 arm64 test image

[Bakul Shah]

On Wed, 21 Aug 2019 19:56:08 +0200 cinap_len...@felloff.net wrote:
> i'v made a sdcard image for the new raspberry pi 4
> (also works on 3).
>
> http://gabe.felloff.net/usr/cinap_lenrek/9front-7336.bb28fe19fe44.pi3.img.gz
>
> this has support for most of the new hardware:
>
> sdcard, ethernet and usb3.0
>
> can someone please test this on the 2GB and 4GB
> ram variants for me?

Trying this on pi4B4GB

- no display
- on the serial port I see

Plan 9
127 holes free
0x00630060 0x0cf4 210829216
210829216 bytes free
cpu0: 1500MHz ARM Cortex-A72 r0p3
512M memory: 207M kernel data, 304M user, 1828M swap
bus dev type vid  did intl memory
0   0/0 06 04 00 14e4 2711   0  ->1
1   0/0 0c 03 30 1106 3483   0  0:6 4096
#l0: genet: 1000Mbps port 0xBD58 irq 189 ea dca6320d63de
usbxhci: cpu2: 1500MHz ARM Cortex-A72 r0p3
cpu3: 1500MHz ARM Cortex-A72 r0p3
cpu1: 1500MHz ARM Cortex-A72 r0p3
0x1106 0x3483: port 0x6 size 0x1000 irq 0
#l0: phy1 id 600d84a2 oui 80361
nusb/kb: /dev/usb/ep4.0: setproto: Context State Error
nusb/kb: /dev/usb/ep4.0: setproto: no report descriptor

/dev/sdM0: eMMC SD Host Controller 02 Version 10
/dev/sdM0/data
/dev/sdM0/dosdos
/dev/sdM0/fs hjfs
/dev/sdM0/nvram
/dev/sdM0/plan9
bootargs is (tcp, tls, il, local!device)[local!/dev/sdM0/fs]
user[glenda]:
hjfs: fs is /dev/sdM0/fs

init: starting /bin/rc
aux/timesync: accessing /dev/rtc: '/dev/rtc' file does not exist
echo: write error: unknown control message "res 3"

Then no response.

Re: [9fans] Plan 9 C compiler for Xtensa CPUs

[Bakul Shah]

On Aug 9, 2019, at 2:34 PM, Charles Forsyth  wrote:
> 
> Since the resources are small if not tiny, a little systems analysis and 
> design is probably needed, but it looks like a bit of fun, until the 
> inevitable moment of "why am I here?".
> 
> On Fri, Aug 9, 2019 at 4:50 PM Charles Forsyth  
> wrote:
> The device I've got is ESP32-WROOM-32. None of the boards I've seen that use 
> it bother with external memory,
> so memory is limited, especially the way it's partitioned.
> 
> On Fri, Aug 9, 2019 at 3:50 PM Charles Forsyth  
> wrote:
> The ESP32 has got several MMUs. The characteristics are different depending 
> on the part that a given MMU accesses (flash, ROM, SRAM, external memory).
> Some things are accessed using Memory Protection Units instead, which control 
> access by Process ID, but don't do mapping. Others including some of the 
> SRAMs are accessed through
> an MMU that can do virtual to physical mapping. The MMUs for internal SRAM0 
> and 2 choose protection for a given physical page as none, one or all of PIDs 
> 2 to 7, with the virtual address that
> maps to it. PIDs 0 and 1 can access everything. PID 0 can execute privileged 
> instructions.
> A large chunk of SRAM (SRAM 1) has only Memory Protection and no translation. 
> The external memory MMU is the most general (most conventional).

Thanks.

Not ideal for plan9 but it would be nice to have access to all its IO 
capabilities over 9p.

Re: [9fans] Plan 9 C compiler for Xtensa CPUs

[Bakul Shah]

esp32 doesn’t have an mmu, right?

> On Jul 26, 2019, at 03:30, Charles Forsyth  wrote:
> 
> I was thinking of doing that since I've got an ESP-32 for some reason
> 
>> On Fri, Jul 26, 2019 at 7:38 AM Cyber Fonic  wrote:
>> I was reading the post Why Didn't Plan 9 Succeed on Hacker News.
>> 
>> Made me think that Plan 9 for IoT system of systems could be viable.
>> 
>> To that end, ESP-32 modules look capable enough to run Plan 9, but is there 
>> a Plan 9 C compiler for Xtensa ISA CPUs? 
>> 

Re: [9fans] Someone made a Wayland compositor based on Rio, Wio

[Bakul Shah]

On May 2, 2019, at 4:10 AM, hiro <23h...@gmail.com> wrote:
> 
>> Broadly speaking, that's [rio running inside rio] the essence of Rio.
> 
> i have lately investigated the code of rio, devdraw and memlayer and
> understood a bit the historic connection to bitblt, etc., and i've
> been wondering lately where statements like above, which i have heard
> before, come from.
> 
> they makes no sense to me, that rio nesting feature seems like an
> afterthought and involves a lot of back and forth which isn't just
> inefficient, but extremely inflexible!

Look at the moon, not the pointing finger.

[Answer kept below Skip's Twitter read limit.]

Re: [9fans] UI design | enhancements.

[Bakul Shah]

What I meant to say is you can't apply aesthetics of art
to UI as the latter has a functional purpose. And we don't
have to wait for a Michelangelo to design a perfect UI!
In other words, I don't think a UI discussion would be
fruitless. Not to replicate KDE/Gnome etc. but to find
other alternatives that feel more in tune with plan9.

> On Apr 14, 2019, at 11:41 PM, Michael Misch  
> wrote:
> 
> The whole thing is a good discussion. plan9's design works, very well; for 
> about 80% of would be users. For differently abled people in any capacity it 
> all falls apart quickly. it's such a simple system though it wouldn't take 
> much work to extend support wherever needed.
> 
> On Mon., Apr. 15, 2019, 12:26 a.m. Devine Lu Linvega,  
> wrote:
> Michelangelo would have been “middle-click!? Hell no”.
> 
> > On Apr 15, 2019, at 3:12 PM, Bakul Shah  wrote:
> > 
> > Michelangelo or Rodin didn't have to worry about function, only form.
> > 
> > Da Vinci on the other hand
> > 
> >> On Apr 14, 2019, at 10:07 PM, Lucio De Re  wrote:
> >> 
> >> The thing is, a UI is a combination of far too many personal tastes
> >> and habits and a GUI multi-dimensionally more so. It's like a marble
> >> slab that needs a Michelangelo to turn it into an image.
> >> 
> >> We've had one Michelangelo and a Rodin and only a few Greek sculptors
> >> in the past, what, three thousand years? Do we really think that a
> >> near infinite number of monkeys is now going to solve that problem,
> >> specially when the marble slab is undergoing its own metamorphosis
> >> underfoot?
> >> 
> >> Good luck!
> >> 
> >> Lucio.
> >> 
> > 
> > 
> 
> 

Re: [9fans] UI design | enhancements.

[Bakul Shah]

Michelangelo or Rodin didn't have to worry about function, only form.

Da Vinci on the other hand

> On Apr 14, 2019, at 10:07 PM, Lucio De Re  wrote:
> 
> The thing is, a UI is a combination of far too many personal tastes
> and habits and a GUI multi-dimensionally more so. It's like a marble
> slab that needs a Michelangelo to turn it into an image.
> 
> We've had one Michelangelo and a Rodin and only a few Greek sculptors
> in the past, what, three thousand years? Do we really think that a
> near infinite number of monkeys is now going to solve that problem,
> specially when the marble slab is undergoing its own metamorphosis
> underfoot?
> 
> Good luck!
> 
> Lucio.
> 

Re: [9fans] zero copy & 9p (was Re: PDP11 (Was: Re: what heavy negativity!)

[Bakul Shah]

On Wed, 10 Oct 2018 20:56:20 -0400 Dan Cross  wrote:
>
> On Wed, Oct 10, 2018 at 7:58 PM  wrote:
>
> > > Fundamentally zero-copy requires that the kernel and user process
> > > share the same virtual address space mapped for the given operation.
> >
> > and it is. this doesnt make your point clear. the kernel is always mapped.
> >
>
> Meltdown has shown this to be a bad idea.

People still do this.

> > (you ment 1:1 identity mapping *PHYSICAL* pages to make the lookup cheap?)

Steve wrote "1:1 mapping of the virtual kernel address space such
that something like zero-copy could be possible"

Not sure what he meant. For zero copy you need to *directly*
write to the memory allocated to a process. 1:1 mapping is
really not needed.

> plan9 doesn't use an identity mapping; it uses an offset mapping for most
> of the address space and on 64-bit systems a separate mapping for the
> kernel. An identity mapping from P to V is a function f such that f(a) = a.
> But on 32-bit plan9, VADDR(p) = p + KZERO and PADDR(v) = v - KZERO. On
> 64-bit plan9 systems it's a little more complex because of the two
> mappings, which vary between sub-projects: 9front appears to map the kernel
> into the top 2 gigs of the address space which means that, on large
> machines, the entire physical address space can't fit into the kernel.  Of
> course in such situations one maps the top part of the canonical address
> space for the exclusive use of supervisor code, so in that way it's a
> distinction without a difference.
>
> Of course, there are tricks to make lookups of arbitrary addresses
> relatively cheap by using the MMU hardware and dedicating part of the
> address space to a recursive self-map. That is, if you don't want to walk
> page tables yourself, or keep a more elaborate data structure to describe
> the address space.
>
> > the difference is that *USER* pages are (unless you use special segments)
> > scattered randomly in physical memory or not even realized and you need
> > to lookup the pages in the virtual page table to get to the physical
> > addresses needed to hand them to the hardware for DMA.

If you don't copy, you do need to find all the physical pages.
This is not really expensive and many OSes do precisely this.

If you copy, you can avoid walking the page table. But for
that to work, the kernel virtual space needs to mapped 1:1 in
*every* process -- this is because any cached data will be in
kernel space and must be availabele in all processes.

In fact the *main* reason this was done was to facilitate such
copying. Had we always done zero-copy, we could've avoided
Meltdown altogether. copyin/copyout of syscall arguments
shouldn't be expensive.

> So...walking page tables is hard? Ok
>
> > now the *INTERESTING* thing is what happens to the original virtual
> > address space that covered the I/O when someone touches into it while
> > the I/O is in flight. so do we cut it out of the TLB's of ALL processes
> > *SHARING* the segment? and then have the pagefault handler wait until
> > the I/O is finished?

In general, the way this works is a bit different. In an
mmap() scenario, the initial mapping simply allocates the
necessary PTEs and marks them so that *any* read/write access
will incur a page fault.  At this time if the underlying page
is found to be cached, it is linked to the PTE and the
relevant access bit changed to allow the access. if not, the
process has to wait until the page is read in, at which time
it be linked with the relevant PTE(s). Even if the same file
page is mapped in N processes, the same thing happens. The
kernel does have to do some bookkeeping as the same file data
may be referenced from multiple places.

> You seem to be mixing multiple things here. The physical page has to be
> pinned while the DMA operation is active (unless it can be reliably
> canceled). This can be done any number of ways; but so what? It's not new
> and it's not black magic. Who cares about the virtual address space? If
> some other processor (nb, not process -- processes don't have TLB entries,
> processors do) might have a TLB entry for that mapping that you just
> changed you need to shoot it down anyway: what's that have to do with
> making things wait for page faulting?

Indeed.

> The simplicity of the current scheme comes from the fact that the kernel
> portion of the address *space* is effectively immutable once the kernel
> gets going. That's easy, but it's not particularly flexible and other
> systems do things differently (not just Linux and its ilk). I'm not saying
> you *should* do it in plan9, but it's not like it hasn't been done
> elegantly before.
>
>
> > fuck your go routines... he wants the D.

What?!

> > > This can't always be done and the kernel will be forced to perform a
> > > copy anyway.

In general this is wrong. None of this is new. By decades.
Theoreticlly even regular read/write can use mapping behind
the scenes. [Save the old V->P map to deal with any IO error,
remove the same from

[9fans] zero copy & 9p (was Re: PDP11 (Was: Re: what heavy negativity!)

[Bakul Shah]

Excellent response! Just what I was hoping for!

On Oct 10, 2018, at 2:54 PM, Steven Stallion  wrote:
> 
> As the guy who wrote the majority of the code that pushed those 1M 4K
> random IOPS erik mentioned, this thread annoys the shit out of me. You
> don't get an award for writing a driver. In fact, it's probably better
> not to be known at all considering the bloody murder one has to commit
> to marry hardware and software together.
> 
> Let's be frank, the I/O handling in the kernel is anachronistic. To
> hit those rates, I had to add support for asynchronous and vectored
> I/O not to mention a sizable bit of work by a co-worker to properly
> handle NUMA on our appliances to hit those speeds. As I recall, we had
> to rewrite the scheduler and re-implement locking, which even Charles
> Forsyth had a hand in. Had we the time and resources to implement
> something like zero-copy we'd have done it in a heartbeat.
> 
> In the end, it doesn't matter how "fast" a storage driver is in Plan 9
> - as soon as you put a 9P-based filesystem on it, it's going to be
> limited to a single outstanding operation. This is the tyranny of 9P.
> We (Coraid) got around this by avoiding filesystems altogether.
> 
> Go solve that problem first.

You seem to be saying zero-copy wouldn't buy anything until these
other problems are solved, right?

Suppose you could replace 9p based FS with something of your choice.
Would it have made your jobs easier? Code less grotty? In other
words, is the complexity of the driver to achieve high throughput
due to the complexity of hardware or is it due to 9p's RPC model?
For streaming data you pretty much have to have some sort of
windowing protocol (data prefetch or write behind with mmap is a
similar thing).

Looks like people who have worked on the plan9 kernel have learned
a lot of lessons and have a lot of good advice to offer. I'd love
to learn from that. Except usually I rarely see anyone criticizing
plan9.


> On Wed, Oct 10, 2018 at 12:36 PM  wrote:
>> 
>>> But the reason I want this is to reduce latency to the first
>>> access, especially for very large files. With read() I have
>>> to wait until the read completes. With mmap() processing can
>>> start much earlier and can be interleaved with background
>>> data fetch or prefetch. With read() a lot more resources
>>> are tied down. If I need random access and don't need to
>>> read all of the data, the application has to do pread(),
>>> pwrite() a lot thus complicating it. With mmap() I can just
>>> map in the whole file and excess reading (beyond what the
>>> app needs) will not be a large fraction.
>> 
>> you think doing single 4K page sized reads in the pagefault
>> handler is better than doing precise >4K reads from your
>> application? possibly in a background thread so you can
>> overlap processing with data fetching?
>> 
>> the advantage of mmap is not prefetch. its about not to do
>> any I/O when data is already in the *SHARED* buffer cache!
>> which plan9 does not have (except the mntcache, but that is
>> optional and only works for the disk fileservers that maintain
>> ther file qid ver info consistently). its *IS* really a linux
>> thing where all block device i/o goes thru the buffer cache.
>> 
>> --
>> cinap
>> 
> 

Re: [9fans] PDP11 (Was: Re: what heavy negativity!)

[Bakul Shah]

On Oct 9, 2018, at 3:06 PM, erik quanstrom  wrote:
> 
> with meltdown/Spectre mitigations in place, I would like to see evidence that 
> flip is faster than copy.

If your system is well balanced, you should be able to
stream data as fast as memory allows[1]. In such a system
copying things N times will reduce throughput by similar
factor. It may be that plan9 underperforms so much this
doesn't matter normally.

But the reason I want this is to reduce latency to the first
access, especially for very large files. With read() I have
to wait until the read completes. With mmap() processing can
start much earlier and can be interleaved with background
data fetch or prefetch. With read() a lot more resources
are tied down. If I need random access and don't need to
read all of the data, the application has to do pread(),
pwrite() a lot thus complicating it. With mmap() I can just
map in the whole file and excess reading (beyond what the
app needs) will not be a large fraction.

The default assumption here seems to be that doing this
will be very complicated and be as bad as on Linux. But
Linux is not a good model of what to do and examples of what
not to do are not useful guides in system design. There are
other OSes such as the old Apollo Aegis (AKA Apollo/Domain),
KeyKOS & seL4 that avoid copying[2].

Though none of this matters right now as we don't even have
a paper design so please put down your clubs and swords :-)

[1] See: https://code.kx.com/q/cloud/aws/benchmarking/
A single q process can ingest data at 1.9GB/s from a
single drive. 16 can achieve 2.7GB/s, with theoretical
max being 2.8GB/s.

[2] Liedke's original L4 evolved into a provably secure
seL4 and in the process it became very much like KeyKOS.
Capability systems do pass around pages as protected
objects and avoid copying. Sort of like how in a program
you'd pass a huge array by reference and not by value
to a function.

Re: [9fans] PDP11 (Was: Re: what heavy negativity!)

[Bakul Shah]

On Tue, 09 Oct 2018 10:45:37 -0700 Lyndon Nerenberg  wrote:
Lyndon Nerenberg writes:
> Bakul Shah writes:
>
> > One thing I have mused about is recasting plan9 as a
> > microkernel and pushing out a lot of its kernel code into user
> > mode code.  It is already half way there -- it is basically a
> > mux for 9p calls, low level device drivers, VM support & some
> > process related code.
>
> Somewhat related to this ... after reading some papers on
> TCP-in-user-space implementations, I've been thinking about how an
> interface that supported fast/secure page flipping between the
> kernel and process address space would change how we do things.
>
> E.g. right now Plan 9 suffers from a *lot* of data copying between
> the kernel and processes, and between processes themselves.  If we
> could eliminate most of that copying, things would get a lot faster.
> Dealing with the security issues isn't trivial, but the programmer
> time going into eeking out the last bit of I/O throughput of the
> current scheme could be redirected.

Funny you say this. I wrote I wanted memory mapping to avoid
having to copy data multiple times but then deleted it,
thinking it would detract from the main point.

Actually I want this even without any major redesign!

> If it works, this would reduce the kernel back to handling
> process/memory management, and talking to the hardware.  Not a
> micro-kernel, but just as good from a practical standpoint.

Some of this process/memory management can be delegated to
user code as well.

Re: [9fans] PDP11 (Was: Re: what heavy negativity!)

[Bakul Shah]

> On Oct 9, 2018, at 2:45 AM, Ethan Gardener  wrote:
> 
> One day, Uriel met a man who explained very 
> convincingly that the Plan 9 kernel is a microkernel.
> On another day, Uriel met a man who explained very 
> convincingly that the Plan 9 kernel is a macrokernel.
> Uriel was enlightened.

Exactly! No point in being scared by labels! I am really
only talking about distilling plan9 further. At least as a
thought experiment.

Isn’t it more fun to discuss this than all the “heavy
negativity”? :-)

Re: [9fans] PDP11 (Was: Re: what heavy negativity!)

[Bakul Shah]

On Mon, 08 Oct 2018 19:03:49 -0400 Dan Cross  wrote:
>
> plan9 is breathtakingly elegant, but this is in no small part because as a
> research system it had the luxury of simply ignoring many thorny problems
> that would have marred that beauty but that the developers chose not to
> tackle. Some of these problems have non-trivial domain complexity and,
> while "modern" systems are far too complex by far, that doesn't mean that
> all solutions can be recast as elegantly simple pearls in the plan9 style.

One thing I have mused about is recasting plan9 as a
microkernel and pushing out a lot of its kernel code into user
mode code.  It is already half way there -- it is basically a
mux for 9p calls, low level device drivers, VM support & some
process related code.  Such a redesign can be made more secure
and more resilient.  The kind of problems you mention are
easier to fix in user code. Different application domains may
have different needs which are better handled as optional user
mode components.

Said another way, keep the good parts of the plan9 design and
reachitect/reimplement the kernel + essential drivers/usermode
daemons.  This is unlikely to happen (without some serious
funding) but still fun to think about!  If done, this would be
a more radical departure than Oberon-7 compared to Oberon but
in the same spirit.

Re: [9fans] plan9port : complete system : kernel : freebsd || linux ?

[Bakul Shah]

On Oct 3, 2018, at 8:44 PM, Mayuresh Kathe  wrote:
> 
> aram, by a complete, installable system for plan9port, i meant a
> distribution running the linux kernel, bionic, plan9port, minimal xorg.
> that distribution would be bootable off a usb disk and can be installed
> to your harddisk like any generic gnu/linux distribution.
> it is meant for use by those who want a pure plan9port based system and
> nothing more, initially. later, as demand mandates, i'll add in
> software.

Have you looked at glendix as someone else suggested?

Is there really any demand for what you want to build?
You will be spending a lot more time using a system than
in installation so why spend time on perfecting an
installable system for some imagined user population?
At any rate, you should be clear about *why* you want
this.

If you just want to learn about plan9, bite the bullet
and use a real or virtual machine running plan9.

If you want to run plan9 on a modern machine that is
not supported natively by plan9/9front, run it in a VM.

If you mainly want plan9 but also run programs not
ported to plan9 (such as a browser), running plan9 in a
VM is likely easier than running linux in a VM running
on top of plan9.

If you just want to use acme or rio, you already have
them in the standard p9p. Compiling from source is
pretty easy on *BSD, Linux & MacOS.

If you have Linux kernel + plan9 userland, you'll be
fighting both systems.

Re: [9fans] plan9port : complete system : kernel : freebsd || linux ?

[Bakul Shah]

> On Oct 2, 2018, at 7:41 AM, Dave MacFarlane  wrote:
> 
> see how far you can take the per process
> namespaces of Linux
> to make it feel like Plan 9. (AFAIK, that wouldn't be possible with
> NetBSD or FreeBSD, but
> I might be mistaken..)

Adding per process namespaces to *BSD would be a nontrivial project.

Re: [9fans] APL for Plan 9?

[Bakul Shah]

On Fri, 07 Sep 2018 08:35:23 +0200 Rudolf Sykora  
wrote:
> I also note that there now exists a GPL'd version of the K language,
> Kona. That one was straightforward to build on OpenBSD.

Kona uses mmap so not so easy to port. If you are used to
normal C style, kona code style will be very hard to grok.

BTW, it carries an ISC license.  [Not copyleft].

Re: [9fans] APL for Plan 9?

[Bakul Shah]

On Sep 6, 2018, at 6:41 AM, Ethan Gardener  wrote:
> 
> Is there an implementation of APL or a related language for Plan 9? 

http://t3x.org/klong/ Though it is not as nice as k or kona. Rob Pike’s
ivy may compile on plan9, it being implemented in go.

Re: [9fans] Is Plan 9 C "Less Dangerous?"

[Bakul Shah]

On Wed, 05 Sep 2018 07:42:52 -0400 Chris McGee  wrote:
>
> It could be, but after having looked briefly at the size of the design for
> RISC-V Rocket and especially BOOM I wonder if it's all overly complicated.
> They even built their own high level hardware language (Chisel) that
> generates Verilog using Scala. Yuck.

These are just tools.  By embedding Chisel in Scala they can
take advantage of Scala's strong typing etc. By generating
verilog they can advantage of existing tool chains to produce
an FPGA or ASIC or for simulation.  The h/w design tool chains
are pretty complex.  Hard to imagine any organization has a
stomach to replace them with something simpler. You can still
produce simple hardware design.

> Also, there's appears to be quite alot of compiler optimizations in gcc for
> RISC-based chips.

If you don't do this, cpu resources are not used efficiently.

H/W can provide a lot of computing resources that can be used
in parallel but none of the programming languages in use
provide a way to get to them effectively.

Part of the difficulty is that C/C++ are too low level and
their processor "model" is no longer the reality. Modern
CPUs have 2-3 levels of caching, TLBs etc.

> Could you get away with a much simpler, smaller hardware design and still
> run Plan 9 in a reasonable way? Maybe one side of the software/hardware
> divide has to take on more complexity to help simplify the other side?

Look at what Prof. Nicklaus Wirth did for Oberon.
https://www.inf.ethz.ch/personal/wirth/ProjectOberon/index.html

But if all you want to do is just run plan9 why even bother?

Re: [9fans] 9P or better file services for multiple platforms

[Bakul Shah]

> On Sep 2, 2018, at 2:25 AM, Lucio De Re  wrote:
> 
> (GIT is the main reason for my begging here: I "pull" the latest Go to
> my workstation, then "archive" to Plan 9 (fossil). But fossil is slow,
> too slow to compete even with cross-compiling to plan9_386. Part of
> the problem is needing to flush the "archive" target in case bits have
> been removed and "export" does not delete them on the target - that
> works well, though, with fresh releases, like go1.11, of late. To be
> honest, I have the slack to use Plan 9 on a low-powered
> server/workstation combination and even cross-produce Linux-64
> executables for production; but building the Go distribution isn't
> really worth the trouble - I make a special effort to do that, not
> often enough.)

I now run 9front on FreeBSD under bhyve on a 10 year old
athlon64 machine. Initially I cross compiled go but now a native
compile doesn’t take all that long, using a previously compiled
Go as the bootstrap compiler. I’m using 9front’s new filesystem,
not fossil.

The “dgit” program (Dave McFarlane, with assists from Chris
McGee) works well enough now for “go get” or “git pull”.

I too want a unified filesystem that all my machines feed off of but
so far I have not found a solution. Local file systems are still faster.

Re: [9fans] Static ip configuration for a standalone cpu server in qemu on Linux

[Bakul Shah]

On Sat, 25 Aug 2018 22:17:16 +0300 Alexander Kapshuk 
 wrote:
> 22:13:25.356189 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
> 10.0.0.2 tell 10.0.0.1, length 28

As Hiro mentioned it is strange that both sides have the same
mac addr as that will confuse them both.  Pick a different one
for the VM.

If that doesn't work, as an experiment try adding a static arp.
sudo arp -s 10.0.0.2  

tcpdump right from the start would be useful.

Re: [9fans] Static ip configuration for a standalone cpu server in qemu on Linux

[Bakul Shah]

On Sat, 25 Aug 2018 14:20:44 +0300 Alexander Kapshuk 
 wrote:
> I am trying to follow the instructions given here:
>
> http://fqa.9front.org/fqa3.html#3.3.1.4.4
> 3.3.1.4.4 - Linux TAP
>
> Here's what I've done so far:
> (1). Set up a tap0 device as user root:
> ip tuntap add dev tap0 mode tap user sasha
> ip address add 10.0.0.1/24 dev tap0
>
> ip addr show dev tap0
> 4: tap0:  mtu 1500 qdisc noop state DOWN group
> default qlen 1000
> link/ether c6:1c:63:d9:91:1d brd ff:ff:ff:ff:ff:ff
> inet 10.0.0.1/24 scope global tap0
>valid_lft forever preferred_lft forever

I see that tap0 state is DOWN. Try bringing it up. 
If that still doesn't work, run 
tcpdump -ni tap0
and tell us what you discover.

Re: [9fans] A compiler bug

[Bakul Shah]

On Aug 1, 2018, at 4:35 PM, Charles Forsyth  wrote:

> even so, the format and intention of the example seems practical (with the 
> correct cast to uintptr) and "An implementation may accept other forms of 
> constant expressions".
> it should be fairly easy to add as an extension with consistent handling 
> across ?c.

Both gcc and clang handle this case. This example was derived from
ObjectIcon (it works on plan9/x86 & unix systems but not on plan9/arm).

I am not familiar with the C compiler sources but will take a look.

Thanks for your response.

[9fans] A compiler bug

[Bakul Shah]

Consider:

% cat x.c
#include 
uintptr foo[3];
uintptr bar=&foo[2];

% 8c -c x.c # this works.
% 5c -c x.c # this fails
x.c:3 initializer is not a constant: bar

If I change the last line to

uintptr* bar=&foo[2];

Both compilers compile it fine. But if I change the last line
to

uintptr bar=(uintptr)&foo[2];

both compilers fail. Note that the last two examples are
type correct.

uintptr is the same size as int* so there should be no runtime
cost and we already know from the second example that &foo[2]
is a link time constant.

Similar code to the last two examples compiles on gcc/clang.

This seems like a compiler bug.

Re: [9fans] What are you using Plan 9 for?

[Bakul Shah]

On Jun 28, 2018, at 12:22 AM, Mart Zirnask  wrote:
> 
> Regarding Forth systems, this might also be of interest:
> http://cosy.com

People may find articles on k, joy etc. on Stevan Apter's
website to be interesting:
  http://nsl.com/
In particular Stevan Apter's conversation with Manfred von
Thun (designer of the Joy language):
  http://archive.vector.org.uk/art1350

Excerpt:
  The language Joy is a purely functional programming language.
  Whereas all other functional programming languages are based
  on the application of functions to arguments, Joy is based on
  the composition of functions.
...
  The semantics of this notation is summed up by: "The
  concatenation of appropriate programs denotes the composition
  of the functions which the programs denote".

Re: [9fans] What are you using Plan 9 for?

[Bakul Shah]

On Jun 25, 2018, at 2:33 AM, Ethan A. Gardener  wrote:
> 
> On Thu, Jun 21, 2018, at 7:03 PM, Bakul Shah wrote:
>> On Jun 21, 2018, at 8:23 AM, Ethan A. Gardener  wrote:
>>> 
>>> Thanks! I don't know APL at all, beyond the fact that its need for a 
>>> graphical (or at least sophisticated) display held it back in the past. I 
>>> should probably look into it now, I'm sure it would save me from making 
>>> some mistakes in my design.
>> 
>> Languages j, k & q are ascii only. K is
>> quite minimalist (compared to APL & j).
>> I quite like Scheme, k and plan9 for
>> their minimalist aesthetics.
> 
> I have briefly used q and pure, but I remember nothing practical about
> them, only that pure is a verbose q.  I've looked into APL a little
> now, got an introduction from a 1975 video which was interesting and a
> little amusing, and had a look at aiju's k pages --

I was talking about kx.com's array language q, which is a thin layer
on top of k4 and it quite SQLish. Very different from the equational
language Q or pure.

> http://aiju.de/code/k/ . I think the idea of combining operators is
> really cool, but I'm certain I'd get mixed up with both APL and k in
> the same way I struggle with regexps.

stream programming rc/sh style is a bit like array programming.
In sh you'd write

f < inputFile | g | h
or
f < inputFile | g | h > outputFile

In an apl (array prog. lang.) such as k you'd write

h g f inputArray
or
outputArray: h g f inputArray

Of course,
a) there is no side channel of stderr for apls.
b) apls have a lot of functions built in, while shells do not
   and rely on external programs.
c) apls use variables where shells use external files.

To operate on a number of files, in sh you'd have to do

for x in a b c; do f $x | g | h ; done

in k you'd use the each operator ('):

{h g f x}'(a;b;c)

A shell can only use pipes (byte streams) to connect functions
(implemented as programs). In contrast apls have much richer
data types and functions.

An interesting experiment would be to try to combine the two
models in one language.