[9fans] drawterm factotum interference in 9front

[wb . kloke]

When I use drawterm to access 9front from FreeBSD with a running factotum, no 
additional user identification is needed.
This is fine, as long as I do not try to use another identity. Factotum seems 
to overrid any -u user option in the drawterm command.  It logs me in always as 
myself, even if I add the other identity to factotum.

BTW. I would like to see a way to build a drawterm without gui, as installing 
X11 libs for nothing else than compiling a drawterm on a remote server is 
annoying. My main application of  drawterm -g is exporting factotum from a 
9front system, as plan9port factotum does not support dp9ik.
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T132487c88905c339-M82d75e29826cc82b623c8ba4
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] 9fat: on rmiller raspberry pi image?

[michaelian ennis]

I'm trying to switch a host over to a cpu server by updating the
kernel on the boot partition but 9fat: doesn't appear to be the way to
do this for this image. I dug around in the list here and didn't see
anyone else with this problem so is there some documentation I am
missing?

 Ian

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tc0393eacdd79b3ac-M51cae74dd610b8bea7ac368a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] strange tls problem on 9front

[wb . kloke]

On Sunday, 28 April 2024, at 5:32 PM, cinap_lenrek wrote:
> because the namespace from bootrc is not inherited.

init creates a complrely new namespace using
/lib/namespace from your root file-system:

Thank you. I copied /lib/namespace to the file server. Now it works as it 
should.
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T59601d5abf5e8d5f-Mec5dbb352229af41d9e1a905
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] strange tls problem on 9front

[wb . kloke]

I just inserted the line 
On Saturday, 27 April 2024, at 11:49 PM, cinap_lenrek wrote:
> bind -a #a /net

into termrc after the ip init.
Now I have /net/tls, but 

aux/listen1 'tcp!*!rcpu' /rc/bin/service/tcp17019 

still does not allow drawterm access.
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T59601d5abf5e8d5f-M2b3c720a780e4ef22454108c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] strange tls problem on 9front

[cinap_lenrek]

> This binding has to be very early to be effective.
> It is done /sys/src/9/boot/bootrc. Why does it disappear when the filesystem 
> is not local?

because the namespace from bootrc is not inherited.

init creates a complrely new namespace using
/lib/namespace from your root file-system:

newns(user, 0);

--
cinap

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T59601d5abf5e8d5f-M6463fc3833c62ea8ff632793
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] strange tls problem on 9front

[wb . kloke]

On Saturday, 27 April 2024, at 11:49 PM, cinap_lenrek wrote:
> i suppose the following is missing in your /lib/namespace:
> bind -a #a /net

This binding has to be very early to be effective. It is done 
/sys/src/9/boot/bootrc. Why does it disappear when the filesystem is not local?
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T59601d5abf5e8d5f-M3f46935c9e3eca112f2f96ac
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] strange tls problem on 9front

[cinap_lenrek]

i suppose the following is missing in your /lib/namespace:

bind -a #a /net

also... what?

--
cinap

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T59601d5abf5e8d5f-Mf69109feaec59f33a9616fab
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] strange tls problem on 9front

[wb . kloke]

I am experiencing a strange problem. When I try to boot  my 9front system using 
a file server over tcp, I get no /net/tls.
The same kernel booting on a local hjfs filesystem has it. I think, that the 
files  in both systems are also he same.
I can drawterm only to the latter configuration.

Config: it is  current 386 on FreeBSD/bhyve, the file server is fossil/venti . 

I just checked, whether it happens on amd64 also: yes.

Using  tls instead of tcp transport fails with some message about no 
/lib/ndb/dnschallenge.ip.

What can be done?
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T59601d5abf5e8d5f-Mc893c4bbb437864d9fa8b366
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] Re: IWP9 slides and materials

[david]

It's in many of the related branches in my fork:
https://github.com/dboddie/inferno-os
My changes have recently been merged into the official mirror of Inferno on 
GitHub as well:
https://github.com/inferno-os/inferno-os
If you have any trouble building the latest Inferno sources it will probably be 
due to the way libfreetype is included and built. The build needs an extra

  git submodule update --init

command to bring in the sources.
I've also pushed a fix to the freetype build process which didn't seem to be 
required when I tested it before making the original merge request:
https://github.com/inferno-os/inferno-os/pull/17

Let me know if you need help getting up and running.
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tab907fb0f88c6a95-M1af6486c985b1d82bfcbc0c5
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] Re: IWP9 slides and materials

[a]

Thanks; I really enjoyed the talk. Is your version of the thumb toolchain in 
one of your repos?
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tab907fb0f88c6a95-M8d86abc50d7cfb4331cf7c70
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] IWP9 slides and materials

[David Boddie]

I wasn't able to push my IWP9 slides to GitHub until late last week, so here
they are for those who are interested:

https://github.com/dboddie/inferno-cortex-m-paper

The slides and paper from the previous year are also available:

https://github.com/dboddie/inferno-freeze-slides

David



--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tab907fb0f88c6a95-M3a63a651f3e5618702a4ddea
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] boot order on separate venti/fossil machines

[Charles Forsyth]

Fossil once attached to venti can't serve without it, so venti must arrive
first.
My machine is fossil+venti, so not quite what you asked about, but the
mechanism would
be similar. The server boots the kernel from 9fat. (If I wanted to pxe boot
the venti,
I could push the boot server problem back to a boot server, perhaps the
auth server.)
The kernel uses configuration pcfs, which contains enough in bootdir to
start and run fossil,
which checks $venti (set in plan9.ini) to see if it should run that first,
if local. If venti isn't
local, it sets up the network so fossil can dial it.
/sys/src/9/boot/local.c organises that. I don't think a configuration is
provided
that starts just venti, but some of the pc* configurations in /sys/src/9/pc
hint at ways to
make various custom systems.

(9front's /sys/src/9/boot use rc scripts, which is much easier to change,
but it doesn't provide fossil at all.)

On Sat, 20 Apr 2024 at 08:21, Marco Feichtinger  wrote:

> I am curios.
> In an environment where you have separate machines for fossil and venti,
> do you boot fossil first, and let venti pxe boot over it,
> or do you boot venti first, with a small, local, fossil partition?
> 
> -marco

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tc731bf1d8c36e0a4-Md17bb5ecf553fcbfb1b3eae9
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] VCS on Plan9

[Dan Cross]

On Sat, Apr 20, 2024 at 4:31 AM Giacomo Tesio  wrote:

> Hi 9fans
>
> Il 18 Aprile 2024 22:41:50 CEST, Dan Cross  ha scritto:
> >
> > Git and Jujitsu are, frankly, superior
>
> out of curiosity, to your knowedge, did anyone ever tried to port fossil
> scm
> to Plan9 or 9front (even through ape)?
>
> 


Not to my knowledge, no.

Also (tangential) did anybody tried to port Tiny-CC?


No idea, sorry.

- Dan C.

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

Re: [9fans] VCS on Plan9

[Giacomo Tesio]

Hi 9fans

Il 18 Aprile 2024 22:41:50 CEST, Dan Cross  ha scritto:
> 
> Git and Jujitsu are, frankly, superior

out of curiosity, to your knowedge, did anyone ever tried to port fossil scm
to Plan9 or 9front (even through ape)?



Also (tangential) did anybody tried to port Tiny-CC?


Giacomo

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

[9fans] boot order on separate venti/fossil machines

[Marco Feichtinger]

I am curios.
In an environment where you have separate machines for fossil and venti,
do you boot fossil first, and let venti pxe boot over it,
or do you boot venti first, with a small, local, fossil partition?

-marco

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tc731bf1d8c36e0a4-M56c266fc875febb66b5af331
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] VCS on Plan9

[Dan Cross]

On Fri, Apr 19, 2024 at 12:10 AM  wrote:
> Quoth Dan Cross :
> > Correct me if I'm wrong, but this is just an `echo` into fossilcons,
> > isn't it? `fsys main snap -a` or something like it?
>
> it would be if being able to write to fossilcons
> didn't imply being able to do a lot more than
> creating a new snapshot.

Fair point. But it would be pretty simple to write a small proxy
service that wrapped that, and only exposed something that let an
authorized user trigger writing the `snap` command into `fossilcons`
on one's behalf. The point is, the raw tools to do what Steve proposed
mostly already exist; wiring them up shouldn't require any changes to
fossil itself.

