9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* [9fans] p9f mention of 9front
@ 2021-06-23 19:11 hiro
  2021-06-23 23:05 ` unobe
  0 siblings, 1 reply; 31+ messages in thread
From: hiro @ 2021-06-23 19:11 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

i think it would help many new potential users if 9front was at least
mentioned (maybe near the link to 9legacy)

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T523d6e906a17a7cc-Mc3ceb771617eacde8227343d
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [9fans] p9f mention of 9front
  2021-06-23 19:11 [9fans] p9f mention of 9front hiro
@ 2021-06-23 23:05 ` unobe
  2021-06-23 23:35   ` Sigrid Solveig Haflínudóttir
  2021-06-24 11:19   ` hiro
  0 siblings, 2 replies; 31+ messages in thread
From: unobe @ 2021-06-23 23:05 UTC (permalink / raw)
  To: 9fans

Quoth hiro <23hiro@gmail.com>:
> i think it would help many new potential users if 9front was at least
> mentioned (maybe near the link to 9legacy)

To begin with, I only run 9front, a fork of Plan 9.  In my experience
it's just enough different from Plan 9 from Bell Labs that it cannot
be grouped with any releases of Plan 9 from Bell Labs with just a
series of patches (as can 9legacy).  However, I hope that this
situation doesn't remain and that whoever is in charge of the
Foundation and 9front can work to figure out how to make it so there's
one distribution.  That might be a pipe dream.  Maybe that's already
happening behind the scenes but my inner pessimist is saying "No."
There appear to be entrenched philosophical differences, but both
"sides" agree that 9front is a fork and 9legacy isn't (one point of
view is described @ http://9legacy.org/intro.html and the other is @
http://fqa.9front.org/fqa0.html#0.1 ).

So given that 9front is a fork, I don't think that the link to 9front
should be mentioned next to 9legacy which is under the "Download"
section.  That appears to be mainly for Bell Labs-related releases.
rmiller's rpi4 is really just implementing a kernel for rpi4, but
otherwise the rest of the system is left untouched.  I think (but do
not know for certain) that 9legacy and the rpi4 source links will go
away when there's a new release.

Instead of under "Download", the link for 9front should at least be
placed under the "Related Resources" section.  In my understanding,
the Foundation is limiting itself to focusing on what came out of Bell
Labs and not different systems that have heavily modified it since.
For example, I don't see HarveyOS, 9atom, Akaros, JehanneOS, NIX, Plan
B, or Clive are linked either.  Yet all of those I could see as being
listed under "Related Resources".  I actually like the listing and
short descriptions found at http://fqa.9front.org/fqa0.html#0.1 (under
"The United States of Plan 9").  With a few minor wording changes,
how about using that list?


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T523d6e906a17a7cc-M19aca5ea58732c93b8700201
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [9fans] p9f mention of 9front
  2021-06-23 23:05 ` unobe
@ 2021-06-23 23:35   ` Sigrid Solveig Haflínudóttir
  2021-06-23 23:58     ` Romano
  2021-06-24 11:19   ` hiro
  1 sibling, 1 reply; 31+ messages in thread
From: Sigrid Solveig Haflínudóttir @ 2021-06-23 23:35 UTC (permalink / raw)
  To: 9fans, unobe, 9fans

Correct me if I'm wrong, but I don't think anyone had any issues with 9legacy taking functionality from 9front, vice versa. So both contain parts of each other anyway. How is 9legacy "more Plan 9", but 9front isn't at all, then? Makes no sense to me.

Would a mention of a practical fork/distribution/whatever-you-wanna-call-it really hurt someone's ego that much?

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T523d6e906a17a7cc-M9ef7044854cc86fce96a1896
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [9fans] p9f mention of 9front
  2021-06-23 23:35   ` Sigrid Solveig Haflínudóttir
@ 2021-06-23 23:58     ` Romano
  2021-06-24  4:06       ` Lucio De Re
  0 siblings, 1 reply; 31+ messages in thread
From: Romano @ 2021-06-23 23:58 UTC (permalink / raw)
  To: 9fans

Quoth Sigrid Solveig Haflínudóttir <ftrvxmtrx@gmail.com>:
> Correct me if I'm wrong, but I don't think anyone had any issues with 9legacy taking functionality from 9front, vice versa. So both contain parts of each other anyway.
> 
> How is 9legacy "more Plan 9", but 9front isn't at all, then? Makes no sense to me.

Yeah, I don't think there are any issues with cross fertilization of
ideas or code.  But I don't think that means they're then equivalent.
But a fork is different than set of patches.  When 9front is
self-described as a fork of Plan 9 (from all accounts I've read),
isn't that separating from the Plan 9?  All the forks I can think of
off the top of my head (LibreSSL and BoringSSL from OpenSSL; OpenBSD
from NetBSD) certainly share code, but remain separate.  In the
latter, I can think of PF that was incorporated into NetBSD from
OpenBSD even after the fork.  Isn't that similar to what you're
describing?

> Would a mention of a practical fork/distribution/whatever-you-wanna-call-it really hurt someone's ego that much?

I don't know the answer to that question: it's not my ego.  But from
what I have read on this list it's not just ego that is involved.

As I wrote in my last e-mail, I want 9front to be listed on the
p9f.org page.  But I'm a nobody, so I'm probably not going to persuade
anyone.


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T523d6e906a17a7cc-Mae74961461cbd11cc116c9ee
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [9fans] p9f mention of 9front
  2021-06-23 23:58     ` Romano
