Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #232642 > unrolled thread

Is there an alternative filesystem hierarchy that could be adapted to Debian.

Back to article view | Back to linux.debian.user

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Is there an alternative filesystem hierarchy that could be adapted to Debian. Cmdte Alpha Tigre Z <santiagopinth@gmail.com> - 2021-03-10 04:10 +0100
    Re: Is there an alternative filesystem hierarchy that could be  adapted to Debian. Weaver <weaver@riseup.net> - 2021-03-10 05:00 +0100
      Re: Is there an alternative filesystem hierarchy that could be  adapted to Debian. Cmdte Alpha Tigre Z <santiagopinth@gmail.com> - 2021-03-10 13:30 +0100
        Re: Is there an alternative filesystem hierarchy that could be adapted  to Debian. The Wanderer <wanderer@fastmail.fm> - 2021-03-10 13:50 +0100
          Re: Is there an alternative filesystem hierarchy that could be  adapted to Debian. Darac Marjal <mailinglist@darac.org.uk> - 2021-03-10 14:00 +0100
            Re: Is there an alternative filesystem hierarchy that could be  adapted to Debian. Cmdte Alpha Tigre Z <santiagopinth@gmail.com> - 2021-03-10 19:10 +0100
              Re: Is there an alternative filesystem hierarchy that could be  adapted to Debian. Dan Ritter <dsr@randomstring.org> - 2021-03-10 19:20 +0100
                Re: Is there an alternative filesystem hierarchy that could be  adapted to Debian. Cmdte Alpha Tigre Z <santiagopinth@gmail.com> - 2021-03-10 20:30 +0100
                  Re: Is there an alternative filesystem hierarchy that could be  adapted to Debian. Andrei POPESCU <andreimpopescu@gmail.com> - 2021-03-10 22:10 +0100
                    Re: Is there an alternative filesystem hierarchy that could be adapted  to Debian. The Wanderer <wanderer@fastmail.fm> - 2021-03-11 01:10 +0100
                      Re: Is there an alternative filesystem hierarchy that could be  adapted to Debian. Cmdte Alpha Tigre Z <santiagopinth@gmail.com> - 2021-03-11 01:40 +0100
                        Re: Is there an alternative filesystem hierarchy that could be adapted  to Debian. The Wanderer <wanderer@fastmail.fm> - 2021-03-11 01:50 +0100
                          Re: Is there an alternative filesystem hierarchy that could be  adapted to Debian. Cmdte Alpha Tigre Z <santiagopinth@gmail.com> - 2021-03-11 03:30 +0100
                            Re: Is there an alternative filesystem hierarchy that could be adapted  to Debian. The Wanderer <wanderer@fastmail.fm> - 2021-03-11 11:50 +0100
                              Re: Is there an alternative filesystem hierarchy that could be  adapted to Debian. Cmdte Alpha Tigre Z <santiagopinth@gmail.com> - 2021-03-11 12:50 +0100
                      Re: Is there an alternative filesystem hierarchy that could be  adapted to Debian. <tomas@tuxteam.de> - 2021-03-11 10:30 +0100
                        Re: Is there an alternative filesystem hierarchy that could be  adapted to Debian. Dan Ritter <dsr@randomstring.org> - 2021-03-11 11:50 +0100
                        Re: Is there an alternative filesystem hierarchy that could be  adapted to Debian. Greg Wooledge <greg@wooledge.org> - 2021-03-11 13:50 +0100
                          Re: Is there an alternative filesystem hierarchy that could be  adapted to Debian. <tomas@tuxteam.de> - 2021-03-11 14:50 +0100
                        Re: Is there an alternative filesystem hierarchy that could be adapted to Debian. Stefan Monnier <monnier@iro.umontreal.ca> - 2021-03-11 18:10 +0100
              Re: Is there an alternative filesystem hierarchy that could be  adapted to Debian. Nate Bargmann <n0nb@n0nb.us> - 2021-03-10 19:30 +0100
                Re: Is there an alternative filesystem hierarchy that could be  adapted to Debian. Cmdte Alpha Tigre Z <santiagopinth@gmail.com> - 2021-03-10 20:40 +0100
                  Re: Is there an alternative filesystem hierarchy that could be adapted to Debian. Stefan Monnier <monnier@iro.umontreal.ca> - 2021-03-10 23:30 +0100
                    Re: Is there an alternative filesystem hierarchy that could be  adapted to Debian. Cmdte Alpha Tigre Z <santiagopinth@gmail.com> - 2021-03-11 00:30 +0100
                      Re: Is there an alternative filesystem hierarchy that could be  adapted to Debian. Dan Ritter <dsr@randomstring.org> - 2021-03-11 12:00 +0100
                  Re: Is there an alternative filesystem hierarchy that could be  adapted to Debian. David Wright <deblis@lionunicorn.co.uk> - 2021-03-11 20:00 +0100
                    Re: Is there an alternative filesystem hierarchy that could be  adapted to Debian. Cmdte Alpha Tigre Z <santiagopinth@gmail.com> - 2021-03-11 21:10 +0100
                      Re: Is there an alternative filesystem hierarchy that could be  adapted to Debian. David Wright <deblis@lionunicorn.co.uk> - 2021-03-12 05:10 +0100
                        Windows drive letters (was Re: Is there an alternative filesystem  hierarchy that could be adapted to Debian.) The Wanderer <wanderer@fastmail.fm> - 2021-03-12 10:40 +0100
                          Re: Windows drive letters (was Re: Is there an alternative  filesystem hierarchy that could be adapted to Debian.) David Wright <deblis@lionunicorn.co.uk> - 2021-03-12 23:30 +0100
                        Re: Is there an alternative filesystem hierarchy that could be  adapted to Debian. Cmdte Alpha Tigre Z <santiagopinth@gmail.com> - 2021-03-12 17:10 +0100
                          Re: Is there an alternative filesystem hierarchy that could be  adapted to Debian. David Wright <deblis@lionunicorn.co.uk> - 2021-03-12 23:20 +0100
                      Re: Is there an alternative filesystem hierarchy that could be  adapted to Debian. Andrei POPESCU <andreimpopescu@gmail.com> - 2021-03-12 15:30 +0100
              Re: Is there an alternative filesystem hierarchy that could be  adapted to Debian. <tomas@tuxteam.de> - 2021-03-11 10:20 +0100
            Re: Is there an alternative filesystem hierarchy that could be adapted to Debian. Stefan Monnier <monnier@iro.umontreal.ca> - 2021-03-10 23:20 +0100
              Re: Is there an alternative filesystem hierarchy that could be  adapted to Debian. Jeremy Ardley <jeremy@ardley.org> - 2021-03-10 23:30 +0100
                Re: Is there an alternative filesystem hierarchy that could be adapted to Debian. Stefan Monnier <monnier@iro.umontreal.ca> - 2021-03-11 00:30 +0100
              Re: Is there an alternative filesystem hierarchy that could be  adapted to Debian. Sven Joachim <svenjoac@gmx.de> - 2021-03-10 23:40 +0100
                Re: Is there an alternative filesystem hierarchy that could be  adapted to Debian. Cmdte Alpha Tigre Z <santiagopinth@gmail.com> - 2021-03-11 00:50 +0100
              Re: Is there an alternative filesystem hierarchy that could be  adapted to Debian. IL Ka <kazakevichilya@gmail.com> - 2021-03-11 01:00 +0100
                Re: Is there an alternative filesystem hierarchy that could be  adapted to Debian. Greg Wooledge <greg@wooledge.org> - 2021-03-11 01:30 +0100
                  Re: Is there an alternative filesystem hierarchy that could be  adapted to Debian. Cmdte Alpha Tigre Z <santiagopinth@gmail.com> - 2021-03-11 01:40 +0100
                  Re: Is there an alternative filesystem hierarchy that could be  adapted to Debian. IL Ka <kazakevichilya@gmail.com> - 2021-03-11 02:20 +0100
                    Re: Is there an alternative filesystem hierarchy that could be  adapted to Debian. Cmdte Alpha Tigre Z <santiagopinth@gmail.com> - 2021-03-11 03:10 +0100
          Re: Is there an alternative filesystem hierarchy that could be  adapted to Debian. <tomas@tuxteam.de> - 2021-03-10 14:00 +0100
            Re: Is there an alternative filesystem hierarchy that could be  adapted to Debian. Cmdte Alpha Tigre Z <santiagopinth@gmail.com> - 2021-03-10 14:10 +0100
              Re: Is there an alternative filesystem hierarchy that could be adapted  to Debian. The Wanderer <wanderer@fastmail.fm> - 2021-03-10 14:30 +0100
                Re: Is there an alternative filesystem hierarchy that could be  adapted to Debian. Cmdte Alpha Tigre Z <santiagopinth@gmail.com> - 2021-03-10 19:10 +0100
          Re: Is there an alternative filesystem hierarchy that could be  adapted to Debian. Cmdte Alpha Tigre Z <santiagopinth@gmail.com> - 2021-03-10 14:10 +0100
            Re: Is there an alternative filesystem hierarchy that could be  adapted to Debian. IL Ka <kazakevichilya@gmail.com> - 2021-03-10 14:30 +0100
          Re: Is there an alternative filesystem hierarchy that could be adapted to Debian. "Thomas Schmitt" <scdbackup@gmx.net> - 2021-03-10 14:20 +0100
      Re: Is there an alternative filesystem hierarchy that could be  adapted to Debian. "J.B. Nicholson" <jbn@forestfield.org> - 2021-03-11 01:50 +0100
    Re: Is there an alternative filesystem hierarchy that could be  adapted to Debian. Darac Marjal <mailinglist@darac.org.uk> - 2021-03-10 10:10 +0100
    Re: Is there an alternative filesystem hierarchy that could be  adapted to Debian. songbird <songbird@anthive.com> - 2021-03-10 14:20 +0100
      Re: Is there an alternative filesystem hierarchy that could be  adapted to Debian. Cmdte Alpha Tigre Z <santiagopinth@gmail.com> - 2021-03-10 14:30 +0100
        Re: Is there an alternative filesystem hierarchy that could be  adapted to Debian. Nate Bargmann <n0nb@n0nb.us> - 2021-03-10 15:40 +0100
        Re: Is there an alternative filesystem hierarchy that could be  adapted to Debian. songbird <songbird@anthive.com> - 2021-03-10 16:30 +0100
          Re: Is there an alternative filesystem hierarchy that could be  adapted to Debian. Richard Owlett <rowlett@cloud85.net> - 2021-03-10 18:00 +0100
          Re: Is there an alternative filesystem hierarchy that could be  adapted to Debian. Cmdte Alpha Tigre Z <santiagopinth@gmail.com> - 2021-03-10 21:30 +0100
            Re: Is there an alternative filesystem hierarchy that could be  adapted to Debian. Dan Ritter <dsr@randomstring.org> - 2021-03-10 21:40 +0100
            Re: Is there an alternative filesystem hierarchy that could be  adapted to Debian. Joe <joe@jretrading.com> - 2021-03-10 22:00 +0100
              Re: Is there an alternative filesystem hierarchy that could be  adapted to Debian. Dan Ritter <dsr@randomstring.org> - 2021-03-10 22:10 +0100
                Re: Is there an alternative filesystem hierarchy that could be  adapted to Debian. Cmdte Alpha Tigre Z <santiagopinth@gmail.com> - 2021-03-10 22:30 +0100
            Re: Is there an alternative filesystem hierarchy that could be adapted to Debian. Stefan Monnier <monnier@iro.umontreal.ca> - 2021-03-10 23:50 +0100
              Re: Is there an alternative filesystem hierarchy that could be  adapted to Debian. Cmdte Alpha Tigre Z <santiagopinth@gmail.com> - 2021-03-11 00:40 +0100
                Re: Is there an alternative filesystem hierarchy that could be  adapted to Debian. <tomas@tuxteam.de> - 2021-03-11 09:30 +0100
              Re: Is there an alternative filesystem hierarchy that could be  adapted to Debian. David Wright <deblis@lionunicorn.co.uk> - 2021-03-11 05:00 +0100
                Re: Is there an alternative filesystem hierarchy that could be  adapted to Debian. David <bouncingcats@gmail.com> - 2021-03-11 06:20 +0100
                  Re: Is there an alternative filesystem hierarchy that could be  adapted to Debian. David Wright <deblis@lionunicorn.co.uk> - 2021-03-11 19:40 +0100
                    Re: Is there an alternative filesystem hierarchy that could be  adapted to Debian. Greg Wooledge <greg@wooledge.org> - 2021-03-11 19:50 +0100
      Re: Is there an alternative filesystem hierarchy that could be  adapted to Debian. Richard Owlett <rowlett@cloud85.net> - 2021-03-10 14:30 +0100
        Re: Is there an alternative filesystem hierarchy that could be  adapted to Debian. Cmdte Alpha Tigre Z <santiagopinth@gmail.com> - 2021-03-10 19:10 +0100
    Re: Is there an alternative filesystem hierarchy that could be  adapted to Debian. Erwan David <erwan@rail.eu.org> - 2021-03-10 19:20 +0100
    Re: Is there an alternative filesystem hierarchy that could be adapted to Debian. Stefan Monnier <monnier@iro.umontreal.ca> - 2021-03-10 23:30 +0100
      Re: Is there an alternative filesystem hierarchy that could be  adapted to Debian. Cmdte Alpha Tigre Z <santiagopinth@gmail.com> - 2021-03-11 00:30 +0100
        Re: Is there an alternative filesystem hierarchy that could be adapted to Debian. deloptes <deloptes@gmail.com> - 2021-03-11 07:30 +0100

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#232718 — Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.