This is all rather far afield from the issue of revision control,
though. Getting back to that, a true VCS and the sort of backup
facility offered by fossil+venti (and other similar things, such as
the work you've done on filesystems) are mostly orthogonal.

- Dan C.

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

Re: [9fans] VCS on Plan9

[Stuart Morrow]

On Fri, 19 Apr 2024 at 10:09, Edouard Klein  wrote:
> I love it when I discover that something down on my todo-list has
> already been done, [ ...
> ... ]
> > https://9p.io/wiki/plan9/divergefs/

It's been done *twice*: https://git.sr.ht/~kvik/unionfs

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

Re: [9fans] troll paper

[Edouard Klein]

I'll add that it takes a special brand of courage to ask "Why has
everything got to be a file" in front of a Plan 9 crowd ;)

The off-track discussions with Daniel were enlightening. I think his
perspective on "NoT" is quite valuable, and has inspired some ideas
since I got back.


ron minnich  writes:

> The  author of the paper not only helped get the conference going this year, 
> he worked hard this and last year to make sure our youtube channel worked. He 
> also has done a lot of work
> to get faculty from U. Bamberg in Germany on board. The author was a major 
> part of making IWP9 2024 go so well.
> 
> He's also done a lot to get the Unix version of the cpu command as good as it 
> is today.
> 
> I think there is a place for a slightly off the wall talk like this.
> 
> Don't like it? Don't watch it. Want talks more to your liking? Look for the 
> next CFP for IWP9, and please contribute something! I'm looking forward to it.
> 
> On Fri, Apr 12, 2024 at 3:05 AM Anthony Martin  wrote:
> 
> "Do we really have to have our own kernel? What are
> the benefits?" ...
> 
> The IWP9 paper titled "centre, left and right" looks like
> a complete troll. Was it generated by an LLM? I read the
> whole thing and it was a waste of time. Zero stars, would
> not recommend.
> 
> Institutional Academy of the Academic Institute, lol.
> 
> The vetting process needs some work, lads.
> 
> Cheers,
>   Anthony
> 
> 9fans / 9fans / see discussions + participants + delivery options Permalink

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T51f7f5a8927e1271-M59318941e57c1af41dc21c5d
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] VCS on Plan9

[Edouard Klein]

I love it when I discover that something down on my todo-list has
already been done, better than I would have, by someone else :)

Very neat tool, I'll be using it soon.
Dave Eckhardt  writes:

>> One thing i did was sometimes to create a skeletron directory
>> tree and bind *before* each single directory in /sys/src/9.
>>
>> when i needed to modify a file, you copy it in your "overlay"
>> tree.
> 
> https://9p.io/wiki/plan9/divergefs/
> 
> Dave Eckhardt

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

Re: [9fans] VCS on Plan9

[ori]

Quoth Dan Cross :
> 
> Correct me if I'm wrong, but this is just an `echo` into fossilcons,
> isn't it? `fsys main snap -a` or something like it?

it would be if being able to write to fossilcons
didn't imply being able to do a lot more than
creating a new snapshot.



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

Re: [9fans] VCS on Plan9

[Jacob Moody]

On 4/18/24 16:48, Shawn Rutledge wrote:
> Interesting that it's Rust.  Just another reason to eventually have Rust on 
> Plan 9…
Has anyone done any work on this? I know someone technically got stuff running 
using a
webasm intermediate, but I am curious if anyone has scoped out what it would 
look like
to do a proper port.

Cross compiling from some linux to a plan 9 a.out and bootstrapping that way 
seems to be the most likely.


Thanks,
moody


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

Re: [9fans] VCS on Plan9

[Dan Cross]

On Thu, Apr 18, 2024, 7:18 PM Bakul Shah via 9fans <9fans@9fans.net> wrote:

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

Arrey yaar, miri vo ki bahoat problem hain.

- Dan C.


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

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tab2715b0e6f3e0a5-M307432eefe257c8a6efc881c
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

[Shawn Rutledge]

> On Apr 18, 2024, at 1:41 PM, Dan Cross  wrote:
> 
> Git and Jujitsu are, frankly, superior.

Aha, I had never heard of Jujutsu until now; you mean 
https://martinvonz.github.io/jj/ right?  Monitoring file changes and treating 
changes to the working copy as an implicit work-in-progress commit sounds like 
a good idea, good for filesystem-integrated revision control.  In my usual 
markdown editor that I use for notes (https://github.com/ec1oud/nettebook) I’m 
planning to add UI for making git commits.  I suppose prompting for a 
customized commit message would still be a good idea, but otherwise getting 
commits automatically without needing to add that as an application feature or 
remembering to do it on the command line might be a good feature.

Interesting that it's Rust.  Just another reason to eventually have Rust on 
Plan 9…

For prose purposes (especially auto-wrapped Markdown) it bothers me that git 
diff mainly does line diffs.  So I’ve been trying to find an efficient 
algorithm for word diffs.  (Yes there is git diff --word-diff, but for an 
application to show this graphically, I’m not a big fan of running a separate 
process for it.  And the output needs parsing anyway.)  It seems a common 
technique is the facepalm one: turn every space into a newline and then do line 
diffs.  But there’s another old Bell project: 
https://github.com/HaikuArchives/Spiff.git  It’s kindof ugly code and with lots 
of comments about how inefficient it is, but at least it starts by tokenizing 
and then working with word lists in memory instead of character substitution.  
So I’m working on a fork to try to turn it into a library (will see if that’s 
worthwhile or just leads to a sufficient understanding of the algorithm that 
I’d rather start over).  But this could also be the sort of thing Jujutsu could 
improve upon, I suppose.


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

Re: [9fans] VCS on Plan9

[Dan Cross]

On Thu, Apr 18, 2024 at 5:01 PM Steve simon  wrote:
> re: VCS -vs-dump
>
> I always planned to add code to fossil to allow members of (say) the 'dump' 
> group to trigger fa fossil to venti dump at arbitrary times.
> If with this it would be trivial to have a 'release' rc script which could 
> save a log message and trigger a dump.

Correct me if I'm wrong, but this is just an `echo` into fossilcons,
isn't it? `fsys main snap -a` or something like it?

> I know this is not really a VCS but the ability to get back to an atomic set 
> of files representing a release would help a lot IMHO.

I could see the utility in that, but at this point, a repo in some
modern VCS that contained the source combined with a snapshot of the
release contents (containing binaries and so on) would be better,
IMHO.

Ironically, this came full circle for me a decade or so ago at Google.
I was explaining Venti to someone and they said, "why did they write
that? Why not just write to git?" I had to explain that Venti predated
`git` by several years. Kids these days!

- Dan C.

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

Re: [9fans] VCS on Plan9

[Steve simon]

re: VCS -vs-dump

I always planned to add code to fossil to allow members of (say) the 'dump' 
group to trigger fa fossil to venti dump at arbitrary times.
If with this it would be trivial to have a 'release' rc script which could save 
a log message and trigger a dump.

I know this is not really a VCS but the ability to get back to an atomic set of 
files representing a release would help a lot IMHO.

-Steve

> On 18 Apr 2024, at 21:41, Dan Cross  wrote:
> 
> Jujitsu



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

Re: [9fans] VCS on Plan9

[Dan Cross]

On Thu, Apr 18, 2024 at 4:27 PM Bakul Shah via 9fans <9fans@9fans.net> wrote:
> Did anyone try to port sccs to plan9?

Interesting question; I suspect not.  The only reason to have done so
would have been to inspect source repositories created outside of plan
9, in which case it likely would have been more natural to do so via
Unix (at least for the repositories I can think of that would have
been adjacent).

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.

The downside of the filesystem approach for maintaining history is
two-fold: 1) granularity. Typically the dump is only generated once a
day, but often one would rather commit more frequently (or perhaps
less so...) than that. 2) context. As it turns out, the ability to
associate a changeset with a well-written commit message is very
valuable. I have lost count of the number of times I've asked, "what
was going on when _this_ code was written?" Having that directly
available from the source repository is incredibly powerful.

Thankfully, I doubt anyone is using the old patch mechanism anymore.
Git and Jujitsu are, frankly, superior.

- Dan C.

> 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-Mec07348f737f68bed8fea253
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] VCS on Plan9

[Ori Bernstein]

On Thu, 18 Apr 2024 15:54:07 +
"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?

on today's plan 9? no.

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

on labs plan 9: https://9p.io/magic/man2html/1/patch

I dont think anyone is submitting patches with this any more.

> 
> Was it as simple as backing a source tree up, making some changes, and then 
> comparing the two? Venti? Replica?
> 
> tom


-- 
Ori Bernstein 

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

Re: [9fans] VCS on Plan9

[Dave Eckhardt]

> One thing i did was sometimes to create a skeletron directory
> tree and bind *before* each single directory in /sys/src/9.
>
> when i needed to modify a file, you copy it in your "overlay"
> tree.