@ 2021-06-24  4:06       ` Lucio De Re
  2021-06-24  4:56         ` unobe
  2021-06-24  8:24         ` Frank D. Engel, Jr.
  0 siblings, 2 replies; 31+ messages in thread
From: Lucio De Re @ 2021-06-24  4:06 UTC (permalink / raw)
  To: 9fans

Eish! I really can't resist, can I?

On 6/24/21, Romano <unobe@cpan.org> wrote:
> [...]  But I'm a nobody, so I'm probably not going to persuade
> anyone.
>
Let me try and keep this short, but it won't be easy.

Firstly, this is not intended as an offence, particularly against
Romano, it is merely an alert against our poorly understood "human
nature".

The sentiment implied in the sentence above is a bare-faced lie.
Romano, you need not defend it, I utter lies like this daily, multiple
times, and I spend my time mostly in solitude :-).

Thing is, we try hard to be tactful or diplomatic and fail to be
convincing because we don't actually know how to respond to similar
falsehoods directed at us. My own problem is that I have no scientific
foundations for what follows, only personal experience in a context
where multiple natural "languages" flow freely and misunderstandings
are more the norm than the exception. Here, we continue to pay a high
price for not having resolved this madness at birth.

9front got off on a bad footing, in my recollection more a
generational clash than anything caused by one or more technical
issue. Repairing the burnt bridges requires undoing all the antagonism
that has been accumulated since, plus more than just a smidgen of
technical savvy.

But the emotional need for approval did lead to acrimony and acrimony
led to the eventual 9 fork and today one can still run 2Ed
applications on 9legacy (bar occasional mishaps - not that I can think
of any), but not 9front applications without modification. That, is a
very clear ring-fence. And it makes me quite sad, but realistically,
it would take quite a lot of tolerance, effort and time to merge the
two streams and something would undoubtably be lost in the process of
compromising. Not least, there would be ego damage (I have my own
skeletons I would not want to release from the cupboard next to the
one implied above).

The point of the above is simple: only a neutral party can put
Plan/9/Front together again and there are more pressing issues for the
average participant to address that stand firmly in the way. Harping
on the politics is the wrong thing to do, eventually survival of the
fittest is going to dictate the path that will be taken. And the
fittest, accidentally or intentionally, in the current ecosystem, in
my opinion is plan9port, at least until Torvalds stops dictating the
path Linux takes: our culture can't resist a strong personality
(that's the "cult" in "culture"), but also cannot survive without
continuity, surprise, surprise.

The democracy that may favour intellect over emotion needs to be an
artifact able to adjust to changing contexts, consciously. The Plan 9
Foundation may or may not have that in its genome. Miller is a
reminder that a port to a different architecture is the product of
both individual genius (and, yes, Cinap does that, also, I don't mean
to be disrespectful) and sound foundations.

What Plan 9 needs is a Nemo to redo his analysis of 3Ed and offer a
more modern version focused on Plan 9 as the glue between the
MS-Windows/Apple user interface (based on a perceived and certainly
not genuine security) and the scrappy Turing machines Intel and
co-conspirators are foisting on us. And to be ready for the next
generation of hardware that may prevent this generation producing an
Atlantis-sized civilisation collapse. Of course, that's not to suggest
this must be Nemo's retirement package, it means that the right
calibre of humans must undertake to perform such an analysis to its
completion.

Lucio.

PS: I would have liked to bring Minix-3 into the rant above, but I
have yet to explore to my satisfaction what it really represents.
Suffice it to say that it may be able to run p9p and that is rather an
interesting curved ball.

The other oddity is the smart mobile computer we like to call a
"phone". Why is there no Plan 9 flavour running on at least some
flavour of it?

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T523d6e906a17a7cc-Me1fe9703569c5c6466229207
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [9fans] p9f mention of 9front
  2021-06-24  4:06       ` Lucio De Re
@ 2021-06-24  4:56         ` unobe
  2021-06-24  5:52           ` Lucio De Re
  2021-06-24  8:24         ` Frank D. Engel, Jr.
  1 sibling, 1 reply; 31+ messages in thread
From: unobe @ 2021-06-24  4:56 UTC (permalink / raw)
  To: 9fans

Quoth Lucio De Re <lucio.dere@gmail.com>:
> On 6/24/21, Romano <unobe@cpan.org> wrote:
> > [...]  But I'm a nobody, so I'm probably not going to persuade
> > anyone.
> >
> Let me try and keep this short, but it won't be easy.
> 
> Firstly, this is not intended as an offence, particularly against
> Romano, it is merely an alert against our poorly understood "human
> nature".
> 
> The sentiment implied in the sentence above is a bare-faced lie.
> Romano, you need not defend it, I utter lies like this daily, multiple
> times, and I spend my time mostly in solitude :-).

No offence taken. I don't agree with you.


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T523d6e906a17a7cc-M7b83cd0b11919bf0a20f7df1
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [9fans] p9f mention of 9front
  2021-06-24  4:56         ` unobe
@ 2021-06-24  5:52           ` Lucio De Re
  2021-06-24 21:25             ` Wes Kussmaul
  0 siblings, 1 reply; 31+ messages in thread
From: Lucio De Re @ 2021-06-24  5:52 UTC (permalink / raw)
  To: 9fans

On 6/24/21, unobe@cpan.org <unobe@cpan.org> wrote:
> Quoth Lucio De Re <lucio.dere@gmail.com>:
>> On 6/24/21, Romano <unobe@cpan.org> wrote:
>> > [...]  But I'm a nobody, so I'm probably not going to persuade
>> > anyone.
>> >
>> [ ... ]
>>
>> The sentiment implied in the sentence above is a bare-faced lie.
>> Romano, you need not defend it, I utter lies like this daily, multiple
>> times, and I spend my time mostly in solitude :-).
>
> No offence taken. I don't agree with you.
>
Well, that was easier than expected :-)

Thank you for the assurance.

Lucio.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T523d6e906a17a7cc-Mf6dbc0868d718f85449007cb
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [9fans] p9f mention of 9front
  2021-06-24  4:06       ` Lucio De Re
  2021-06-24  4:56         ` unobe
@ 2021-06-24  8:24         ` Frank D. Engel, Jr.
  2021-06-24  9:25           ` [9fans] plan9 and touch screens Richard Miller
  2021-06-24 10:12           ` [9fans] p9f mention of 9front Philip Silva via 9fans
  1 sibling, 2 replies; 31+ messages in thread
From: Frank D. Engel, Jr. @ 2021-06-24  8:24 UTC (permalink / raw)
  To: 9fans

I don't think the touchscreen technology has figured out how to 
distinguish between fingers yet.

The rio environment would need to identify if you were using finger 1, 2 
or 3 to tap on something so it would know if it was to move or resize 
the window, which context menu to open, etc...

Either that or you would need to replace rio with something more 
touchscreen-friendly, in the process losing much of what makes the Plan 
9 environment as unique as it is from a user interface perspective.

Most "modern" phones also lack a suitable keyboard to provide reasonable 
interaction with the command line (and it can be difficult to type 
efficiently on something that small anyway).


On 6/24/21 12:06 AM, Lucio De Re wrote:
> The other oddity is the smart mobile computer we like to call a
> "phone". Why is there no Plan 9 flavour running on at least some
> flavour of it?

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T523d6e906a17a7cc-M84bef267275597c3ab44884a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 31+ messages in thread

* [9fans] plan9 and touch screens
  2021-06-24  8:24         ` Frank D. Engel, Jr.