[Multipart message — attachments visible in raw view] — view raw

* On 2021 10 Mar 12:02 -0600, Cmdte Alpha Tigre Z wrote:
> > I think all these shortened names derive from a time when computing
> > resources were limited. If you're using an 80x25 terminal over at 50
> > bits per second to a time-shared mainframe, it's more comfortable to
> > type "/usr" than it is to type "/Programs". Easier to type "cp" than to
> > type "copy", and so on. It's all fairly arbitrary. Why C:\? Why not
> > System:\? Convention and history and inertia.
> > >
> > > Cheers
> > >
> > > [1] https://en.wikipedia.org/wiki/Usr
> > >
> > >  - t
> 
> But why do we have to use a system designed for such old computers
> when the now old computers are much more capable than that.
> I think it needs a redesign.
> 
> By the way, C:\ looks fine since it is just a letter succession mechanism
> for labeling storage devices: C, D, E... it is like: usb0, usb1, usb2...

It is more than looks.  In Unix filesystems disks/volumes/partitions are
"mounted" into the main file system at some arbitrary "mount point" and
thus the filesystem encompasses all mounted devices.  With DOS, all
lettered disks are independent, though resources can be referenced
across disks, it's not seamless.  Also, what happens when you get to
disk Z?

Why should we use filesystem specifications that are constrained by the
limitations of CP/M running on 8 bit processors?