https://9p.io/wiki/plan9/divergefs/

Dave Eckhardt

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

Re: [9fans] VCS on Plan9

[cinap_lenrek]

One thing i did was sometimes to create a skeletron directory
tree and bind *before* each single directory in /sys/src/9.

when i needed to modify a file, you copy it in your "overlay"
tree.

not exactly version control, but a primitive way to prepare
a change.

--
cinap

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

Re: [9fans] VCS on Plan9

[Paul Lalonde]

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
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tab2715b0e6f3e0a5-M1b6d6751f6d830d2a70a696f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] VCS on Plan9

[certanan via 9fans]

> From what I understand folks used to make diffs against the last release. 
> There was also some use of replica as you eluded to.

That answers my question. Thanks.


tom

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

Re: [9fans] 9front nvram setup

[Eric Lynema]

my setup complained when it was not set, then again im running in a vm
(uefi setup).

Sent from my phone. Please excuse the fact that I can't type on these
things to save my life.

On Thu, Apr 18, 2024, 10:36 AM  wrote:

> > It was that nvrlen setting. Apparently that needs to be something like
> 256
> > or it gets mad. It didnt like 0.
> 
> all right! good catch :D
> 
> iirc these are optional, i usually just set nvram= and nothing else.
> nvr is fixed size anyway.
> 
> --
> cinap

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T7b64800a7a98e3e1-Mfc2b877e1f554b42ae1f8c33
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] VCS on Plan9

[Jacob Moody]

On 4/18/24 10:54, certanan via 9fans 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?

Perhaps worth mentioning that before git 9front used mecurial for VCS, but I 
don't think that answers your question.
>From what I understand folks used to make diffs against the last release. 
>There was also some use of replica as you eluded to.


Thanks,
moody


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

[9fans] VCS on Plan9

[certanan via 9fans]

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
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tab2715b0e6f3e0a5-M3ad4cc51ed9aebb728fe83f8
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] 9front nvram setup

[cinap_lenrek]

> It was that nvrlen setting. Apparently that needs to be something like 256
> or it gets mad. It didnt like 0.

all right! good catch :D

iirc these are optional, i usually just set nvram= and nothing else.
nvr is fixed size anyway.

--
cinap

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T7b64800a7a98e3e1-M09cc8d488b6c432d2308165f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] 9front nvram setup

[Eric Lynema]

It was that nvrlen setting. Apparently that needs to be something like 256
or it gets mad. It didnt like 0.

Sent from my phone. Please excuse the fact that I can't type on these
things to save my life.

On Thu, Apr 18, 2024, 4:59 AM  wrote:

> > I am setting up a CPU server on 9front, and have been getting the
> following
> > errors that I just can't seem to work around.
> > can't write to nvram: i/o error
> > I have set my nvram in plan9.ini to
> > nvram=#S/sdE2/nvram
> > nvroff=0
> > nvrlen=0
> 
> You can break into rc shell at the bootargs prompt by typing !rc
> 
> then you can inspect the state of the sata drive.
> 
> cd /dev/sdE2
> ls
> cat ctl
> 
> Check if the nvram partition is here.
> 
> I'm curious as it complains only on write?
> 
> --
> cinap

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T7b64800a7a98e3e1-M058812cc2e58a761c0b7cb05
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] disk/prep partitioning issue

[Marco Feichtinger]

Okey, thanks

-marco


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T798ae549700d1ad5-Mdd2b243c924cccbf1b83646c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] disk/prep partitioning issue

[Richard Miller]

> Tried it; output:
> syntax error reading partition
> 488
> 
> So my partition count is too much, correct?

Correct. The last line has been truncated at the end of the block
so it has no newline, which is a syntax error.

It's ok to use fdisk to create more than one plan9 partition on a disk.
They'll appear as /dev/sd*/plan9, /dev/sd*/plan9.1 etc. Then you can
use prep to put some of your arenas on each plan9 partition, to avoid
overflowing the partition tables.


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T798ae549700d1ad5-M2591dfe674a68c1b200aeca1
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] disk/prep partitioning issue

[Marco Feichtinger]

> Try 'disk/prep -p /dev/sdE0/plan9 | wc -c'

Tried it; output:
syntax error reading partition
488

So my partition count is too much, correct?


> The original idea behind limiting
> arena size was so that they could be conveniently
> backed up onto optical media, but I suspect nobody
> does that any more.  

That was the plan.
Now I might change that.

-marco


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T798ae549700d1ad5-M87035549b62948583d85e24f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] 9front nvram setup

[cinap_lenrek]

> I am setting up a CPU server on 9front, and have been getting the following
> errors that I just can't seem to work around.
> can't write to nvram: i/o error
> I have set my nvram in plan9.ini to
> nvram=#S/sdE2/nvram
> nvroff=0
> nvrlen=0

You can break into rc shell at the bootargs prompt by typing !rc

then you can inspect the state of the sata drive.

cd /dev/sdE2
ls
cat ctl

Check if the nvram partition is here.

I'm curious as it complains only on write?

--
cinap

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T7b64800a7a98e3e1-M35df4b4e9c81c47f5598053d
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] disk/prep partitioning issue

[Richard Miller]

I said:
> You might have to split it up
> into two fdisk partitions, or shorten some names.

Actually, shortening names isn't likely to help much.

If you're setting up a new venti, not expanding an
existing one, could you make the arena partitions
fewer and larger? The original idea behind limiting
arena size was so that they could be conveniently
backed up onto optical media, but I suspect nobody
does that any more.  Nowadays large arenas can be
backed up onto a big USB flash drive, or onto another
venti server.


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T798ae549700d1ad5-Ma377c9908c8c5533e3ccca0b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] disk/prep partitioning issue

[Richard Miller]

> ...
> the bloom, isect7 and arenas7 partition are gone.
> ...
> What's causing that?

The partition table has to fit in one disk sector. Has yours
got bigger than 512 bytes? You might have to split it up
into two fdisk partitions, or shorten some names.

Try 'disk/prep -p /dev/sdE0/plan9 | wc -c'


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T798ae549700d1ad5-Mffe2a9371294cdca649ead2f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] disk/prep partitioning issue

[Marco Feichtinger]

I have a behaviour from disk/prep I do not understand.
I want to setup a partition table on a venti server as follows.

%disk/prep /dev/sdE0/plan9
empty 0 204800  (204800 
sectors, 100.00 MB)
nvram   204800 204801   (1 sectors, 512 B )
empty   204801 204816   (15 sectors, 7.50 KB)
arenas0 204816 209920016(209715200 
sectors, 100.00 GB)
isect0209920016 220405776   (10485760   sectors, 
5.00 GB)
arenas1   220405776 430120976   (209715200 sectors, 
100.00 GB)
isect1430120976 440606736   (10485760   sectors, 
5.00 GB)
arenas2   440606736 650321936   (209715200 sectors, 
100.00 GB)
isect2650321936 660807696   (10485760   sectors, 
5.00 GB)
arenas3   660807696 870522896   (209715200 sectors, 
100.00 GB)
isect3870522896 881008656   (10485760   sectors, 
5.00 GB)
arenas4   881008656 1090723856  (209715200 sectors, 100.00 GB)
isect4  1090723856 1101209616   10485760   sectors,  5.00 GB)
arenas5 1101209616 1310924816   (209715200 sectors, 100.00 GB)
isect5  1310924816 1321410576   (10485760   sectors,  5.00 GB)
arenas6 1321410576 1531125776   (209715200 sectors, 100.00 GB)
isect6  1531125776 1541611536   (10485760   sectors, 5.00 GB)
arenas7 1541611536 1751326736   (209715200 sectors, 100.00 GB)
isect7  1751326736 1761812496   (10485760   sectors, 5.00 GB)
bloom   1761812496 1762861072   (1048576 sectors, 512.00 MB)
empty   1762861072 1875379842   (112518770 sectors, 53.65 GB)

Now if I write the partition to disk, and exit the prep,
the bloom, isect7 and arenas7 partition are gone.

If I prep the disk again it shows following

