9front - general discussion about 9front
 help / color / mirror / Atom feed
From: Stuart Morrow <morrow.stuart@gmail.com>
To: 9front@9front.org
Subject: Re: [9front] Enabling a service
Date: Wed, 8 May 2024 22:26:41 +0100	[thread overview]
Message-ID: <CABB-WO_OivjBORWVVV7+ekVLFbcaVOHYLpg-DkFCdYwVDhAD5g@mail.gmail.com> (raw)
In-Reply-To: <CAFSF3XP6d4yjP0CRCb3tK_TqDGT9ERSKmaJvNist6BhD_Cf0MQ@mail.gmail.com>

On Wed, 8 May 2024 at 21:17, hiro <23hiro@gmail.com> wrote:
> i had hoped there would evolve something out of lapfs for a long time.
> i still think of it often, but now i stopped using laptops mostly,
> so...

But even within a single box, Something Like Orifs could replicate
across heterogeneous disks (as a side effect of being able to
replicate across different boxes).  It might be faster than devfs
because a write's correctness doesn't depend on every one of the disks
being touched straight away (disconnected operation is the premise of
Orifs).

Online resizing of a sort would fall out for free, too, not by
resizing the partition but by making a new partition and doing as
above (except with a partition instead of a disk). This would be good
to have on platforms installed by just writing 9front.*.img to the
disk.

The Orifs paper (old enough to be referenced by the newest Modern
Operating Systems by Tanenbaum) doesn't think of either of those.

With multiple machines:

Replication subsumes backups, at least the first level of them
(copies, but in the same building).  Plan 9 has a founding assumption
that computers are capital goods, and there's someone whose job it is
to make backups.  Today every 9front user has to do this themselves.
I understand the point of an operating system to be "to make computers
easier to use", not "& but only up to a certain point and then stop".

The Something Like Orifs <> Something Like Orifs protocol wouldn't be
9P.  So it's faster over the internet.

(Orifs itself is C++ abandonware.)

  reply	other threads:[~2024-05-08 21:29 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-06 11:32 Rocky Hotas
2024-05-06 11:58 ` Alex Musolino
2024-05-06 12:43 ` ori
2024-05-06 15:16   ` Scott Flowers
2024-05-06 15:37     ` sirjofri
2024-05-06 16:32     ` Stanley Lieber
2024-05-06 22:18   ` Rocky Hotas
2024-05-06 22:59     ` ori
2024-05-06 23:00     ` ori
2024-05-07  8:22       ` Rocky Hotas
2024-05-07  8:29         ` Frank D. Engel, Jr.
2024-05-07  9:03           ` Rocky Hotas
2024-05-07  9:14         ` sirjofri
2024-05-07 21:11           ` Shawn Rutledge
2024-05-07 21:35             ` Kurt H Maier
2024-05-07 21:45               ` sirjofri
2024-05-07 21:54             ` sl
2024-05-07 21:58               ` sl
2024-05-07 23:15                 ` Lennart Jablonka
2024-05-07 23:16                 ` Shawn Rutledge
2024-05-07 23:45                   ` Shawn Rutledge
2024-05-08  0:34                   ` Kurt H Maier
2024-05-08  0:35                   ` sl
2024-05-08  1:05                     ` Jacob Moody
2024-05-08  1:24                       ` sl
2024-05-08  7:22                         ` hiro
2024-05-08 14:04                           ` Stanley Lieber
2024-05-08 12:08                         ` Stuart Morrow
2024-05-08 16:37                           ` Brian Stuart
2024-05-08 20:16                             ` hiro
2024-05-08 21:26                               ` Stuart Morrow [this message]
2024-05-08 21:17                             ` Disconnection-tolerant / distributed filesystems (was Re: [9front] Enabling a service) Shawn Rutledge
2024-05-08 14:25                         ` [9front] Enabling a service Jacob Moody
2024-05-08  3:41                       ` Ori Bernstein
2024-05-08  4:09                         ` sl
2024-05-08  8:39                           ` Frank D. Engel, Jr.
2024-05-08 14:17                             ` Jacob Moody
2024-05-08 15:49                               ` Frank D. Engel, Jr.
2024-05-08 16:10                                 ` Jacob Moody
2024-05-08 16:33                                   ` Frank D. Engel, Jr.
2024-05-08 17:27                                     ` Jacob Moody
2024-05-08 18:00                                       ` Steve Simon
2024-05-08 19:46                                         ` hiro
2024-05-08 19:46                                   ` Roberto E. Vargas Caballero
2024-05-08 20:34                                     ` tlaronde
2024-05-08 14:57                   ` Lucas Francesco
2024-05-08 15:10                     ` an2qzavok
2024-05-08  2:11             ` Thaddeus Woskowiak

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CABB-WO_OivjBORWVVV7+ekVLFbcaVOHYLpg-DkFCdYwVDhAD5g@mail.gmail.com \
    --to=morrow.stuart@gmail.com \
    --cc=9front@9front.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).