- Nate

-- 

"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."

Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819

[toc] | [prev] | [next] | [standalone]

#232727 — Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.

> It is more than looks.  In Unix filesystems disks/volumes/partitions are
> "mounted" into the main file system at some arbitrary "mount point" and
> thus the filesystem encompasses all mounted devices.  With DOS, all
> lettered disks are independent, though resources can be referenced
> across disks, it's not seamless.  Also, what happens when you get to
> disk Z?

Yes I saw that too.  But I prefer not to further continue this debate to
/dev or /mount.
I like to know at hand what file is on which disk.  Aside from that,
if I made Windows, I would make it go to AA after Z, looks like a little
solution.  Even though, it would not be bad to call them USB0: or HDD0:,
just a bit more complex.

> Why should we use filesystem specifications that are constrained by the
> limitations of CP/M running on 8 bit processors?

I never tried to say that we should use FAT or NTFS.  I was just talking
about names.

[toc] | [prev] | [next] | [standalone]

#232748

> I like to know at hand what file is on which disk.

That used to work for A: vs C: back in the days of floppys, but what
part of "E:" tells you which disk it is?  At best you get to assume that
E: and D: are different disks, but the names don't tell you which is which.

> Even though, it would not be bad to call them USB0: or HDD0:,
> just a bit more complex.

That's better, indeed.  But the "0" still makes it unclear (which disk
is 0 and which is 1?).  To make it more clear, I think it's important to
give (as much as possible) human-chosen names to the disks (for that
reason I use LVM to partition my disks, where I can label my disks and
partitions, although those labels aren't always reflected in the mount
points, so they're not always visible in the actual names of the files
that reside in them).


        Stefan

[toc] | [prev] | [next] | [standalone]

#232755 — Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.

[Multipart message — attachments visible in raw view] — view raw

> > I like to know at hand what file is on which disk.
>
> That used to work for A: vs C: back in the days of floppys, but what
> part of "E:" tells you which disk it is?  At best you get to assume that
> E: and D: are different disks, but the names don't tell you which is
which.
>
> > Even though, it would not be bad to call them USB0: or HDD0:,
> > just a bit more complex.
>
> That's better, indeed.  But the "0" still makes it unclear (which disk
> is 0 and which is 1?).  To make it more clear, I think it's important to
> give (as much as possible) human-chosen names to the disks (for that
> reason I use LVM to partition my disks, where I can label my disks and
> partitions, although those labels aren't always reflected in the mount
> points, so they're not always visible in the actual names of the files
> that reside in them).

That would depend whether you would prefer sequentially
labeled devices or named devices.  The better approach would be to use both,
so the computer could give a name to a recently plugged device
without asking you for one or even before you can try to give it one.

Perhaps this conversation is getting off topic since this is a mailing list
for user-related things. :)

[toc] | [prev] | [next] | [standalone]

#232803 — Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.

Cmdte Alpha Tigre Z wrote: 
> > > I like to know at hand what file is on which disk.
> >
> > That used to work for A: vs C: back in the days of floppys, but what
> > part of "E:" tells you which disk it is?  At best you get to assume that
> > E: and D: are different disks, but the names don't tell you which is
> which.
> >
> > > Even though, it would not be bad to call them USB0: or HDD0:,
> > > just a bit more complex.
> >
> > That's better, indeed.  But the "0" still makes it unclear (which disk
> > is 0 and which is 1?).  To make it more clear, I think it's important to
> > give (as much as possible) human-chosen names to the disks (for that
> > reason I use LVM to partition my disks, where I can label my disks and
> > partitions, although those labels aren't always reflected in the mount
> > points, so they're not always visible in the actual names of the files
> > that reside in them).
> 
> That would depend whether you would prefer sequentially
> labeled devices or named devices.  The better approach would be to use both,
> so the computer could give a name to a recently plugged device
> without asking you for one or even before you can try to give it one.