%disk/prep /dev/sdE0/plan9
empty 0 204800  (204800 
sectors, 100.00 MB)
nvram   204800 204801   (1 sectors, 512 B )
empty   204801 204816   (15 sectors, 7.50 KB)
arenas0 204816 209920016(209715200 
sectors, 100.00 GB)
isect0209920016 220405776   (10485760   sectors, 
5.00 GB)
arenas1   220405776 430120976   (209715200 sectors, 
100.00 GB)
isect1430120976 440606736   (10485760   sectors, 
5.00 GB)
arenas2   440606736 650321936   (209715200 sectors, 
100.00 GB)
isect2650321936 660807696   (10485760   sectors, 
5.00 GB)
arenas3   660807696 870522896   (209715200 sectors, 
100.00 GB)
isect3870522896 881008656   (10485760   sectors, 
5.00 GB)
arenas4   881008656 1090723856  (209715200 sectors, 100.00 GB)
isect4  1090723856 1101209616   (10485760   sectors, 5.00 GB)
arenas5 1101209616 1310924816   (209715200 sectors, 100.00 GB)
isect5  1310924816 1321410576   (10485760   sectors, 5.00 GB)
arenas6 1321410576 1531125776   (209715200 sectors, 100.00 GB)
isect6  1531125776 1541611536   (10485760   sectors, 5.00 GB)
empty   1541611536 1875379842   (333768306 sectors, 159.15 GB)

What's causing that?

-marco


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T798ae549700d1ad5-Me8793ca87b6411c7971f8edb
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] troll paper

[ron minnich]

The  author of the paper not only helped get the conference going this
year, he worked hard this and last year to make sure our youtube channel
worked. He also has done a lot of work to get faculty from U. Bamberg in
Germany on board. The author was a major part of making IWP9 2024 go so
well.

He's also done a lot to get the Unix version of the cpu command as good as
it is today.

I think there is a place for a slightly off the wall talk like this.

Don't like it? Don't watch it. Want talks more to your liking? Look for the
next CFP for IWP9, and please contribute something! I'm looking forward to
it.


On Fri, Apr 12, 2024 at 3:05 AM Anthony Martin  wrote:

> "Do we really have to have our own kernel? What are
> the benefits?" ...
> 
> The IWP9 paper titled "centre, left and right" looks like
> a complete troll. Was it generated by an LLM? I read the
> whole thing and it was a waste of time. Zero stars, would
> not recommend.
> 
> Institutional Academy of the Academic Institute, lol.
> 
> The vetting process needs some work, lads.
> 
> Cheers,
>   Anthony

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T51f7f5a8927e1271-Md3d1e5463ea018bbdc1a0bf5
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] troll paper

[Charles Forsyth]

Briefly, no. It's a constraint language, and it happens to be able to
produce yaml etc as a side-process.
I've used it to enforce constraints in a tax application. "Enforce"
understates what actually can be done.

On Tue, 16 Apr 2024 at 20:31, G B via 9fans <9fans@9fans.net> wrote:

> Isn't Cue YACL (Yet Another Configuration Language)? Absolutely no way one
> can deprecate YAML and just use Cue, so all one is doing essentially is
> adding one more thing to learn and keep updated. And since it hasn't
> released 1.0, what happens if the new YACL never materializes but was
> adopted? Good luck ripping that out to return to YAML.
>
> On Tuesday, April 16, 2024 at 09:26:28 AM CDT, Charles Forsyth <
> charles.fors...@gmail.com> wrote:
>
>
> Although cue itself is more generally useful, applied that way it's a
> coping mechanism that indeed doesn't address the fundamental point:
> like those Sendmail configuration languages that compiled down into the
> rewrite language instead of just replacing that.
>
>
> On Tue, 16 Apr 2024 at 15:19,  wrote:
>
> Quoth Charles Forsyth :
> >
> > it's been a little while since i first looked at it, but i think one of
> the
> > example application is exactly how one might use it to avoid 80k lines of
> > yaml that you must look at directly.
> 
> while it may help -- this is just stacking complexity on top of
> complexity.
> 
> kubernetes may be a tool that some of us need to deal with for
> our jobs, but it has no place in a well designed rethink of the
> world.
> 
> *9fans * / 9fans / see discussions
>  + participants
>  + delivery options
>  Permalink
> 

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T51f7f5a8927e1271-M47e060c9bce6265f95ef579c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] troll paper

[G B via 9fans]

 Isn't Cue YACL (Yet Another Configuration Language)? Absolutely no way one can 
deprecate YAML and just use Cue, so all one is doing essentially is adding one 
more thing to learn and keep updated. And since it hasn't released 1.0, what 
happens if the new YACL never materializes but was adopted? Good luck ripping 
that out to return to YAML.

On Tuesday, April 16, 2024 at 09:26:28 AM CDT, Charles Forsyth 
 wrote:  
 
 Although cue itself is more generally useful, applied that way it's a coping 
mechanism that indeed doesn't address the fundamental point:like those Sendmail 
configuration languages that compiled down into the rewrite language instead of 
just replacing that.

On Tue, 16 Apr 2024 at 15:19,  wrote:

Quoth Charles Forsyth :
> 
> it's been a little while since i first looked at it, but i think one of the
> example application is exactly how one might use it to avoid 80k lines of
> yaml that you must look at directly.

while it may help -- this is just stacking complexity on top of
complexity.

kubernetes may be a tool that some of us need to deal with for
our jobs, but it has no place in a well designed rethink of the
world.


9fans / 9fans / seediscussions +participants +delivery optionsPermalink  
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T51f7f5a8927e1271-Me7b04f3e2f6e4c8db91448b5
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] troll paper

[Charles Forsyth]

Although cue itself is more generally useful, applied that way it's a
coping mechanism that indeed doesn't address the fundamental point:
like those Sendmail configuration languages that compiled down into the
rewrite language instead of just replacing that.


On Tue, 16 Apr 2024 at 15:19,  wrote:

> Quoth Charles Forsyth :
> >
> > it's been a little while since i first looked at it, but i think one of
> the
> > example application is exactly how one might use it to avoid 80k lines of
> > yaml that you must look at directly.
> 
> while it may help -- this is just stacking complexity on top of
> complexity.
> 
> kubernetes may be a tool that some of us need to deal with for
> our jobs, but it has no place in a well designed rethink of the
> world.
> 

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T51f7f5a8927e1271-M344d24b2cc5ab461b471e97e
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] troll paper

[ori]

Quoth Charles Forsyth :
> 
> it's been a little while since i first looked at it, but i think one of the
> example application is exactly how one might use it to avoid 80k lines of
> yaml that you must look at directly.

while it may help -- this is just stacking complexity on top of
complexity.

kubernetes may be a tool that some of us need to deal with for
our jobs, but it has no place in a well designed rethink of the
world.


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T51f7f5a8927e1271-M258f197be9ba11ce28b6cc6e
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] troll paper

[Charles Forsyth]

it's been a little while since i first looked at it, but i think one of the
example application is exactly how one might use it to avoid 80k lines of
yaml that you must look at directly.

On Tue, 16 Apr 2024 at 05:30,  wrote:

> Taj Khattra  wrote:
>
> > > > You might find help in culang.org
> > >
> > > DNS can't seem to find that for me 
> >
> > https://cuelang.org/
> 
> Much thanks!
> 
> Arnold

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T51f7f5a8927e1271-Ma3ab6cce9db4a39059bfea83
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] troll paper

[arnold]

Taj Khattra  wrote:

> > > You might find help in culang.org
> >
> > DNS can't seem to find that for me 
>
> https://cuelang.org/

Much thanks!

Arnold

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T51f7f5a8927e1271-Mb09361bab5b0b487622723cb
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] troll paper

[Charles Forsyth]

yes, sorry, mistyped on a phone

On Tue, 16 Apr 2024 at 04:24,  wrote:

> 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
> 
> DNS can't seem to find that for me 
> 
> Thanks,
> 
> Arnold

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T51f7f5a8927e1271-Mb8a9a40361e9e1e26d3b509f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] troll paper

[Taj Khattra]

>
>
> > You might find help in culang.org
>
> DNS can't seem to find that for me 
>

https://cuelang.org/

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T51f7f5a8927e1271-Mc63aa5939d7bec938566fefe
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] troll paper

[arnold]

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

DNS can't seem to find that for me 

Thanks,

Arnold

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T51f7f5a8927e1271-M6b93f78a60388d81a74a2467
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] troll paper

[michaelian ennis]

 cuelang.org rather On Apr 15, 2024, at 13:51, Charles Forsyth  wrote: And, if I hear about it being“declarative” as a virtue, I point to the 81,000+ lines (andgrowing) of YAML, that I defy any one human to comprehend.You might find help in culang.org On Mon, 15 Apr 2024 at 20:49, Kim Shrier  wrote:> On Apr 12, 2024, at 4:56 AM, David Arnold  wrote:
> 
>> The vetting process needs some work, lads.
> 
> More heresy than trolling, perhaps?
> 
> It was thought-provoking for me.  I wished I was there for the bar session afterwards. 
> 
> d
It didn’t read like a troll paper to me.  I periodically go through
a similar exercise of thinking about how I would re-evaluate
various Plan 9 decisions given the environment we find
ourselves in, more than 35 years after the original work
was done.
I do have an answer to the question, “Do we really have to
have our own kernel?”.
Yes.
Making decisions about fundamental principles upon which
you build your system has profound impacts on every aspect
of the software, including the kernel itself.  Linux is not a good
substitute for Plan 9.
And, I take particular exception to recommending Kubernetes
as a tool for deploying services.  I am having to live through
Kubernetes hell in my day job.  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.
I do think it is a good exercise to reevaluate the premises on
which one builds their systems in order to see if something
needs to change or a completely different approach is
warranted.
I just come to different conclusions than the author of this
paper.
Kim
_
C++ is an off-by-one error
--
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T51f7f5a8927e1271-M53fcb07a2a24c78bc0fd5545
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

Re: [9fans] troll paper

[Charles Forsyth]

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

On Mon, 15 Apr 2024 at 20:49, Kim Shrier  wrote:

> > On Apr 12, 2024, at 4:56 AM, David Arnold  wrote:
> >
> >> The vetting process needs some work, lads.
> >
> > More heresy than trolling, perhaps?
> >
> > It was thought-provoking for me.  I wished I was there for the bar
> session afterwards.
> >
> > d
> 
> It didn’t read like a troll paper to me.  I periodically go through
> a similar exercise of thinking about how I would re-evaluate
> various Plan 9 decisions given the environment we find
> ourselves in, more than 35 years after the original work
> was done.
> 
> I do have an answer to the question, “Do we really have to
> have our own kernel?”.
> 
> Yes.
> 
> Making decisions about fundamental principles upon which
> you build your system has profound impacts on every aspect
> of the software, including the kernel itself.  Linux is not a good
> substitute for Plan 9.
> 
> And, I take particular exception to recommending Kubernetes
> as a tool for deploying services.  I am having to live through
> Kubernetes hell in my day job.  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.
> 
> I do think it is a good exercise to reevaluate the premises on
> which one builds their systems in order to see if something
> needs to change or a completely different approach is
> warranted.
> 
> I just come to different conclusions than the author of this
> paper.
> 
> Kim
> _
> C++ is an off-by-one error
> 

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T51f7f5a8927e1271-Ma63b1c0f14990832dddeadef
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] troll paper

[Kim Shrier]

> On Apr 12, 2024, at 4:56 AM, David Arnold  wrote:
> 
>> The vetting process needs some work, lads.
> 
> More heresy than trolling, perhaps?
> 
> It was thought-provoking for me.  I wished I was there for the bar session 
> afterwards. 
> 
> d

It didn’t read like a troll paper to me.  I periodically go through
a similar exercise of thinking about how I would re-evaluate
various Plan 9 decisions given the environment we find
ourselves in, more than 35 years after the original work
was done.

I do have an answer to the question, “Do we really have to
have our own kernel?”.

Yes.

Making decisions about fundamental principles upon which
you build your system has profound impacts on every aspect
of the software, including the kernel itself.  Linux is not a good
substitute for Plan 9.

And, I take particular exception to recommending Kubernetes
as a tool for deploying services.  I am having to live through
Kubernetes hell in my day job.  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.

I do think it is a good exercise to reevaluate the premises on
which one builds their systems in order to see if something
needs to change or a completely different approach is
warranted.

I just come to different conclusions than the author of this
paper.

Kim
_
C++ is an off-by-one error





--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T51f7f5a8927e1271-M53fcb07a2a24c78bc0fd5545
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Re: 9front nvram setup

[Eric Lynema]

To the kind person who called and made sure I was all set, what was your
name again? Thank you, kind human!

On Mon, Apr 15, 2024 at 2:04 PM  wrote:

> for reference, not reading the documentation and assuming you can just set
> things like nvrlen to 0, might be the start of issues. What is the
> appopriate value for that? I set it to 256 and it worked.
> *9fans * / 9fans / see discussions
>  + participants
>  + delivery options
>  Permalink
> 
>

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T7b64800a7a98e3e1-M440b7db57dfbf6c036dc3165
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] Re: 9front nvram setup

[elynema]

for reference, not reading the documentation and assuming you can just set 
things like nvrlen to 0, might be the start of issues. What is the appopriate 
value for that? I set it to 256 and it worked.
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T7b64800a7a98e3e1-M37f83ea9b4adf2217303bc62
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] 9front nvram setup

[Eric Lynema]

I am setting up a CPU server on 9front, and have been getting the following
errors that I just can't seem to work around.
can't write to nvram: i/o error

I have set my nvram in plan9.ini to

nvram=#S/sdE2/nvram
nvroff=0
nvrlen=0

Eric Lynema
(616) 990-0911

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T7b64800a7a98e3e1-Mea9759eb71f1e8f35bc46c0c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] troll paper

[michaelian ennis]

Bar-raising.On Apr 12, 2024, at 06:29, Charles Forsyth  wrote:Where’s the link? I haven’t seen one yet for reading papers in advance.  Still one hour to go…I haven't read it yet myself, to avoid spoilers, but I thought it was a record even for Plan 9 that something has disturbed people even before the workshop opens! 

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

[9fans] IWP9 2024 - Day 2 Live Stream

[Skip Tavakkolian]

FYI, it will start shortly

https://www.youtube.com/watch?v=z8ZPgQR1IVc

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tf46d6f4d4b41700c-M659eb6ac40287b1e0dee7d3c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] Re: IWP9 2024 Live Stream

[Skip Tavakkolian]

Also, if you subscribe to the channel, you are allowed to participate
and ask questions via the live chat.

On Fri, Apr 12, 2024 at 10:50 AM Skip Tavakkolian
 wrote:
>
> FYI, in case you missed it, IWP9 is being broadcast on the Plan 9
> Foundation YouTube channel.
>
> https://www.youtube.com/watch?v=LVFovcvThX8

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tfc430a73002fc1c7-Mce04cdbe0a2105b04736cca2
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] IWP9 2024 Live Stream

[Skip Tavakkolian]

FYI, in case you missed it, IWP9 is being broadcast on the Plan 9
Foundation YouTube channel.

https://www.youtube.com/watch?v=LVFovcvThX8

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tfc430a73002fc1c7-M6db0d3920b46cad5a0d4ca3a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] troll paper

[Charles Forsyth]

>
> Where’s the link? I haven’t seen one yet for reading papers in advance.
> Still one hour to go…


I haven't read it yet myself, to avoid spoilers, but I thought it was a
record even for Plan 9 that something has disturbed people even before the
workshop opens!

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T51f7f5a8927e1271-M01f15c2d3f4e4a44193c473c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] troll paper

[lists]

Never mind, https://iwp9.org/10iwp9proceedings.pdf

> On Apr 12, 2024, at 06:56, David Arnold  wrote:
> 
> 
>> 
>> The vetting process needs some work, lads.
> 
> More heresy than trolling, perhaps?
> 
> It was thought-provoking for me.  I wished I was there for the bar session 
> afterwards.
> 
> d

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T51f7f5a8927e1271-M9dd436078709478f3864eb51
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] troll paper

[lists]

Where’s the link? I haven’t seen one yet for reading papers in advance.  Still 
one hour to go…

> On Apr 12, 2024, at 06:04, Anthony Martin  wrote:
> 
> "Do we really have to have our own kernel? What are
> the benefits?" ...
> 
> The IWP9 paper titled "centre, left and right" looks like
> a complete troll. Was it generated by an LLM? I read the
> whole thing and it was a waste of time. Zero stars, would
> not recommend.
> 
> Institutional Academy of the Academic Institute, lol.
> 
> The vetting process needs some work, lads.
> 
> Cheers,
>  Anthony

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T51f7f5a8927e1271-M73f3dc3b7bb66b0db2117c83
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] troll paper

[David Arnold]

> The vetting process needs some work, lads.

More heresy than trolling, perhaps?

It was thought-provoking for me.  I wished I was there for the bar session 
afterwards. 




d

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T51f7f5a8927e1271-M5c28f8dd1747a6fab6d30262
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] troll paper

[Peter Hull]

On Fri, 12 Apr 2024 at 11:05, Anthony Martin  wrote:
>
> The IWP9 paper titled "centre, left and right" looks like
> a complete troll. Was it generated by an LLM?

I don't always understand things written about plan9 but this seemed
even to me to be a bit off. However the author is listed as being part
of the organising committee. Maybe it is a joke to see if we are awake
and paying attention?

Really interesting stuff in the other papers though, congratulations
to all who contributed!

Peter

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T51f7f5a8927e1271-M9334f12e2579ba9ee4922483
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] troll paper

[Anthony Martin]

