> 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
Okey, thanks
-marco
--
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/T798ae549700d1ad5-Mdd2b243c924cccbf1b83646c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
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
> 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:
> 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
> 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
--
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
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
>
> 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:
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
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
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
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
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
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
>
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
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
> 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
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:
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
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
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
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.
> 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
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
> ...
> 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
26 matches
Mail list logo