You can give a filesystem a label, and then it is visible in
/dev/disk/by-label
after it is mounted.

Labels are not guaranteed to be unique, though, so it's possible
for you to label two USB sticks as "Project Data" and then get
confused.

Filesystems get Universally Unique Identifiers (UUIDs) as seen:
/dev/disk/by-uuid

But UUIDs are terrible for humans to remember, and while they
are probably unique, it's possible to copy them and thus make
them non-unique.

You can also reference disks by their serial numbers, which
really should be unique but are beyond your control, or by their
place in your hardware architecture, which is only reliable
until something changes.

-dsr-

[toc] | [prev] | [next] | [standalone]

#232828 — Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.

On Wed 10 Mar 2021 at 15:35:07 (-0400), Cmdte Alpha Tigre Z wrote:
> > It is more than looks.  In Unix filesystems disks/volumes/partitions are
> > "mounted" into the main file system at some arbitrary "mount point" and
> > thus the filesystem encompasses all mounted devices.  With DOS, all
> > lettered disks are independent, though resources can be referenced
> > across disks, it's not seamless.  Also, what happens when you get to
> > disk Z?
> 
> Yes I saw that too.  But I prefer not to further continue this debate to
> /dev or /mount.

Err, not so fast …

> I like to know at hand what file is on which disk.  Aside from that,
> if I made Windows, I would make it go to AA after Z, looks like a little
> solution.  Even though, it would not be bad to call them USB0: or HDD0:,
> just a bit more complex.
> 
> > Why should we use filesystem specifications that are constrained by the
> > limitations of CP/M running on 8 bit processors?
> 
> I never tried to say that we should use FAT or NTFS.  I was just talking
> about names.

No. You're not. You're talking about the filesystem structure,
the hierarchy, not just names.

Changing the names themselves is trivial. The name /usr exists
in one place, and you could rename it by typing, say,
# mv /usr /UlSteR
The *filesystem* is still happy—the OS would crash only because
nothing else calls usr that. Simple to change.

But device letters are different.

Take the case where partition E: contains the users' home
directories for users foo and bar. Foo's video collection
in E:/foo/Videos/ eventually grows so large that it has to
be hived off onto a separate device, F: is assigned to it,
and all of Foo's videos are moved there.

Now, a file that Bar knew as E:/foo/Videos/cats.mp4, or
even ../foo/Videos/cats.mp4, has the new path F:/cats.mp4.

Here's how that works differently on unix filesystems:

Old scheme:

# mount /dev/sdc1 /home

~foo/Videos/cats.mp4 (or ../foo/Videos/cats.mp4).

New scheme:

# mount /dev/sdc1 /home

on which /home/foo/Videos/ has been copied to device /dev/sdd1,
and emptied.

# mount /dev/sdd1 /home/foo/Videos

Now the videos copied to /dev/sdd1 all appear in the same
location as they did before, and all the file paths stay
the same.

So by closing down debate on /dev and /mount, you show that
you've missed the essence of unix's unified filesystem by
not seeing beyond mere names.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#232836 — Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.

El jue, 11 mar 2021 a las 14:51, David Wright
(<deblis@lionunicorn.co.uk>) escribió:
> Take the case where partition E: contains the users' home
> directories for users foo and bar. Foo's video collection
> in E:/foo/Videos/ eventually grows so large that it has to
> be hived off onto a separate device, F: is assigned to it,
> and all of Foo's videos are moved there.
>
> Now, a file that Bar knew as E:/foo/Videos/cats.mp4, or
> even ../foo/Videos/cats.mp4, has the new path F:/cats.mp4.
>
> Here's how that works differently on unix filesystems:
>
> Old scheme:
>
> # mount /dev/sdc1 /home
>
> ~foo/Videos/cats.mp4 (or ../foo/Videos/cats.mp4).
>
> New scheme:
>
> # mount /dev/sdc1 /home
>
> on which /home/foo/Videos/ has been copied to device /dev/sdd1,
> and emptied.
>
> # mount /dev/sdd1 /home/foo/Videos
>
> Now the videos copied to /dev/sdd1 all appear in the same
> location as they did before, and all the file paths stay
> the same.

Thanks for your proposition, I didn't understand the usefulness of a
unified hierarchy
until you put that example.

Well, you still have to mount it, don't you?  We don't have to delete
the mount "feature"
nor the unified hierarchy, instead we could use both approaches.
Think of E: and F:
as sdc1 and sdd1, with direct access to those E: and F:. (Now that I'm
writing this,
I think we could use E1: and F1:, I find it useful too).  Then you
could write something like:

mount E1: /home
mount F1: /home/foo/Videos

The boot device could always be An: (with "n" being some number), so
the system could automatically do: "mount An: /" at boot.  If you
would prefer some
operating system interoperability, we could use Cn: instead of An:

At the end, you have the safe option to write /something/something_else
on the command line, or F1:/something/something_else at a GUI.

Please read the following.

El mié, 10 mar 2021 a las 18:25, Stefan Monnier
(<monnier@iro.umontreal.ca>) escribió:
> > (...) To make it more clear, I think it's important to
> > give (as much as possible) human-chosen names to the disks (for that
> > reason I use LVM to partition my disks, where I can label my disks and
> > partitions, although those labels aren't always reflected in the mount
> > points, so they're not always visible in the actual names of the files
> > that reside in them).

El mié, 10 mar 2021 a las 19:28, Cmdte Alpha Tigre Z
(<santiagopinth@gmail.com>) escribió:
> That would depend whether you would prefer sequentially
> labeled devices or named devices.  The better approach would be to use both (...)

We can store names into devices' filesystems.  This way, we could use
e.g. :Foo:/foo/Videos/cats.mp4.  The system will assign it F1:, but then
it could read into the device's filesystem that it is called Foo, so the system
makes it available as :Foo:  If you plug the device into another PC,
it will still
be automatically called :Foo:

We could even use USBa1: or HDDb2:, although it looks a bit more complex,
it adds more information about the device as (I think, I don't
remember well) sda
or sdb do.

As you can see, we don't have to use some fixed existing approach,
everything could be possible, it's a matter of thinking about possibilities,
and pros and cons.

-- 
Time zone: GMT-4
Months: Ene = Jan ; Abr = Apr ; Ago = Aug ; Dic = Dec

[toc] | [prev] | [next] | [standalone]

#232854 — Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.

On Thu 11 Mar 2021 at 16:02:55 (-0400), Cmdte Alpha Tigre Z wrote:
> El jue, 11 mar 2021 a las 14:51, David Wright escribió:
> > Take the case where partition E: contains the users' home
> > directories for users foo and bar. Foo's video collection
> > in E:/foo/Videos/ eventually grows so large that it has to
> > be hived off onto a separate device, F: is assigned to it,
> > and all of Foo's videos are moved there.
> >
> > Now, a file that Bar knew as E:/foo/Videos/cats.mp4, or
> > even ../foo/Videos/cats.mp4, has the new path F:/cats.mp4.
> >
> > Here's how that works differently on unix filesystems:
> >
> > Old scheme:
> > # mount /dev/sdc1 /home
> > ~foo/Videos/cats.mp4 (or ../foo/Videos/cats.mp4).
> >
> > New scheme:
> > # mount /dev/sdc1 /home
> > on which /home/foo/Videos/ has been copied to device /dev/sdd1,
> > and emptied.
> > # mount /dev/sdd1 /home/foo/Videos
> >
> > Now the videos copied to /dev/sdd1 all appear in the same
> > location as they did before, and all the file paths stay
> > the same.
> 
> Thanks for your proposition, I didn't understand the usefulness of a
> unified hierarchy until you put that example.
> 
> Well, you still have to mount it, don't you?  We don't have to delete
> the mount "feature"
> nor the unified hierarchy, instead we could use both approaches.

If you think you need the feature, it might not be too difficult to
set up, say, a directory called /top, which contains links A, B1, etc
pointing to any directory you choose. Symlinks are the normal way to
approach these requirements, and don't require any modifications to
the filesystem.

> Think of E: and F:
> as sdc1 and sdd1, with direct access to those E: and F:.

Take care how you express this. sdc1 and sdd1 *do* give you direct
access to devices, but it's raw, and doesn't go through the filesystem
access methods. Consequently it would be the easiest way to destroy
your files, which is exactly how most users employ it: with dd, to
write one filesystem over another, or to wipe it with /dev/zero or
/dev/urandom.

> (Now that I'm writing this,
> I think we could use E1: and F1:, I find it useful too).  Then you
> could write something like:
> 
> mount E1: /home
> mount F1: /home/foo/Videos

The point about sdc and sdd is that these names are outside your
control, being chosen by the kernel in ways you may need to learn
about. The only sensible way ahead here is for you to write
filesystem LABELs into the partitions, eg

LABEL=toto06 /home ext4 errors=remount-ro,nofail,noauto,user,exec,suid 0 2

from my own /etc/fstab. (But that still doesn't give you the option of
opening, say, toto06•Videos/dog.mp4, where • is some sensibly chosen
delimiter.)

I'm not familiar with how Windows assigns drive letters, particularly
ones that are meant to be Stable. Nor what happens if two devices
with the same (Stable) name are plugged in simultaneously.

> The boot device could always be An: (with "n" being some number), so
> the system could automatically do: "mount An: /" at boot.  If you
> would prefer some
> operating system interoperability, we could use Cn: instead of An:

I don't think you'll gain any interoperability from these
proposed changes to your filesystem. And any hope that you did
have would immediately be destroyed if you used a letter other
than C: to represent the system drive. That's not because it
has to be C:, but because everybody has respected that convention
since its invention. (IOW it's more like the convention that
usr is called usr, and not UlSteR.)

But AIUI you're fighting hard to go backwards. Under the right
circumstances, I am led to believe that you can mount devices
onto directories in Window's NTFS filesystems, thereby avoiding
letters.

> At the end, you have the safe option to write /something/something_else
> on the command line, or F1:/something/something_else at a GUI.

You'd have to sort out the delimiter ":", and the semantics of
a filename F1:something/something_else. (I take it you're familiar
with how the interpretation of F:a\b is distinguished from F:\a\b
in Windows.)

> Please read the following.
> 
> El mié, 10 mar 2021 a las 18:25, Stefan Monnier escribió:
> > > (...) To make it more clear, I think it's important to
> > > give (as much as possible) human-chosen names to the disks (for that
> > > reason I use LVM to partition my disks, where I can label my disks and
> > > partitions, although those labels aren't always reflected in the mount
> > > points, so they're not always visible in the actual names of the files
> > > that reside in them).

I, too, label my disk partitions with a LABEL (as seen in the
example above), and a PARTLABEL (Toto-Home), the latter required here
for unlocking the LUKS encryption,

$ sudo udisksctl unlock --block-device /dev/disk/by-partlabel/Toto-Home

because the LABEL is, as yet, hidden by the encryption.

Yes, there are limitations as to which labels are visible and/or
appropriate to use at different times. You can't unlock encryption
by LABEL, and you can't directly reference files by either of
[PART]LABEL. So the choice of mount point can be important.