"Do we really have to have our own kernel? What are
the benefits?" ...

The IWP9 paper titled "centre, left and right" looks like
a complete troll. Was it generated by an LLM? I read the
whole thing and it was a waste of time. Zero stars, would
not recommend.

Institutional Academy of the Academic Institute, lol.

The vetting process needs some work, lads.

Cheers,
  Anthony

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T51f7f5a8927e1271-Mc0042c4999171963951f5bad
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] openat()

[wb . kloke]

Some replies seem to hold openat() for superfluous. In fact, IMHO the 
traditional syscall open() should be deprecated.

In FreeBSD at least, the libc  open() does in fact use the real thing 
__sys_openat(). in /usr/src/lib/libc/sys/open.c
via the interposing table.

Some days ago, I experimented with a user space implementation of the of the 
file lookup in namei() to get the benefits of a  proc specific namespace on my 
FreeBSDsystem, making Plan9 style bind and mount  available. This involved 
changing every  slash in a path name into  openat() calls for the splltted path 
components. pkeus.de/~wb/ns.c

Btw, there is another syscall in FreeBSD, which overlaps open() and openat() , 
namely fhopen(). This seems to isolate the namespace lookup operation and the 
actual file access.


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

Re: [9fans] cmdline.txt for RPi 4 with QHD screen

[taylor . garry]

Thanks Richard, I will give this a try.
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T42a55b55ffb81417-M2ea35b9ed73c3d678822e320
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] cmdline.txt for RPi 4 with QHD screen

[Richard Miller]

> We do not provide the binary files ourselves you need to acquire them from 
> the rasbian ISO.

Or look in https://github.com/RPi-Distro/firmware-nonfree/raw/buster/brcm


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T42a55b55ffb81417-Md799ead1babe0a73392e20e7
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] openat()

[Alyssa M via 9fans]

I left the oven on for my partly-baked idea.

I'm now thinking that with fd 5 as an example:
 open ("#d/5dir/a/b/c", ...)
might be a practical way to do this (the  syntax I suggested earlier would 
require walking from a file, which wouldn't be sensible).

So I went snorkeling in the kernel to see how hard this would be...

devdup.c uses the bottom bit of the qid.path to distinguish #d/0 from #d/0ctl, 
so that would have to change to modulo 3 to allow the '5dir' virtual directory 
to be found when qid.path % 3 == 2, and twicefd would have to change to 
thricefd.
The idea is that a walk to #d/5dir would continue the walk at the cloned 
unopened directory fid that fd 5 is also holding in its chan (as I suggested in 
a previous post).

Currently, dupwalk just calls devwalk in dev.c, so we'd probably want to do the 
first step in dupwalk, doing fd2chan, much like dupopen does. Then call 
something else to walk from there. I'm not sure what though: walk() maybe?
I don't really know my way around the Plan 9 kernel, so this may not be the 
right way to do this. There are some scary creatures in dev.c, including a 
spikey backward pointing goto and some dark comments about contradictory rules 
and ugly bits... :o

You'd want to get the effect of having the directory open on fd 5 bound to 
#d/5dir without actually doing the bind (because you can't...).
Ideally if fd 5 is not a directory, then #d/5dir should not even appear.

The idea is that then:
int
openat (int fd, char *path, int mode)
{
char newpath[PATHSIZE];
sprintf (newpath, "#d/%ddir/%s", fd, path);
return open (newpath, mode);
}

could be a function in a library somewhere that would parcel it up in a more 
convenient form, and the rest of the *at suite could follow the same pattern. 
Maybe someone would want this for a version of APE emulating Linux?

So the idea is still partly-baked, and still very much in the realm of the 
hypothetical: 

Ron Minnich wrote:
"I don't want this to turn into a debate on the merits of openat"

I'm approaching this in the spirit of "if we had to implement this, how would 
we do it while inflicting the least harm"... :)
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T675e737e776e5a9c-M124c4e12c40240ab85dbdea0
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] cmdline.txt for RPi 4 with QHD screen

[taylor . garry]

Thanks, I got the Raspbian image and I can see .dtb files there, but can't find 
a clear explanation of how to get the .bin files out of there. For moment I've 
just found an Ethernet cable and now at least my Plan 9 machine is on the 
network.
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T42a55b55ffb81417-M0437b8df134dbeac71cffd02
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] openat()

[Alyssa M via 9fans]

Well I got curious, and wrote a test program for my Linux RPi: 
Doing the equivalent of what du(1) does (a recursive tree walk statting every 
file) seemed to be about 15% faster with openat/fstatat than with open/lstat. 
This was on a local drive (SD card).
Over 9p to my Plan 9 RPi from Linux it appeared to make no measurable 
difference at all (though I don't know whether v9fs can take advantage of the 
*at capability).
Maybe there's some use case where it makes a more dramatic difference. My tests 
were not very scientific.
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T675e737e776e5a9c-M5f33ea51d2130dafe5918a21
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] cmdline.txt for RPi 4 with QHD screen

[moody]

All of what Brian said is true for 9front as well. If you want to see our code 
implementation of this you can find
it in /sys/src/9/bcm/ether4330.c. The only difference is that 9front puts 
firmware in /lib/firmware and not /sys/lib/firmware.
We do not provide the binary files ourselves you need to acquire them from the 
rasbian ISO. It should be located within
the raspbian ISO, within the fat32 partition there.
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T42a55b55ffb81417-M8d848d6549f0c7233e407ba2
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] cmdline.txt for RPi 4 with QHD screen

[taylor . garry]

Please don't apologise Brian, thanks so much for this help.

Looking at my ether4330.c, those two entries for revisions 6 and 9 are present, 
but I did a "walk | grep 43444" over the whole disk and I can't find anything 
like those blob files anywhere. /lib/firmware is empty too.

I think I will look at giving 9legacy a try and try your advice again.

Thanks again.

Garry
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T42a55b55ffb81417-Mc6133120b2fccaf49ba2be73
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] openat()

[moody]

In response to Ron's mail. Still can not reply from my mail server.

I still don't quite understand what you are getting at.

I was focusing up on the linux interface (ie openat(int fd, char *path, int 
flags, ...)) mapping of open fd to path. I see now as well that openat 
specifies that the argument must be a fd to a directory , so the issue of walk 
not being able to use files is not relevant, but you still have the other 
walk(5) limitations on the source fid.

If you are instead just wanting something that has the interface of: 
openat(char *dir, char *file, mode) for the purpose of avoiding just the cd 
than open as you say. Than I don't see why you couldn't usually just combine 
the open path yourself before handing it to the kernel.

If we put aside the interface and just focus on it's ability to act as a method 
to cache a walk for reuse with multiple subsequent open's let's say than I 
still think the design of 9p gets in the way. The difference between walking 
first then being able to reuse the fid for further walks, and just always 
walking from the root is however many path elements being walked internally to 
the 9p server. So I imagine that the overhead of doing this partial walk first, 
pinging to the 9p server and back to userspace would only be cheaper if you 
were opening quite a large amount of files. Is that what you were getting at 
Ron?

In response to Bakul:

I don't think it's just an easy win at all. As mentioned already the act of 
getting whatever handle you choose from the 9p server and back to userspace as 
a method of reuse to prevent a couple of internal walks within the 9p server I 
think are not going to be favorable in performance.

Thanks,
moody


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T675e737e776e5a9c-M3c21a5ee93f83ca1650b537c
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()

[Alyssa M via 9fans]

Moody wrote:
"What you _would_ want for this would be the ability to walk from the existing 
fd, however the limits of 9p walk make this a bit impossible to implement in a 
great way in my opinion. " 

Maybe the chan could keep two fids: the original walked fid, and an opened 
clone of that fid? The open one could be used for read/write, etc, and the 
original could be used for subsequent walks.

Ron Minnich wrote:
"The question I had was, can I get the benefit of *at without doing 
what linux is doing, namely, for all system calls with a path, make an 
'...at' version.
I am guessing so, though I'm not sure it's as efficient."

Could you do something like
open ("/fd/5/as-dir/a/b/c", ...)
or
open ("#d/5/as-dir/a/b/c", ...)
where 5 is the file descriptor of an open directory, and "as-dir" is 
effectively bound to the directory it has open? 
The Linux docs make passing reference to "tricks involving /proc/../fd" which 
seems like a better idea than adding all those *at system calls...

... from the department of partly-baked ideas...
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T675e737e776e5a9c-M4f2926b33d54b9f6842c2078
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] openat()

[David Leimbach via 9fans]