@ 2021-06-24  9:25           ` Richard Miller
  2021-06-24  9:59             ` Lucio De Re
  2021-06-24 10:12           ` [9fans] p9f mention of 9front Philip Silva via 9fans
  1 sibling, 1 reply; 31+ messages in thread
From: Richard Miller @ 2021-06-24  9:25 UTC (permalink / raw)
  To: 9fans

fde101@fjrhome.net:
> Either that or you would need to replace rio with something more 
> touchscreen-friendly, in the process losing much of what makes the Plan 
> 9 environment as unique as it is from a user interface perspective.
> 
> Most "modern" phones also lack a suitable keyboard to provide reasonable 
> interaction with the command line (and it can be difficult to type 
> efficiently on something that small anyway).

Inferno can work quite comfortably with a touchscreen and a virtual
"bitsy" keyboard. It's a different user interface from rio, but not
horribly worse. Likely Plan 9 could be adapted to do the same.


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T93744379e79c6971-M02879a98ecf562634ea3842d
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [9fans] plan9 and touch screens
  2021-06-24  9:25           ` [9fans] plan9 and touch screens Richard Miller
@ 2021-06-24  9:59             ` Lucio De Re
  0 siblings, 0 replies; 31+ messages in thread
From: Lucio De Re @ 2021-06-24  9:59 UTC (permalink / raw)
  To: 9fans

On 6/24/21, Richard Miller <9fans@hamnavoe.com> wrote:
> Inferno can work quite comfortably with a touchscreen and a virtual
> "bitsy" keyboard. It's a different user interface from rio, but not
> horribly worse. Likely Plan 9 could be adapted to do the same.
>
And handwriting may have been discarded in the recent past, but it can
be brought back if, say, speech recognition won't work.

We've moved on and Plan 9 can catch up. If not, then I think
obsolescence looms large. But I don't think so, I think it just needs
the ability to absorb lessons from the ecosystem.

Lucio.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T93744379e79c6971-M5fa24cba9e3d66a7f8ff253a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [9fans] p9f mention of 9front
  2021-06-24  8:24         ` Frank D. Engel, Jr.
  2021-06-24  9:25           ` [9fans] plan9 and touch screens Richard Miller
@ 2021-06-24 10:12           ` Philip Silva via 9fans
  2021-06-24 16:05             ` unobe
  2021-06-24 16:16             ` Ethan Gardener
  1 sibling, 2 replies; 31+ messages in thread
From: Philip Silva via 9fans @ 2021-06-24 10:12 UTC (permalink / raw)
  To: 9fans

I wonder if this could be copied from how plan9port behaves on macOS for instance. Using a single tap and then toggling/chording using alt and command keys. Maybe on a multi-touch input the distance of the 2nd and 3rd finger could help to identify which modifier/button it translates to.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

Frank D. Engel, Jr. <fde101@fjrhome.net> schrieb am Donnerstag, 24. Juni 2021 um 10:24:

> The rio environment would need to identify if you were using finger 1, 2
>
> or 3 to tap on something so it would know if it was to move or resize
>

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T523d6e906a17a7cc-Ma226d19a1eea70cb2dc82b62
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [9fans] p9f mention of 9front
  2021-06-23 23:05 ` unobe
  2021-06-23 23:35   ` Sigrid Solveig Haflínudóttir
@ 2021-06-24 11:19   ` hiro
  2021-06-24 15:01     ` AW: " sirjofri
  2021-06-24 20:51     ` unobe
  1 sibling, 2 replies; 31+ messages in thread
From: hiro @ 2021-06-24 11:19 UTC (permalink / raw)
  To: 9fans

> Foundation and 9front can work to figure out how to make it so there's
> one distribution.

For 9front this doesn't matter so much. We do not have a problem with
there being multiple (sometimes experimental) distributions. For
non-experimental things like 9legacy and miller's rpi releases, we're
already benefiting from each other and sharing code without any
issues.

> There appear to be entrenched philosophical differences, but both
> "sides" agree that 9front is a fork and 9legacy isn't (one point of
> view is described @ http://9legacy.org/intro.html and the other is @
> http://fqa.9front.org/fqa0.html#0.1 ).

I disagree here.

When 9front was created it was technically a fork, because there was
still a diverging bell-labs plan 9 distribution.

We may seem to have new non-accreditated "management", but we are all
fascinated what Plan 9 brought to this world and we would all like to
build on the general wisdom of the Plan 9 philosophy.

Now that bell-labs is gone, there have been no more mainline plan9 releases.

Instead we have a few remaining relevant distributions like 9legacy or
miller's rpi releases, all of which technically are about as much a
fork as 9front is.

Erik's 9atom has been unmaintained for a longer time so we didn't have
any problems following those patches.

Harvey and related distributions are highly experimental, they diverge
much further from Plan 9 basic architecture without any will of
keeping backwards compatibility.
They are more revolutionary than some of us can stomach.

A lot of people from the old crew at bell-labs completely abandoned
mainline bell-labs plan9 even before 9front has been started because
they seem content with just having a p9p layer on top of their
macbooks or other unix machines.

Apart from the occasional trolling that keeps on coming up on this
list, I don't see what deep trenches people are imagining would impair
the Plan 9 Community from working together on a well maintained Plan 9
distribution with simple procedures for sharing code in all
directions. Whose wrong foot did you suffer from when 9front got first
made?

The few remaining people that actually care about collaborating
together and keeping Plan 9 alive as a proper operating system running
on real hardware, please add your views in case I am ignoring some
other side of all this.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T523d6e906a17a7cc-M439abc986009d978dc66f867
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 31+ messages in thread

* AW: [9fans] p9f mention of 9front
  2021-06-24 11:19   ` hiro
@ 2021-06-24 15:01     ` sirjofri
  2021-06-24 20:51     ` unobe
  1 sibling, 0 replies; 31+ messages in thread
From: sirjofri @ 2021-06-24 15:01 UTC (permalink / raw)
  To: 9fans

Hello all,

Klong mail incoming. I hope my English is ok and I don't tread on other's 
toes.)