I use udev to create mount points with appropriate names when I insert
my own removable drives: udev tries, in order, to match properties
(ID_FS_LABEL, ID_FS_UUID, ID_SERIAL_SHORT, ID_PART_ENTRY_NAME,
DEVNAME's basename, and ID_SERIAL) with a directory of filenames,
each of which contains the name I chose for the mount point.
(Sounds complicated, but it's very simple: it has to be fast.)

I don't currently have any use for LVM. It's a complication
I don't need.

> El mié, 10 mar 2021 a las 19:28, Cmdte Alpha Tigre Z escribió:
> > That would depend whether you would prefer sequentially
> > labeled devices or named devices.  The better approach would be to use both (...)
> 
> We can store names into devices' filesystems.  This way, we could use
> e.g. :Foo:/foo/Videos/cats.mp4.  The system will assign it F1:, but then
> it could read into the device's filesystem that it is called Foo, so the system
> makes it available as :Foo:  If you plug the device into another PC,
> it will still
> be automatically called :Foo:
> 
> We could even use USBa1: or HDDb2:, although it looks a bit more complex,
> it adds more information about the device as (I think, I don't
> remember well) sda
> or sdb do.
> 
> As you can see, we don't have to use some fixed existing approach,
> everything could be possible, it's a matter of thinking about possibilities,
> and pros and cons.

Hmm, I'm not sure what sort of reply you want. Perhaps:

  "Jolly good idea. Let's do that. How long do you think you'll take?
   I'll start thinking about how to persuade people to use it. We need
   a major existing problem that it solves, and remember that we're up
   against an installed base of devices, like TVs, that can use only
   FATnn/NTFS/HFS+/EXTn filesystems, so it needs to be completely
   compatible¹ with one of those. Finally, whatever changes are made,
   they have to be supported so that it'll all work with future kernels."

Perhaps read this, by someone playing around with a filesystem from
the simpler times in the last century.

http://time.to.pullthepl.ug/post/2013/06/24/porting-an-ancient-filesystem-to-modern-linux/

¹ ie the insertions you make should be either invisible to, ignored by,
  or untroubling for, an existing filesystem's access methods.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#232873 — Windows drive letters (was Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.)

[Multipart message — attachments visible in raw view] — view raw

On 2021-03-11 at 23:05, David Wright wrote:

> On Thu 11 Mar 2021 at 16:02:55 (-0400), Cmdte Alpha Tigre Z wrote:

<snip>

> I'm not familiar with how Windows assigns drive letters,

Basically, there's an internal device ID list (hexadecimal GUIDs, if I'm
not mistaken), and a mapping in the Registry. Beyond that it probably
involves the internal device paths which underlie e.g. devmgmt.msc
(Device Manager), and I've only recently begun to learn about that
syntax in the first place.

For fixed disks, no letter is assigned by default, one has to be set up
explicitly. The GUI tool for doing this is diskmgmt.msc, and I believe
it can also be done using command-line tools that I've rarely had
occasion to touch.

For removable disks (e.g. USB drives), whenever a new one is connected
the next currently-not-known-used letter is assigned, for a definition
of "used" that doesn't count letters taken up by being mapped to network
drives. *Usually* it seems to recognize a previously-connected drive and
assign it the same letter as it got before, but not always; I've yet to
identify any recognizable pattern to how it handles things when two
drives previously got the same letter and you connect them both.

> particularly ones that are meant to be Stable.

I'm not entirely sure how you're defining this.

Fixed disks basically always get the same letter. Removable ones only
sometimes do.

> Nor what happens if two devices with the same (Stable) name are
> plugged in simultaneously.

I can't completely swear to this, but I believe it's one of two things:
either whichever one gets connected first gets the letter and the other
one doesn't show up except in e.g. diskmgmt.msc (and an error is
probably logged), or whichever one gets connected second gets a
different letter automatically.

The exception is for letters consumed by network drives. If you have
e.g. enough USB drives connected for one of them to automatically get
the letter G:, and you already have G: mapped to a network location,
Windows will silently allow the network location to take precedence;
diskmgmt.msc will show the drive-letter mapping of the USB drive and
allow you to change it, but otherwise it will mostly look as if the
drive wasn't recognized in the first place.

>> The boot device could always be An: (with "n" being some number),
>> so the system could automatically do: "mount An: /" at boot.  If
>> you would prefer some operating system interoperability, we could
>> use Cn: instead of An:
> 
> I don't think you'll gain any interoperability from these proposed
> changes to your filesystem. And any hope that you did have would
> immediately be destroyed if you used a letter other than C: to
> represent the system drive. That's not because it has to be C:, but
> because everybody has respected that convention since its invention.
> (IOW it's more like the convention that usr is called usr, and not
> UlSteR.)
> 
> But AIUI you're fighting hard to go backwards. Under the right 
> circumstances, I am led to believe that you can mount devices onto
> directories in Window's NTFS filesystems, thereby avoiding letters.

You still have to have the letters, or at least "letter" singular, so
that you have a place to create directories onto which to do the
mounting. Other than that, yes, this is possible.


To be clear: I think this entire proposal (except for the part about how
Windows should automatically proceed to AA: after hitting Z:) is
wrongheaded, not worth the effort, virtually certain to never be
implemented in practice, and would cause far more problems than it would
solve. As a thought exercise it is interesting, but primarily for how it
helps us dig up and see the problems which would result from trying to
implement it.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

[toc] | [prev] | [next] | [standalone]

#232935 — Re: Windows drive letters (was Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.)

On Fri 12 Mar 2021 at 04:33:00 (-0500), The Wanderer wrote:
> On 2021-03-11 at 23:05, David Wright wrote:
> > On Thu 11 Mar 2021 at 16:02:55 (-0400), Cmdte Alpha Tigre Z wrote:
> 
> <snip>
> 
> > I'm not familiar with how Windows assigns drive letters,
> 

[ … ]

> For removable disks (e.g. USB drives), whenever a new one is connected
> the next currently-not-known-used letter is assigned, for a definition
> of "used" that doesn't count letters taken up by being mapped to network
> drives. *Usually* it seems to recognize a previously-connected drive and
> assign it the same letter as it got before, but not always; I've yet to
> identify any recognizable pattern to how it handles things when two
> drives previously got the same letter and you connect them both.
> 
> > particularly ones that are meant to be Stable.
> 
> I'm not entirely sure how you're defining this.

I'm probably conflating …

> Fixed disks basically always get the same letter. Removable ones only
> sometimes do.

… those two things. I've used Disk Manager to stop assigning *any*
letter to my fixed disk linux partitions so that it doesn't nag my
wife about reformatting them.

Reading the OP's use of E: and F:, and storing device names in the
filesystem, I assumed that Stable/Remembered names was some ability of
Windows that the OP missed in linux. (Like much of the thread seems
to be.) Hence the exposition on my own scheme for stable mount points.

[ … ]

> > But AIUI you're fighting hard to go backwards. Under the right 
> > circumstances, I am led to believe that you can mount devices onto
> > directories in Window's NTFS filesystems, thereby avoiding letters.
> 
> You still have to have the letters, or at least "letter" singular, so
> that you have a place to create directories onto which to do the
> mounting. Other than that, yes, this is possible.

Yes, I wasn't discounting the system drive being a letter (C:),
but just pointing out the recent ability to make a hierarchy out of
Windows's C: D: E: F: disjointed filesystem.
(IOW "letters" stood for having all these separate "roots".)

> To be clear: I think this entire proposal (except for the part about how
> Windows should automatically proceed to AA: after hitting Z:) is
> wrongheaded, not worth the effort, virtually certain to never be
> implemented in practice, and would cause far more problems than it would
> solve. As a thought exercise it is interesting, but primarily for how it
> helps us dig up and see the problems which would result from trying to
> implement it.

Agreed. (No opinion on the parenthesised bit.)

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#232905 — Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.

2021-03-12 0:05 GMT-04:00, David Wright <deblis@lionunicorn.co.uk>:
> On Thu 11 Mar 2021 at 16:02:55 (-0400), Cmdte Alpha Tigre Z wrote:
>> Think of E: and F:
>> as sdc1 and sdd1, with direct access to those E: and F:.
>
> Take care how you express this. sdc1 and sdd1 *do* give you direct
> access to devices, but it's raw, and doesn't go through the filesystem
> access methods. Consequently it would be the easiest way to destroy
> your files, which is exactly how most users employ it: with dd, to
> write one filesystem over another, or to wipe it with /dev/zero or
> /dev/urandom.

Oh, thanks, I didn't know that.

> You'd have to sort out the delimiter ":", and the semantics of
> a filename F1:something/something_else. (I take it you're familiar
> with how the interpretation of F:a\b is distinguished from F:\a\b
> in Windows.)

I'm sorry, I don't know that difference.  I made some
experiments.  It looks like every letter has its own working directory,
and F:\a\b is just an absolute path but F:a\b is acomments, lative
to the working directory of F:
Is it right?

> Perhaps read this, by someone playing around with a filesystem from
> the simpler times in the last century.
>
> http://time.to.pullthepl.ug/post/2013/06/24/porting-an-ancient-filesystem-to-modern-linux/

Thanks, I will read it later.

Thanks for your comments and help, I find them very useful.

Have a good day.

[toc] | [prev] | [next] | [standalone]

#232934 — Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.

On Fri 12 Mar 2021 at 12:03:37 (-0400), Cmdte Alpha Tigre Z wrote:
> 2021-03-12 0:05 GMT-04:00, David Wright <deblis@lionunicorn.co.uk>:

> > You'd have to sort out the delimiter ":", and the semantics of
> > a filename F1:something/something_else. (I take it you're familiar
> > with how the interpretation of F:a\b is distinguished from F:\a\b
> > in Windows.)
> 
> I'm sorry, I don't know that difference.  I made some
> experiments.  It looks like every letter has its own working directory,
> and F:\a\b is just an absolute path but F:a\b is [re]lative
> to the working directory of F:
> Is it right?

Yes, and this is often overlooked.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#232892 — Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.

[Multipart message — attachments visible in raw view] — view raw

On Jo, 11 mar 21, 16:02:55, Cmdte Alpha Tigre Z wrote:
> 
> Thanks for your proposition, I didn't understand the usefulness of a
> unified hierarchy
> until you put that example.
> 
> Well, you still have to mount it, don't you?  We don't have to delete
> the mount "feature"
> nor the unified hierarchy, instead we could use both approaches.
> Think of E: and F:
> as sdc1 and sdd1, with direct access to those E: and F:. (Now that I'm
> writing this,
> I think we could use E1: and F1:, I find it useful too).  Then you
> could write something like:
> 
> mount E1: /home
> mount F1: /home/foo/Videos
> 
> The boot device could always be An: (with "n" being some number), so
> the system could automatically do: "mount An: /" at boot.  If you
> would prefer some
> operating system interoperability, we could use Cn: instead of An:
> 
> At the end, you have the safe option to write /something/something_else
> on the command line, or F1:/something/something_else at a GUI.

It seems to me you are proposing an additional level of indirection[1], 
so beware of:

"All problems in computer science can be solved by another level of 
indirection"
"... except for the problem of too many levels of indirection"

(attributed to various Computer Scientists)

[1] https://en.wikipedia.org/wiki/Indirection

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#232798 — Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.

[Multipart message — attachments visible in raw view] — view raw

On Wed, Mar 10, 2021 at 02:01:29PM -0400, Cmdte Alpha Tigre Z wrote:
> > I think all these shortened names derive from a time when computing
> > resources were limited. If you're using an 80x25 terminal over at 50
> > bits per second to a time-shared mainframe, it's more comfortable to
> > type "/usr" than it is to type "/Programs". Easier to type "cp" than to
> > type "copy", and so on. It's all fairly arbitrary. Why C:\? Why not
> > System:\? Convention and history and inertia.
> > >
> > > Cheers
> > >
> > > [1] https://en.wikipedia.org/wiki/Usr
> > >
> > >  - t
> 
> But why do we have to use a system designed for such old computers
> when the now old computers are much more capable than that.

You are still using the (human) language(s) you learnt when you
were a kid. Granted, that language(s) evolved a bit in the meantime,
but not so quicly as to prevent them from doing their job: allow
communication between humans.

A file system layout (like a kernel call interface, or a hardware
architecture design) fulfill a similar role: since there's no
way (well, nearly no way) one could build such complex things all
alone -- on the contrary, you need a pretty big community, to
achieve that [1], you need a set of conventions and rituals to
gather around. Once the communities grow large, those conventions
move more slowly.

In a nutshell:

Complex system development (be it buildings, math or software)
is an inherently social activity, and need common languages, which
tend to evolve, but according to a "time constant" in the order
of a human life.

> I think it needs a redesign.

Go ahead. Perhaps you want to read first about strange beasts
which roamed the earth before the idea of a hierarchical file
system established itself, e.g. [2].

> By the way, C:\ looks fine since it is just a letter succession mechanism
> for labeling storage devices: C, D, E... it is like: usb0, usb1, usb2...

To me it looks weird, but hey. Putting everything in one tree
and having special places (/dev, /proc...) for special things.

And, oh, on my box it isn't just "usb0" without any context, but
something like "/dev/bus/usb/001/001" (or then, perhaps, also
"/dev/sdb", depending on how many layers of software you put in
front of it ;-)

Only "eth0" is special and weird. Who said our systems have no
warts? Look at Plan9 [3] to see what other smart folks have
attempted to do (heck, there, even GUI windows have a place
in the file system. You "rm" that file, and pop goes the window).

Enjoy

[1] Have a look at Linux kernel development statistics to get
   a feeling about the orders of magnitude involved, e.g. in
   https://lwn.net/Articles/834085/
[2] https://en.wikipedia.org/wiki/MVS#MVS_filesystem
[3] https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs

 - t

[toc] | [prev] | [next] | [standalone]

#232745

> I think all these shortened names derive from a time when computing
> resources were limited. If you're using an 80x25 terminal over at 50
> bits per second to a time-shared mainframe, it's more comfortable to
> type "/usr" than it is to type "/Programs". Easier to type "cp" than to
> type "copy", and so on. It's all fairly arbitrary. Why C:\? Why not
> System:\? Convention and history and inertia.

[ I think even back in the early days of time-sharing, connections were
  faster than 50bit/s.  ]

I suspect that the short names were chosen rather so as to minimize the
amount of typing that humans need to do on the command line.
And AFAIK humans haven't evolved enough during the last 50 years to
justify a redesign in this respect ;-)

Of course, the command line is less important nowadays, but using short
names is common practice in all walks of human life, so I really don't
think the reason is technological but rather a result of aesthetic
preference of those who developed the system.


        Stefan

[toc] | [prev] | [next] | [standalone]

#232747 — Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.

[Multipart message — attachments visible in raw view] — view raw

On 11/3/21 6:13 am, Stefan Monnier wrote:
>
> [ I think even back in the early days of time-sharing, connections were
>    faster than 50bit/s.  ]

Common teletype Baud rates were 45.5 and 110. 45.5 was used primarily 
for radio transmission and 110 for landline - both using a modem.

When I started out I used an ASR-33 machine connected via RS-232 to a 
Burroughs B6700 mainframe, though usually programs and data were input 
via punch cards.

-- 
Jeremy

[toc] | [prev] | [next] | [standalone]

#232754

>> [ I think even back in the early days of time-sharing, connections were
>>    faster than 50bit/s.  ]
> Common teletype Baud rates were 45.5 and 110. 45.5 was used primarily for
> radio transmission and 110 for landline - both using a modem.

110bit/s is indeed the number I remember as "the slowest" for
connections to time-sharing machines.  That was generally fast enough to
keep up with a user's typing.


        Stefan

[toc] | [prev] | [next] | [standalone]

#232749 — Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.

On 2021-03-10 17:13 -0500, Stefan Monnier wrote:

>> I think all these shortened names derive from a time when computing
>> resources were limited. If you're using an 80x25 terminal over at 50
>> bits per second to a time-shared mainframe, it's more comfortable to
>> type "/usr" than it is to type "/Programs". Easier to type "cp" than to
>> type "copy", and so on. It's all fairly arbitrary. Why C:\? Why not
>> System:\? Convention and history and inertia.
>
> [ I think even back in the early days of time-sharing, connections were
>   faster than 50bit/s.  ]
>
> I suspect that the short names were chosen rather so as to minimize the
> amount of typing that humans need to do on the command line.

The Unix-Haters Handbook has the following theory:

,----
| Those of us who used early 70s I/O devices suspect the degeneracy stems
| from the speed, reliability, and, most importantly, the keyboard of the
| ASR-33 Teletype, the common input/output device in those days. Unlike
| today’s keyboards, where the distance keys travel is based on feedback
| principles, and the only force necessary is that needed to close a
| microswitch, keys on the Teletype (at least in memory) needed to travel
| over half an inch, and take the force necessary to run a small electric gener-
| ator such as those found on bicycles. You could break your knuckles touch
| typing on those beasts.
| 
| If Dennis and Ken had a Selectric instead of a Teletype, we’d probably be
| typing “copy” and “remove” instead of “cp” and “rm.” Proof again that
| technology limits our choices as often as it expands them.
`----

Cheers,
       Sven

[toc] | [prev] | [next] | [standalone]

#232760 — Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.

[Multipart message — attachments visible in raw view] — view raw

> The Unix-Haters Handbook has the following theory:
>
> ,----
> | Those of us who used early 70s I/O devices suspect the degeneracy stems
> | from the speed, reliability, and, most importantly, the keyboard of the
> | ASR-33 Teletype, the common input/output device in those days. Unlike
> | today’s keyboards, where the distance keys travel is based on feedback
> | principles, and the only force necessary is that needed to close a
> | microswitch, keys on the Teletype (at least in memory) needed to travel
> | over half an inch, and take the force necessary to run a small electric
gener-
> | ator such as those found on bicycles. You could break your knuckles
touch
> | typing on those beasts.
> |
> | If Dennis and Ken had a Selectric instead of a Teletype, we’d probably
be
> | typing “copy” and “remove” instead of “cp” and “rm.” Proof again that
> | technology limits our choices as often as it expands them.

Who knows what really caused that "inconvenience",
but I think it is not there anymore to stop us bring a solution.

[toc] | [prev] | [next] | [standalone]

#232761 — Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.

[Multipart message — attachments visible in raw view] — view raw

>
>
> [ I think even back in the early days of time-sharing, connections were
>   faster than 50bit/s.  ]
>

[quote]
Joy explained that the terse, single character commands and the ability to
type ahead of the display were a result of the slow 300 baud modem he used
when developing the software and that he wanted to be productive when the
screen was painting slower than he could think
[/quote]

https://en.wikipedia.org/wiki/Vi

I believe they had 1 bit per symbol back then, so Joy really had 300 bits
per second:)



> I suspect that the short names were chosen rather so as to minimize the
> amount of typing that humans need to do on the command line.


There was no readline nor shell history, so you had to type the full
directory name each time!.

Imagine someone typing "c:\Documents And Settings\" with 300bit/sec.

They also had small CRTs and slow dot matrix printers.

Every single letter matters: open() has "O_CREAT" flag, not o_create.

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | linux.debian.user

csiph-web