Depending on the implementation of the file system, openat vs open can be more efficient if there’s a lot of metadata locking for file creation.Sent from my iPhoneOn Apr 6, 2024, at 1:36 PM, 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. My first reaction, assuming you have a lot of files in that directory, was something likebind /dir /n/x and then just open /n/x/file... for a lot of files. This would work for any system call that takes a path.The question I had was, can I get the benefit of *at without doing what linux is doing, namely, for all system calls with a path, make an '...at' version.I am guessing so, though I'm not sure it's as efficient.On Fri, Apr 5, 2024 at 8:19 PM  wrote:My two cents on this:

What you _would_ want for this would be the ability to walk from the existing fd, however the limits of 9p walk make this a bit impossible to implement in a great way in my opinion. From walk(5):

The fid must represent a directory unless zero path name elements(for just cloning the fid) are specified. The fid must be valid in the current session and must not have been opened for I/O by an open or create message.

Since not every fid is eligible for being walked from, in order to implement opanat() in any way that would be better than just batching the fd2path and open would be to keep a "last directory" associated, like what we do with the string used to open it. Also worth mentioning that fd2path is not without its own problems, it's possible that the namespace has changed since the file has been opened so the same path may not work the second time. So tagging the last directory Chan would be "more correct", but I am not sure how useful this is.

Answering some other comments made:As I understand it from the rationale section on the
 linux man page, the call exists to avoid a race condition between 
checking that a directory exists and doing something to a path 
containing it. An additional motivator is providing the effect of 
additional current working directories notably for Linux threads (which 
presumably don't have their own. I think 'threads'  (processes that 
share memory) on Plan 9 do???).Each process has it's own current working directory:

% pwd
/home/moody
% @{cd /}
% pwd
% /home/moody
This is all based on the assumption that holding a file/directory open keeps it alive and in existence... which on Plan 9, I think it doesn't, does it? As I understand it, remove can remove a file or directory that is open, which is not like UNIX/Linux...
Depends on the file server implementation, I find that for more synthetic files they are indeed kept alive as long there is someone with a reference to the fid.
This is identifiable if all the cleanup happens on clunks(destroyfid in lib9p), which only happen when a fid's refcount hits zero.

For non-synthetic or more "disk" file servers the behavior can differ. Cwfs does not keep the data around, readers that attempt to read a deleted file, even if they already have a reference open to it will result in a phase error. However 9front's ramfs keeps the data around.

My test for this was as follows:win1% echo 'something' >/tmp/testwin2% win1% rm /tmp/test
# observe the error(if any) on win2So you really can't assume either case.Thanks,
moodyP.S.I apologize for the formatting, it seems my emails are not making it to the list when I attempt to send them from my mail server so I had to copy this response in to the web form.  I would like to figure out why if possible.

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

Re: [9fans] cmdline.txt for RPi 4 with QHD screen

[Brian L. Stuart]

 I wouldn't call it obvious.  :)  It looks like there's at least a difference 
in where the firmware blobs are kept.  I don't really know how much difference 
there is in the driver code, but I would expect that there would be a file in 
/sys/src/9/bcm that is analogous to ether4330.c.  But I'll have to leave it to 
others who are more knoledgable about the 9front internals to follow up with 
more details.
In the absence of a more definitive direction, I'd grep the source files in 
/sys/src/9/bcm for the string 4345.  As a hex number, that is the chip ID for 
the 802.11 interface on the 4s.  The revision number on the original 4s was 6, 
but the revision on my 400 is 9.  In the 9legacy version that I use, the 
different IDs are listed in an array of structures:
struct {
    int chipid;
    int chiprev;
    char *fwfile;
    char *cfgfile;
    char *regufile;
} firmware[] = {
    { 0x4330, 3,    "fw_bcm40183b1.bin", config40183, 0 },
    { 0x4330, 4,    "fw_bcm40183b2.bin", config40183, 0 },
    { 43362, 0,    "fw_bcm40181a0.bin", config40181, 0 },
    { 43362, 1,    "fw_bcm40181a2.bin", config40181, 0 },
    { 43430, 1,    "brcmfmac43430-sdio.bin", "brcmfmac43430-sdio.txt", 0 },
    { 43430, 2,    "brcmfmac43436-sdio.bin", "brcmfmac43436-sdio.txt",  
"brcmfmac43436-sdio.clm_blob" },
    { 0x4345, 6, "brcmfmac43455-sdio.bin", "brcmfmac43455-sdio.txt", 
"brcmfmac43455-sdio.clm_blob" },
    { 0x4345, 9, "brcmfmac43456-sdio.bin", "brcmfmac43456-sdio.txt", 
"brcmfmac43456-sdio.clm_blob" },
};

The code then runs through the array comparing the ID and rev read from the 
controller.  When it finds a match, it sends over the various blobs.  The code 
that looks for the blobs in the 9legacy driver is:

    if(!waserror()){
        snprint(nbuf, sizeof nbuf, "/boot/%s", file);
        c = namec(nbuf, Aopen, OREAD, 0);
        poperror();
    }else if(!waserror()){
        snprint(nbuf, sizeof nbuf, "/sys/lib/firmware/%s", file);
        c = namec(nbuf, Aopen, OREAD, 0);
        poperror();

If it's the same in 9front, then the blobs you have might be /boot which would 
be necessary if you were going to take the root from a file server over wifi.  
I don't ever run mine that way, so it's more convenient for me to put them in 
/sys/lib/firmware.
As before, I'll need to leave it to a 9front expert to point out any of my 
suppositions that are wrong.

Sorry for the delay.  I took a couple of hours out to take advantage of a break 
in the clouds here to test my setup for the eclipse on Monday.  And btw, the 
computer I'll have there will be my 400 running Plan 9 with the file system 
I'll be talking about at IWP9 next weekend.

BLS


On Saturday, April 6, 2024 at 07:15:16 AM UTC, taylor.ga...@gmail.com 
 wrote:  
 
 Hi Brian, 
Thanks for your help, does it make a difference that I'm using 9front? I don't 
even seem to have a /sys/lib/firmware directory, and I'm not sure I have a 
ether4330.c either. 

I'm sure it's obvious, but I'm a newcomer to Plan 9 and I apologise in advance 
if I'm missing obvious things.

Thanks

Garry9fans / 9fans / seediscussions +participants +delivery optionsPermalink  
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T42a55b55ffb81417-M21bff740cfc3be6ecf936bdb
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] openat()

[ron minnich]

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.

My first reaction, assuming you have a lot of files in that directory, was
something like
bind /dir /n/x and then just open /n/x/file... for a lot of files.

This would work for any system call that takes a path.

The question I had was, can I get the benefit of *at without doing what
linux is doing, namely, for all system calls with a path, make an '...at'
version.
I am guessing so, though I'm not sure it's as efficient.


On Fri, Apr 5, 2024 at 8:19 PM  wrote:

> My two cents on this:
>
> What you _would_ want for this would be the ability to walk from the existing 
> fd, however the limits of 9p walk make this a bit impossible to implement in 
> a great way in my opinion. From walk(5):
>
> The fid must represent a directory unless zero path name elements(for just 
> cloning the fid) are specified. The fid must be valid in the current session 
> and must not have been opened for I/O by an open or create message.
>
> Since not every fid is eligible for being walked from, in order to implement 
> opanat() in any way that would be better than just batching the fd2path and 
> open would be to keep a "last directory" associated, like what we do with the 
> string used to open it. Also worth mentioning that fd2path is not without its 
> own problems, it's possible that the namespace has changed since the file has 
> been opened so the same path may not work the second time. So tagging the 
> last directory Chan would be "more correct", but I am not sure how useful 
> this is.
>
> Answering some other comments made:
>
> As I understand it from the rationale section on the linux man page, the
> call exists to avoid a race condition between checking that a directory
> exists and doing something to a path containing it. An additional motivator
> is providing the effect of additional current working directories notably
> for Linux threads (which presumably don't have their own. I think
> 'threads'  (processes that share memory) on Plan 9 do???).
>
>
> Each process has it's own current working directory:
>
> % pwd
> /home/moody
> % @{cd /}
> % pwd
> % /home/moody
>
> This is all based on the assumption that holding a file/directory open keeps 
> it alive and in existence... which on Plan 9, I think it doesn't, does it? As 
> I understand it, remove can remove a file or directory that is open, which is 
> not like UNIX/Linux...
>
>
> Depends on the file server implementation, I find that for more synthetic
> files they are indeed kept alive as long there is someone with a reference
> to the fid. This is identifiable if all the cleanup happens on
> clunks(destroyfid in lib9p), which only happen when a fid's refcount hits
> zero. For non-synthetic or more "disk" file servers the behavior can
> differ. Cwfs does not keep the data around, readers that attempt to read a
> deleted file, even if they already have a reference open to it will result
> in a phase error. However 9front's ramfs keeps the data around.
>
> My test for this was as follows:
> win1% echo 'something' >/tmp/test
> win2%  win1% rm /tmp/test # observe the error(if any) on win2
>
> So you really can't assume either case.
>
>
> Thanks,
> moody
>
> P.S.
> I apologize for the formatting, it seems my emails are not making it to
> the list when I attempt to send them from my mail server so I had to copy
> this response in to the web form.  I would like to figure out why if
> possible.
> *9fans * / 9fans / see discussions
>  + participants
>  + delivery options
>  Permalink
> 
>

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