from my perspective it looks like this:

There are multiple Plan 9 forks kor distributions). They all are 
philosophically and technically different, but they still share patches 
(even if many people don't know). This is fine.

It would be great to have some kind of compatibility. i'm not necessarily 
talking about binary/ABI compatibility, but network compatibility, shell 
scripting and usability. People are actively working on it. I personally 
have no reason to run 9legacy in my network since 9front has everything I 
need, but other people do.

The community is split into multiple different areas. Some areas are open 
to communicate with others, some actively work together and some are very 
"unique": you don't really hear from them in most channels, besides some 
email here and there, but that's it.

I can name #cat-v, #plan9, ##9fans (bridged to discord) and the 9fans and 
9front mailing lists.

P9f is some very special case: They have the rights to the original 
codebase, they stare noble goals, but they seem to actively hide the fact 
that 9front exists. Hardcore 9front people don't really care about that, 
but the community (and I) do. I consider it really sad that 9front seems 
so cut away from the Plan 9 history just because some people try to hide 
it. Many people asked about mentioning 9front on the p9f page.

When p9f started they told us that they focus on more important stuff 
first (which I can totally understand). Some activities (also mentioned 
at 9front.org/who/p9f) make me think that they just don't want 9front to 
exist.

They state they want to push all stuff in the plan 9 family (9p, plan9 
with forks, inferno), but they seem to actively promote 9legacy (which is 
fine, it's the most original continuation of plan9) and hide 9front 
(which is just sad). This is especially sad since 9front is probably the 
most modern and most active Plan 9 system currently existing.

I just hope we all find a way to still respect each other and to grow as 
a community. Misunderstandings happen as well as lots of other human 
factors.

My long 2 cents

sirjofri

Disclaimer: I actively used the original Plan 9 4e, Plan 9 on rpi, 
inferno, and I am an active 9front user.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T523d6e906a17a7cc-M0a6e0197e217adff3f184fd7
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [9fans] p9f mention of 9front
  2021-06-24 10:12           ` [9fans] p9f mention of 9front Philip Silva via 9fans
@ 2021-06-24 16:05             ` unobe
  2021-06-24 16:16             ` Ethan Gardener
  1 sibling, 0 replies; 31+ messages in thread
From: unobe @ 2021-06-24 16:05 UTC (permalink / raw)
  To: 9fans

Quoth Philip Silva via 9fans <9fans@9fans.net>:
> I wonder if this could be copied from how plan9port behaves on macOS for instance. Using a single tap and then toggling/chording using alt and command keys. Maybe on a multi-touch input the distance of the 2nd and 3rd finger could help to identify which modifier/button it translates to.

What I did with my Pinephone, but not run directly.  I ran drawterm.
I mapped the hardware vol up/down buttons to buttons 2&3.  That gave
me some chording ability (with 1-2 and 1-3), and simple keypresses for
2 & 3 (no swiping with 2, or swiping with 3).  It didn't seem too odd.


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T523d6e906a17a7cc-Mbe4fa7cadb978896acecdb8d
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [9fans] p9f mention of 9front
  2021-06-24 10:12           ` [9fans] p9f mention of 9front Philip Silva via 9fans
  2021-06-24 16:05             ` unobe
@ 2021-06-24 16:16             ` Ethan Gardener
  1 sibling, 0 replies; 31+ messages in thread
From: Ethan Gardener @ 2021-06-24 16:16 UTC (permalink / raw)
  To: 9fans

On Thu, Jun 24, 2021, at 11:12 AM, Philip Silva via 9fans wrote:
> I wonder if this could be copied from how plan9port behaves on macOS 
> for instance. Using a single tap and then toggling/chording using alt 
> and command keys. Maybe on a multi-touch input the distance of the 2nd 
> and 3rd finger could help to identify which modifier/button it 
> translates to.

Doesn't P9P do something more than this on macOS already? I recall something about some multitouch arrangements as a replacement for chords. Some pro users liked it very much, but I've forgotten what the arrangements were. Caveat: it might have been optimized for Acme only.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T523d6e906a17a7cc-M959527dd82998773b268d056
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [9fans] p9f mention of 9front
  2021-06-24 11:19   ` hiro
  2021-06-24 15:01     ` AW: " sirjofri
@ 2021-06-24 20:51     ` unobe
  2021-06-25  8:28       ` Steve Simon
  2021-06-26  8:34       ` [9fans] p9f mention of 9front Ethan Gardener
  1 sibling, 2 replies; 31+ messages in thread
From: unobe @ 2021-06-24 20:51 UTC (permalink / raw)
  To: 9fans

Quoth hiro <23hiro@gmail.com>:
> > Foundation and 9front can work to figure out how to make it so there's
> > one distribution.
> 
> For 9front this doesn't matter so much. We do not have a problem with
> there being multiple (sometimes experimental) distributions. For
> non-experimental things like 9legacy and miller's rpi releases, we're
> already benefiting from each other and sharing code without any
> issues.

So perhaps I should have said 'one code base under version control',
not 'distributions'.  That is, have a master branch and different
branches for experimental things and for formal releases.  I think
getting 9front onto git is a good push forward in that direction,
since the Plan 9 is released by P9F under the MIT license from git,
too.

> > There appear to be entrenched philosophical differences, but both
> > "sides" agree that 9front is a fork and 9legacy isn't (one point of
> > view is described @ http://9legacy.org/intro.html and the other is @
> > http://fqa.9front.org/fqa0.html#0.1 ).
> 
> I disagree here.
> 
> When 9front was created it was technically a fork, because there was
> still a diverging bell-labs plan 9 distribution.
> 
> We may seem to have new non-accreditated "management", but we are all
> fascinated what Plan 9 brought to this world and we would all like to
> build on the general wisdom of the Plan 9 philosophy.
> 
> Now that bell-labs is gone, there have been no more mainline plan9 releases.
> 
> Instead we have a few remaining relevant distributions like 9legacy or
> miller's rpi releases, all of which technically are about as much a
> fork as 9front is.
> 
> Erik's 9atom has been unmaintained for a longer time so we didn't have
> any problems following those patches.
> 
> Harvey and related distributions are highly experimental, they diverge
> much further from Plan 9 basic architecture without any will of
> keeping backwards compatibility.
> They are more revolutionary than some of us can stomach.
> 
> A lot of people from the old crew at bell-labs completely abandoned
> mainline bell-labs plan9 even before 9front has been started because
> they seem content with just having a p9p layer on top of their
> macbooks or other unix machines.
> 
> Apart from the occasional trolling that keeps on coming up on this
> list, I don't see what deep trenches people are imagining would impair
> the Plan 9 Community from working together on a well maintained Plan 9
> distribution with simple procedures for sharing code in all
> directions. Whose wrong foot did you suffer from when 9front got first
> made?

For one, not having fossil.  The removal of fossil might be what some
users cannot accept?  The setup and wiki preserved at 9p.io talk about
how to setup fossil+venti and yet that cannot be done on 9front--it
was removed completely.  I think I recall you saying it was bug-ridden
and unmaintainable, but could be misremembering who said what.  From
what I can gather, there was a serious bug that was fixed in fossil
after 9front forked, and yet there is no intention of including it
back into 9front.

Additionally, I didn't realize initially that there was only one
kernel for both cpu and terminal in 9front, as opposed to two in Plan
9.  (I like that there's only one, personally.) That makes a
difference because of the documentation in each system on how to setup
a server.

Those are two things that I can think of off the top of my head.

Philosophically, I think the 9front maintainers/developers are much
more willing to chuck older code and to replace with new code.  I have
personally benefitted from this approach so I'm not against it.
9legacy is much more conservative.


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T523d6e906a17a7cc-Ma33a7ff5d2238a0c5a82a824
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [9fans] p9f mention of 9front
  2021-06-24  5:52           ` Lucio De Re
@ 2021-06-24 21:25             ` Wes Kussmaul
  2021-06-24 23:29               ` silas poulson
  0 siblings, 1 reply; 31+ messages in thread
From: Wes Kussmaul @ 2021-06-24 21:25 UTC (permalink / raw)
  To: 9fans

[-- Attachment #1: Type: text/plain, Size: 338 bytes --]


All versions of Plan9, Inferno, derivatives, forks, et al are welcome on 
the Glenda continent.






------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T523d6e906a17a7cc-Ma32a526a9ee3953b55afcc24
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2.1: Type: text/html, Size: 1007 bytes --]

[-- Attachment #2.2: hpicgebfckhdkaia.png --]
[-- Type: image/png, Size: 27590 bytes --]

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [9fans] p9f mention of 9front
  2021-06-24 21:25             ` Wes Kussmaul
@ 2021-06-24 23:29               ` silas poulson
  2021-06-25 13:06                 ` Wes Kussmaul
  0 siblings, 1 reply; 31+ messages in thread
From: silas poulson @ 2021-06-24 23:29 UTC (permalink / raw)
  To: 9fans

[-- Attachment #1: Type: text/plain, Size: 850 bytes --]

What’s Dorren continent referencing?

Silas

On 24 Jun 2021, at 22:25, Wes Kussmaul <wes@ReliableID.com<mailto:wes@ReliableID.com>> wrote:



All versions of Plan9, Inferno, derivatives, forks, et al are welcome on the Glenda continent.

<hpicgebfckhdkaia.png>





9fans<https://9fans.topicbox.com/latest> / 9fans / see discussions<https://9fans.topicbox.com/groups/9fans> + participants<https://9fans.topicbox.com/groups/9fans/members> + delivery options<https://9fans.topicbox.com/groups/9fans/subscription> Permalink<https://9fans.topicbox.com/groups/9fans/T523d6e906a17a7cc-Ma32a526a9ee3953b55afcc24>


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T523d6e906a17a7cc-M7b4febdc7dfcb5246fa8f366
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 1621 bytes --]

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [9fans] p9f mention of 9front
  2021-06-24 20:51     ` unobe
@ 2021-06-25  8:28       ` Steve Simon
  2021-06-25  9:31         ` Richard Miller
  2021-06-26  8:34       ` [9fans] p9f mention of 9front Ethan Gardener
  1 sibling, 1 reply; 31+ messages in thread
From: Steve Simon @ 2021-06-25  8:28 UTC (permalink / raw)
  To: 9fans

I think there where two reported issues with fossil.

On was a bug in ephermerial shapshots which could cause it to crash,
this was fixed about 10 years ago but did exist for an embarassingly long time.

The other was a design decision rather than a bug which was not well
communicated. Fossil was designed as a write buffer to be used in
conjunction with venti. It could operate as a stand alone filesystem
to replace the single user kfs.

However if fossil fills up - because more has been written to it than
it can hold or because snapshots have been turned on without a venti
attached, it will crash badly and can (I believe) lose user data.

The third issue with using fossil and venti is it is not very performant,
it was reasonable when it was written in the early 2000s but is slow
compared to modern Linux filesystems (I don't know how it compares to
cwfs or hjfs).

I have been using fossil and venti continuiously since 2004 and tend
to jump to its defence.

Re different kernels
As I have understood it (others may correct me) the difference between
cpu and terminal kernels is only the value one global variable (cpuserver)
in the kernel, and the list of drivers compiled in - traditionally there
was no graphics support in cpu kernels for example.

-Steve

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T523d6e906a17a7cc-M105752d0fa6af0e964b6b87f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [9fans] p9f mention of 9front
  2021-06-25  8:28       ` Steve Simon
@ 2021-06-25  9:31         ` Richard Miller
  2021-06-25 12:41           ` [9fans] full fossil follies Richard Miller
  0 siblings, 1 reply; 31+ messages in thread
From: Richard Miller @ 2021-06-25  9:31 UTC (permalink / raw)
  To: 9fans

steve@quintile.net:
> However if fossil fills up - because more has been written to it than
> it can hold or because snapshots have been turned on without a venti
> attached, it will crash badly and can (I believe) lose user data.

No, it won't lose data (except in the sense that incoming mail, for
example, can't be stored anywhere while the disk is full).  You can't
usually boot from a completely full fossil, but if you have a fallback
boot method (from a CD or USB drive, from a network, or a spare recovery
fossil partition) you can then start a fossil on the full partition, and
run snapclean and/or delete some files, and all will be well. Even if
fossil data was damaged, you could recover with flfmt from venti if you
had archiving turned on.

Also, nowadays it doesn't actually "crash" ... it just becomes difficult
to do anything when no fossil blocks can be allocated. If the fossil on
a networked server is full, you may not be able to log into it because
that would require some fossil blocks. But you can still recover from
a client terminal, by importing its /srv/fossil and using that to issue
a snapclean command, or a remove command to delete something.

> As I have understood it (others may correct me) the difference between
> cpu and terminal kernels is only the value one global variable (cpuserver)
> in the kernel, and the list of drivers compiled in - traditionally there
> was no graphics support in cpu kernels for example.

I have a version of the 4e kernel which functions as either cpu or terminal
depending on the setting of environment variable 'service' in plan9.ini or
cmdline.txt. It requires only a handful of lines to be added in
/sys/src/9/boot/boot.c to make that work. Nowadays kernel RAM is plentiful
enough that there's no real reason to configure different sets of devices
between terminal and cpu.


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T523d6e906a17a7cc-Md2b7a8425ae0681a784e7451
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 31+ messages in thread

* [9fans] full fossil follies
  2021-06-25  9:31         ` Richard Miller
@ 2021-06-25 12:41           ` Richard Miller
  2021-06-25 14:12             ` adr via 9fans
  0 siblings, 1 reply; 31+ messages in thread
From: Richard Miller @ 2021-06-25 12:41 UTC (permalink / raw)
  To: 9fans

> it just becomes difficult
> to do anything when no fossil blocks can be allocated

Thinking a bit further about this: intuitively one might expect to be
able to reboot using a local file system which is completely full, and
use du and ls to find big files and rm to delete them, without the need
to allocate new blocks. Something in the way fossil works, makes this
impossible at present. I wonder how much work it would be to investigate
and fix?



------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T4ec62ed03a91d7a4-Mdf35f73131f8dcb668365537
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [9fans] p9f mention of 9front
  2021-06-24 23:29               ` silas poulson
@ 2021-06-25 13:06                 ` Wes Kussmaul
  0 siblings, 0 replies; 31+ messages in thread
From: Wes Kussmaul @ 2021-06-25 13:06 UTC (permalink / raw)
  To: 9fans


On 6/24/21 7:29 PM, silas poulson wrote:
> What’s Dorren continent referencing?
>
There are three continents in the digital world

  * Montaigne
  * Dorren
  * Glenda

On the Montaigne continent, everything is done outdoors on the old 
information highway using these strange billboards called websites 
(pretty much the existing world);

On the Dorren continent, outdoor spaces are supplemented by secure 
indoor spaces called "buildings," built with PKI construction materials 
and PKIDR methods (e.g. occupancy permits);

On Glenda, the Plan9 assumptions prevail.



------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T523d6e906a17a7cc-M176398634e00d7431b515c56
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [9fans] full fossil follies
  2021-06-25 12:41           ` [9fans] full fossil follies Richard Miller
@ 2021-06-25 14:12             ` adr via 9fans
  2021-06-25 15:17               ` tlaronde
  0 siblings, 1 reply; 31+ messages in thread
From: adr via 9fans @ 2021-06-25 14:12 UTC (permalink / raw)
  To: 9fans

On Fri, Jun 25, 2021 at 01:41:30PM +0100, Richard Miller wrote:
> > it just becomes difficult
> > to do anything when no fossil blocks can be allocated
> 
> Thinking a bit further about this: intuitively one might expect to be
> able to reboot using a local file system which is completely full, and
> use du and ls to find big files and rm to delete them, without the need
> to allocate new blocks. Something in the way fossil works, makes this
> impossible at present. I wonder how much work it would be to investigate
> and fix?

I haven't studied how fossil works, so excuse this light chat.
Couldn't fossil have reserved blocks so when it starts and it's
full it can add those block and present the user to a recovery
session? Just a console session printing the last file modified?

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T4ec62ed03a91d7a4-M386580fb9170872f973a9995
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [9fans] full fossil follies
  2021-06-25 14:12             ` adr via 9fans
@ 2021-06-25 15:17               ` tlaronde
  2021-06-25 16:06                 ` adr via 9fans
  2021-06-25 17:23                 ` Iruatã Souza
  0 siblings, 2 replies; 31+ messages in thread
From: tlaronde @ 2021-06-25 15:17 UTC (permalink / raw)
  To: 9fans

On Fri, Jun 25, 2021 at 02:12:07PM +0000, adr via 9fans wrote:
> On Fri, Jun 25, 2021 at 01:41:30PM +0100, Richard Miller wrote:
> > > it just becomes difficult
> > > to do anything when no fossil blocks can be allocated
> > 
> > Thinking a bit further about this: intuitively one might expect to be
> > able to reboot using a local file system which is completely full, and
> > use du and ls to find big files and rm to delete them, without the need
> > to allocate new blocks. Something in the way fossil works, makes this
> > impossible at present. I wonder how much work it would be to investigate
> > and fix?
> 
> I haven't studied how fossil works, so excuse this light chat.
> Couldn't fossil have reserved blocks so when it starts and it's
> full it can add those block and present the user to a recovery
> session? Just a console session printing the last file modified?

I don't think I will tell anybody a scoop, but it is what is present in
traditional Unix filesystems where there is a percent of the storage
preserved... but for root, user under which you are not supposed to
log to the system in normal operation. This is probably the problem:
since there is no privileged user, for "whom" to preserve/reserve these
blocks?

I imagine the alternative would be, if fossil reports full, that memory
filesystems should be mounted on top of the system mandatory writable
dirs so that the system will not block but normal booting will not
be done but the program launched will be one requiring user to make
room, crucial infos written in memory filesystems being copied back
to fossil when done. But it is easier to implement when booting/rebooting,
but more problematic if the system is running. Except perhaps that
there will always be a memory filesystem mounted with rescue
programs/scripts that the user can precisely use when the system
is out of disk space, utilities that write nothing to disk (but just in
their memory realm), in order to not paint oneself in a corner.

FWIW,
-- 
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                    http://kertex.kergis.com/
                       http://www.sbfa.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T4ec62ed03a91d7a4-M6b1ac09a6f8c59ccbd5b2327
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [9fans] full fossil follies
  2021-06-25 15:17               ` tlaronde
@ 2021-06-25 16:06                 ` adr via 9fans
  2021-06-25 16:45                   ` adr via 9fans
  2021-06-25 17:23                 ` Iruatã Souza
  1 sibling, 1 reply; 31+ messages in thread
From: adr via 9fans @ 2021-06-25 16:06 UTC (permalink / raw)
  To: 9fans

On Fri, Jun 25, 2021 at 05:17:39PM +0200, tlaronde@polynum.com wrote:
> On Fri, Jun 25, 2021 at 02:12:07PM +0000, adr via 9fans wrote:
> > On Fri, Jun 25, 2021 at 01:41:30PM +0100, Richard Miller wrote:
> > > > it just becomes difficult
> > > > to do anything when no fossil blocks can be allocated
> > > 
> > > Thinking a bit further about this: intuitively one might expect to be
> > > able to reboot using a local file system which is completely full, and
> > > use du and ls to find big files and rm to delete them, without the need
> > > to allocate new blocks. Something in the way fossil works, makes this
> > > impossible at present. I wonder how much work it would be to investigate
> > > and fix?
> > 
> > I haven't studied how fossil works, so excuse this light chat.
> > Couldn't fossil have reserved blocks so when it starts and it's
> > full it can add those block and present the user to a recovery
> > session? Just a console session printing the last file modified?
> 
> I don't think I will tell anybody a scoop, but it is what is present in
> traditional Unix filesystems where there is a percent of the storage
> preserved... but for root, user under which you are not supposed to
> log to the system in normal operation. This is probably the problem:
> since there is no privileged user, for "whom" to preserve/reserve these
> blocks?

I don't think there is need of superuser concept here. What I'm
imagining, again, without having seen the source code, is something
like this:

The file system is formatted and data representing the structure of
the file system are stored normally.

At execution time, the file server check a flag stored in some
place to see if the system is full. If not, the data is changed so
the blocks are "hidden" and execution continues.

If the system is full, the file system starts a console session
presenting the last file edited. At the end of the session, if the
number of free blocks is bigger than the reserved blocks, the blocks are
"hidden" and execution continues. If not, the console session gives
an error and continues.

The flag can be turn on at the same place the error of file system
full is triggered.

Again, easy talk, I haven't studied the source and a lot of people
have said in this list that fossil is very complex. Some times the
complexity of a task results in a complex implementation. You can't
screw 1000 screws in a minute without a mechanical tool. What I
don't know jet is if the complexity of fossil match its features.
At least I can df all partitions...

adr.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T4ec62ed03a91d7a4-M010365538d976d3e3c89f274
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [9fans] full fossil follies
  2021-06-25 16:06                 ` adr via 9fans
@ 2021-06-25 16:45                   ` adr via 9fans
  2021-06-26  9:01                     ` Ethan Gardener
  0 siblings, 1 reply; 31+ messages in thread
From: adr via 9fans @ 2021-06-25 16:45 UTC (permalink / raw)
  To: 9fans

> I don't think there is need of superuser concept here. What I'm
> imagining, again, without having seen the source code, is something
> like this:
>
> The file system is formatted and data representing the structure of
> the file system are stored normally.
>
> At execution time, the file server check a flag stored in some
> place to see if the system is full. If not, the data is changed so
> the blocks are "hidden" and execution continues.
>
> If the system is full, the file system starts a console session
> presenting the last file edited. At the end of the session, if the
> number of free blocks is bigger than the reserved blocks, the blocks are
> "hidden" and execution continues. If not, the console session gives
> an error and continues.
>
> The flag can be turn on at the same place the error of file system
> full is triggered.

In a multi-user environment you can make the file system do something
similar when the system is full, but instead of starting a console
session, delete the last file modified and presenting the user
an error.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T4ec62ed03a91d7a4-M4987d580aea7ace04872c584
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [9fans] full fossil follies
  2021-06-25 15:17               ` tlaronde
  2021-06-25 16:06                 ` adr via 9fans
@ 2021-06-25 17:23                 ` Iruatã Souza
  2021-06-26  8:56                   ` Richard Miller
  1 sibling, 1 reply; 31+ messages in thread
From: Iruatã Souza @ 2021-06-25 17:23 UTC (permalink / raw)
  To: 9fans

[-- Attachment #1: Type: text/plain, Size: 2477 bytes --]

Le ven. 25 juin 2021 à 17:19, <tlaronde@polynum.com> a écrit :

> On Fri, Jun 25, 2021 at 02:12:07PM +0000, adr via 9fans wrote:
> > On Fri, Jun 25, 2021 at 01:41:30PM +0100, Richard Miller wrote:
> > > > it just becomes difficult
> > > > to do anything when no fossil blocks can be allocated
> > >
> > > Thinking a bit further about this: intuitively one might expect to be
> > > able to reboot using a local file system which is completely full, and
> > > use du and ls to find big files and rm to delete them, without the need
> > > to allocate new blocks. Something in the way fossil works, makes this
> > > impossible at present. I wonder how much work it would be to
> investigate
> > > and fix?
> >
> > I haven't studied how fossil works, so excuse this light chat.
> > Couldn't fossil have reserved blocks so when it starts and it's
> > full it can add those block and present the user to a recovery
> > session? Just a console session printing the last file modified?
>
> I don't think I will tell anybody a scoop, but it is what is present in
> traditional Unix filesystems where there is a percent of the storage
> preserved... but for root, user under which you are not supposed to
> log to the system in normal operation. This is probably the problem:
> since there is no privileged user, for "whom" to preserve/reserve these
> blocks?
>
> I imagine the alternative would be, if fossil reports full, that memory
> filesystems should be mounted on top of the system mandatory writable
> dirs so that the system will not block but normal booting will not
> be done but the program launched will be one requiring user to make
> room, crucial infos written in memory filesystems being copied back
> to fossil when done. But it is easier to implement when booting/rebooting,
> but more problematic if the system is running. Except perhaps that
> there will always be a memory filesystem mounted with rescue
> programs/scripts that the user can precisely use when the system
> is out of disk space, utilities that write nothing to disk (but just in
> their memory realm), in order to not paint oneself in a corner.
>

FWIW in 9front you can jump into rc while booting and fix this sort of
issue.


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T4ec62ed03a91d7a4-Mec344f9c69bd216b67f824c4
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 3645 bytes --]

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [9fans] p9f mention of 9front
  2021-06-24 20:51     ` unobe
  2021-06-25  8:28       ` Steve Simon
@ 2021-06-26  8:34       ` Ethan Gardener
  2021-06-26 12:55         ` noam
  1 sibling, 1 reply; 31+ messages in thread
From: Ethan Gardener @ 2021-06-26  8:34 UTC (permalink / raw)
  To: 9fans

On Thu, Jun 24, 2021, at 9:51 PM, unobe@cpan.org wrote:
> 
>  From
> what I can gather, there was a serious bug that was fixed in fossil
> after 9front forked, and yet there is no intention of including it
> back into 9front.

When I was involved with 9front, there was a dislike for Fossil because it's complicated. 9front core devs greatly valued being able to understand the entire system, but Fossil was a bit too much. Particularly, they didn't want to be responsible for maintaining a fork of Fossil too. Some people imported it & maintained it for themselves. Notably, mycroftiv ran quite a complex setup with a number of users on 9front+Fossil and was quite happy about it. I think he still does, but he no longer publishes CD-ROMs with his additions as he's changed his focus to the latest mathematical programming concepts.

mycrovtiv's... fork? I'm not sure it constitutes a fork, but there is quite a large set of namespace tools in addition to 9front+fossil.
"ANTS is no longer maintained and updated post 2020 but the iso is still available."
http://www.9gridchan.org/

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T523d6e906a17a7cc-Md646adaede1124e9b486cf40
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [9fans] full fossil follies
  2021-06-25 17:23                 ` Iruatã Souza
@ 2021-06-26  8:56                   ` Richard Miller
  0 siblings, 0 replies; 31+ messages in thread
From: Richard Miller @ 2021-06-26  8:56 UTC (permalink / raw)
  To: 9fans

> FWIW in 9front you can jump into rc while booting and fix this sort of
> issue.

Sure, having an in-kernel file system with rc and some tools for
file system exploration and repair is another alternative to having
them on a spare partition or usb drive or whatever. One could even
imagine a community 9p server in the cloud providing a FSRaaS
(file system recovery as a service).

What I was suggesting is that it would be simpler if we could just
run things like ls, du, and rm from a completely full fossil, without
having to reboot or switch into a special environment. It may be as
simple as not trying to update file access times if the partition is full.


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T4ec62ed03a91d7a4-M1d945cfd3d40324c273d42c8
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [9fans] full fossil follies
  2021-06-25 16:45                   ` adr via 9fans
@ 2021-06-26  9:01                     ` Ethan Gardener
  0 siblings, 0 replies; 31+ messages in thread
From: Ethan Gardener @ 2021-06-26  9:01 UTC (permalink / raw)
  To: 9fans

On Fri, Jun 25, 2021, at 5:45 PM, adr via 9fans wrote:
> 
> In a multi-user environment you can make the file system do something
> similar when the system is full, but instead of starting a console
> session, delete the last file modified and presenting the user
> an error.

The last file modified could be the log file which documents what went wrong. ;) I thought this through years ago, it's an annoying problem. I think the current situation isn't too bad. If I remember right, it's much better than CWFS, but I don't remember too clearly. I do remember my early Linux experience, trying to arrange several 100-200MB disks in such a way as to have both Emacs and X installed at the same time. (Impossible!) I was also root all the time because A: I didn't know what it was, and B: non-root authentication was broken in that release of that distro and I didn't know how to use the patch disks. My tiny disks inevitably filled up and somehow I managed to deal with them. (It helped that I had no data to lose, having just lost everything I wanted to keep from DOS, but it was still annoying.) It was harder than dealing with a full Fossil because Linux had no ramdisk at the time, I don't think there were any live CDs, and Linux didn't yet support `init=/bin/sh`. I don't think I understood how to start it in runlevel 1, or maybe I did everything in runlevel 1 so when that went wrong, I had to do something else. Sometimes, I had to unplug all the drives but the root, edit the boot config to make a recovery system, plug the drives back in... etc. By comparison, booting a Plan 9 iso and mounting Fossil is very simple and easy! :D It's essentially the same as how I'd repair any OS with a full disk today. Wonderful things, live-CDs.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T4ec62ed03a91d7a4-M0b4c16b88cb43f6182e94a8b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [9fans] p9f mention of 9front
  2021-06-26  8:34       ` [9fans] p9f mention of 9front Ethan Gardener
@ 2021-06-26 12:55         ` noam
  0 siblings, 0 replies; 31+ messages in thread
From: noam @ 2021-06-26 12:55 UTC (permalink / raw)
  To: 9fans

[-- Attachment #1: Type: text/plain, Size: 319 bytes --]

I'm working on rebasing ANTS onto 9front-master, with the intent of taking up maintainance.
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T523d6e906a17a7cc-Me752f3cc22bb8ccd5a0bc381
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 811 bytes --]

^ permalink raw reply	[flat|nested] 31+ messages in thread

end of thread, other threads:[~2021-06-26 12:55 UTC | newest]

Thread overview: 31+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-06-23 19:11 [9fans] p9f mention of 9front hiro
2021-06-23 23:05 ` unobe
2021-06-23 23:35   ` Sigrid Solveig Haflínudóttir
2021-06-23 23:58     ` Romano
2021-06-24  4:06       ` Lucio De Re
2021-06-24  4:56         ` unobe
2021-06-24  5:52           ` Lucio De Re
2021-06-24 21:25             ` Wes Kussmaul
2021-06-24 23:29               ` silas poulson
2021-06-25 13:06                 ` Wes Kussmaul
2021-06-24  8:24         ` Frank D. Engel, Jr.
2021-06-24  9:25           ` [9fans] plan9 and touch screens Richard Miller
2021-06-24  9:59             ` Lucio De Re
2021-06-24 10:12           ` [9fans] p9f mention of 9front Philip Silva via 9fans
2021-06-24 16:05             ` unobe
2021-06-24 16:16             ` Ethan Gardener
2021-06-24 11:19   ` hiro
2021-06-24 15:01     ` AW: " sirjofri
2021-06-24 20:51     ` unobe
2021-06-25  8:28       ` Steve Simon
2021-06-25  9:31         ` Richard Miller
2021-06-25 12:41           ` [9fans] full fossil follies Richard Miller
2021-06-25 14:12             ` adr via 9fans
2021-06-25 15:17               ` tlaronde
2021-06-25 16:06                 ` adr via 9fans
2021-06-25 16:45                   ` adr via 9fans
2021-06-26  9:01                     ` Ethan Gardener
2021-06-25 17:23                 ` Iruatã Souza
2021-06-26  8:56                   ` Richard Miller
2021-06-26  8:34       ` [9fans] p9f mention of 9front Ethan Gardener
2021-06-26 12:55         ` noam

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).