Re: [9fans] cmdline.txt for RPi 4 with QHD screen

[taylor . garry]

Hi Brian, 
Thanks for your help, does it make a difference that I'm using 9front? I don't 
even seem to have a /sys/lib/firmware directory, and I'm not sure I have a 
ether4330.c either. 

I'm sure it's obvious, but I'm a newcomer to Plan 9 and I apologise in advance 
if I'm missing obvious things.

Thanks

Garry
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T42a55b55ffb81417-Mbf9496cfdbfc3fb8ad314f25
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] cmdline.txt for RPi 4 with QHD screen

[Brian L. Stuart]

 I haven't had any trouble with wifi on the 4, with one caveat.  The 400 (and 
maybe some of the later 4s) have an updated version of the radio.  It just 
takes a new entry in ether4330.c and new blobs in /sys/lib/firmware.  The entry 
I've got in my ether4330.c is:
    { 0x4345, 9, "brcmfmac43456-sdio.bin", "brcmfmac43456-sdio.txt", 
"brcmfmac43456-sdio.clm_blob" },

and the files named there are the ones I added to /sys/lib/firmware.
BLS


On Saturday, April 6, 2024 at 01:33:46 AM UTC,  
wrote:  
 
 That's great, now I just need to get wifi to work... I can't get a definitive 
answer on RPi 4 wifi is even supported.9fans / 9fans / seediscussions 
+participants +delivery optionsPermalink  
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T42a55b55ffb81417-M5332574c9fdef8908ac6b551
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] openat()

[moody]

My two cents on this:

What you _would_ want for this would be the ability to walk from the existing 
fd, however the limits of 9p walk make this a bit impossible to implement in a 
great way in my opinion. From walk(5):

The fid must represent a directory unless zero path name elements(for just 
cloning the fid) are specified. The fid must be valid in the current session 
and must not have been opened for I/O by an open or create message.

Since not every fid is eligible for being walked from, in order to implement 
opanat() in any way that would be better than just batching the fd2path and 
open would be to keep a "last directory" associated, like what we do with the 
string used to open it. Also worth mentioning that fd2path is not without its 
own problems, it's possible that the namespace has changed since the file has 
been opened so the same path may not work the second time. So tagging the last 
directory Chan would be "more correct", but I am not sure how useful this is.

Answering some other comments made:
> As I understand it from the rationale section on the
 linux man page, the call exists to avoid a race condition between 
checking that a directory exists and doing something to a path 
containing it. An additional motivator is providing the effect of 
additional current working directories notably for Linux threads (which 
presumably don't have their own. I think 'threads'  (processes that 
share memory) on Plan 9 do???).

Each process has it's own current working directory:

% pwd
/home/moody
% @{cd /}
% pwd
% /home/moody
> This is all based on the assumption that holding a file/directory open keeps 
> it alive and in existence... which on Plan 9, I think it doesn't, does it? As 
> I understand it, remove can remove a file or directory that is open, which is 
> not like UNIX/Linux...
> 

Depends on the file server implementation, I find that for more synthetic files 
they are indeed kept alive as long there is someone with a reference to the fid.
This is identifiable if all the cleanup happens on clunks(destroyfid in lib9p), 
which only happen when a fid's refcount hits zero.

For non-synthetic or more "disk" file servers the behavior can differ. Cwfs 
does not keep the data around, readers that attempt to read a deleted file, 
even if they already have a reference open to it will result in a phase error. 
However 9front's ramfs keeps the data around.



My test for this was as follows:
win1% echo 'something' >/tmp/test
win2% https://9fans.topicbox.com/groups/9fans/T675e737e776e5a9c-M8abb414d4890eefbbbe7ef96
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] cmdline.txt for RPi 4 with QHD screen

[taylor . garry]

That's great, now I just need to get wifi to work... I can't get a definitive 
answer on RPi 4 wifi is even supported.
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T42a55b55ffb81417-M0bb93f82eedab10f21146c19
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] openat()

[Gorka Guardiola]

On Fri, Apr 5, 2024, 23:49 Alyssa M via 9fans <9fans@9fans.net> wrote:

> Are you thinking narrowly about "What changes to the Plan 9 kernel would
> you make to emulate the Linux openat() system call" or more generally about
> "How would you design a facility for plan 9 that provides an equivalent
> service?
>

Yes, this is what I understood between my first answer and the second. You
don't want to rewalk the path and you already have the fid with the
directory part walked in the chan of dirfd. I think that if you walk the
remaining path from that chan (cloning it) you preserve the same guarantees
provided by openat.



> As I understand it from the rationale section on the linux man page, the
> call exists to avoid a race condition between checking that a directory
> exists and doing something to a path containing it. An additional motivator
> is providing the effect of additional current working directories notably
> for Linux threads (which presumably don't have their own. I think
> 'threads'  (processes that share memory) on Plan 9 do???).
>
> This is all based on the assumption that holding a file/directory open
> keeps it alive and in existence... which on Plan 9, I think it doesn't,
> does it? As I understand it, remove can remove a file or directory that is
> open, which is not like UNIX/Linux...
>
> Sorry, I'm just trying to understand the question.
>
>
> *9fans * / 9fans / see discussions
>  + participants
>  + delivery options
>  Permalink
> 
>

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

Re: [9fans] openat()

[Alyssa M via 9fans]

Are you thinking narrowly about "What changes to the Plan 9 kernel would you 
make to emulate the Linux openat() system call" or more generally about "How 
would you design a facility for plan 9 that provides an equivalent service?

As I understand it from the rationale section on the linux man page, the call 
exists to avoid a race condition between checking that a directory exists and 
doing something to a path containing it. An additional motivator is providing 
the effect of additional current working directories notably for Linux threads 
(which presumably don't have their own. I think 'threads'  (processes that 
share memory) on Plan 9 do???).

This is all based on the assumption that holding a file/directory open keeps it 
alive and in existence... which on Plan 9, I think it doesn't, does it? As I 
understand it, remove can remove a file or directory that is open, which is not 
like UNIX/Linux...

Sorry, I'm just trying to understand the question.


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

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: [9fans] openat()

[ron minnich]

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-M0445ed55bee993d4cfbd3450
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] openat()

[Gorka Guardiola]

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-M43026122c2960e83ab07e80b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] openat()

[Gorka Guardiola]

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-M0fdda14083bc18f0e59c774f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] openat()

[Gorka Guardiola]

¿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-M9023f4cd7b382f26249c302b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] openat()

[ron minnich]

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
Permalink: 
https://9fans.topicbox.com/groups/9fans/T675e737e776e5a9c-Mf6adaa9f7c07518efcb7a293
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] 9legacy Raspberry Pi HDMI video questions

[slash 9fans]

I was able to remove the black border by appending the following lines to 
config.txt:

hdmi_group=2
hdmi_mode=82
hdmi_cvt=1920 1080 60 3 0 0 1
framebuffer_width=1920
framebuffer_height=1080
max_framebuffer_width=1920
max_framebuffer_height=1080

The lesson I learned was that the Pi needs to be physically powered off after 
making changes to the config file. ctrl-t ctrl-t r is not sufficient.

/


> On 5. Apr 2024, at 16.33, slash 9fans  wrote:
> 
> Dear 9fans,
> 
> I am booting my Raspberry Pi 4B off the 9legacy SD card image 
> (http://www.9legacy.org/download.html) and it boots fine with the default 
> config.txt, but there is a 48-pixel wide black border on the screen.
> 
> term% echo `{ dd -if /dev/screen -bs 64 -count 1}
> 0+1 records in
> 0+1 records out
> r5g6b5 0 0 1824 984
> 
> The Pi is connected to a standard 1080p 60Hz monitor via HDMI. How can I get 
> rid of the black border i.e. expand the screen size to 1920x1080? If anyone 
> has accomplished this, could you share your config.txt? Also, how can I 
> enable 24bit colors? Thank you.
> 
> /
> 

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T3b1609b3926a2f19-M9826399302cb5bf55ac94e01
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription