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: > > > > > 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.
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 : > > 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.
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
2021-03-12 0:05 GMT-04:00, David Wright : > 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.
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
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 signature.asc Description: PGP signature
Windows drive letters (was Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.)
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: > 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 signature.asc Description: OpenPGP digital signature
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
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
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. 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 () 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 () 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
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.
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
On Thu, Mar 11, 2021 at 12:35:44PM -0600, David Wright wrote: > Thanks. So really the complaint is just that dpkg -S operates on the > paths of files as packaged, whereas type -p yields canonical paths, > I assume. It'll search through the directories in PATH, in order, and use the first one that contains the program. That may or may not be the "canonical" one, depending on how PATH is set. The other half is that the packages themselves install programs in their traditional FHS locations, not their UsrMerge locations. unicorn:~$ dpkg -L coreutils | grep mkdir /bin/mkdir /usr/share/man/man1/mkdir.1.gz On a non-merged system, the package system's location (/bin/mkdir) and the PATH-searched location (/bin/mkdir) will match. But on a merged system, both /usr/bin/mkdir and /bin/mkdir are valid paths to the command. If /usr/bin is first in PATH, then the PATH search will give /usr/bin/mkdir, which won't match where the package system thinks the program is.
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
On Thu 11 Mar 2021 at 16:09:40 (+1100), David wrote: > On Thu, 11 Mar 2021 at 14:52, David Wright wrote: > > On Wed 10 Mar 2021 at 17:45:48 (-0500), Stefan Monnier wrote: > > > > dpkg -S =foo > > > Sorry, but we're not all familiar with the construct "=foo" > > as interpreted by zsh, oops, Zsh. Can you elaborate on what > > dpkg itself is being fed by this command line. I searched > > man dpkg and man dpkg-query for = but that didn't help. > > It appears to be a Zsh feature, nothing to do with dpkg. > During procrastination, I found this [1]: > ''' > The companion of `~' is `=', which again has to occur at the start > of a word or assignment to be special. The remainder of the word > (here the entire remainder, because directory paths aren't useful) > is taken as the name of an external command, and the word is > expanded to the complete path to that command, using $PATH > just as if the command were to be executed: > > % print =ls > /bin/ls > ''' > [1] http://zsh.sourceforge.net/Guide/zshguide03.html#l58 > > So the above dpkg command seems to be the equivalent of > dpkg -S $(type -p foo) > in Bash. Thanks. So really the complaint is just that dpkg -S operates on the paths of files as packaged, whereas type -p yields canonical paths, I assume. Interactively, I guess that's another reason I hadn't thought of for piping dpkg -S unadornedname | less or using apt-file find likewise piped. As for scripts (other than personal ones), would people write them to rely on this feature? Cheers, David.
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
> And oh, please: drop those whitespaces off file and directory names. This > makes teaching shell scripting to newbies a really #@%*&$¡~ chore. Unless > you want newbies to not learn scripting [1]. On the flip side, it teaches good practices, compared to the all too common scripts using un-quoted $foo which vomits all over your system as soon as it bumps into a file with a not-so-funny character in it. Stefan
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
On Thu, Mar 11, 2021 at 07:48:14AM -0500, Greg Wooledge wrote: > On Thu, Mar 11, 2021 at 10:24:25AM +0100, to...@tuxteam.de wrote: > > And oh, please: drop those whitespaces off file and directory names. This > > makes teaching shell scripting to newbies a really #@%*&$¡~ chore. Unless > > you want newbies to not learn scripting [1]. > > > > Cheers > > > > [1] The generic "you". You (this time the personal) are the last person > >I would suspect of this! > > On the other hand, newbies who fail to learn proper shell scripting > practices go on to write terrible, horrible, bug-ridden shell scripts > that get installed on your[1] computer, and then break. You're right, and then... I wasn't proposing to ignore the problems with those whitespaces. Rather to just push the steep part of the ramp a bit further down the learning path. I still do one-off scripts without getting every nook and cranny of quoting right. When I rework scripts for possible consumption by others, I put much more attention in it. > The notion that "all filenames are alphanumeric plus dots, and maybe > dashes or underscores if you're a rebel" leads to scripts that break > when given the more typical messy filenames that one encounters in > real life. Sure, it's easy to write those scripts, but they're not > correct. They're ticking bombs. Definitely. And pages like yours do an invaluable job in helping people to refine those skills. But I insist: taking everything into account when starting shell programming can build up to be an insurmountable wall. Perhaps I'm wrong, though. Cheers - t signature.asc Description: Digital signature
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
On Thu, Mar 11, 2021 at 10:24:25AM +0100, to...@tuxteam.de wrote: > And oh, please: drop those whitespaces off file and directory names. This > makes teaching shell scripting to newbies a really #@%*&$¡~ chore. Unless > you want newbies to not learn scripting [1]. > > Cheers > > [1] The generic "you". You (this time the personal) are the last person >I would suspect of this! On the other hand, newbies who fail to learn proper shell scripting practices go on to write terrible, horrible, bug-ridden shell scripts that get installed on your[1] computer, and then break. The notion that "all filenames are alphanumeric plus dots, and maybe dashes or underscores if you're a rebel" leads to scripts that break when given the more typical messy filenames that one encounters in real life. Sure, it's easy to write those scripts, but they're not correct. They're ticking bombs.
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
> If that type of mark is possible in your environment, then no, this > shouldn't break anything. > > However, as far as I'm aware, there is no non-file-manager-specific > "hidden" attribute for an *nix filesystem. The traditional way to make > most *nix programs treat a file as hidden is to rename the file so that > it starts with a '.' character - and renaming any of these directories > would, of course, bring back in the "existing programs can't find what > they expect" problem. > > The need to introduce, or take advantage of, a file-manager-specific > "hidden" attribute is exactly the reason why I think a specialized file > manager for the purpose would probably be needed. Oh, I see, that makes sense. Thanks for your help.
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-
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
On 2021-03-10 at 21:22, Cmdte Alpha Tigre Z wrote: >> I don't see why that would come up in this case. >> >> In the model I described, the original paths which you found >> confusing are all still there, and anything which wants to find >> things under them can continue to use them. >> >> All this model does is give those paths an additional name each, >> and maybe go out of its way to hide the original names from you. >> Just because there are new names, and you can't see the old ones >> when you use one specific way of looking, doesn't mean that they >> aren't there or that other things can't see them. > > Oh, now I understand what you mean, instead of doing it like the > merge of /usr, you would make the new paths and not the old ones to > be symbolic links. Yes, it should not break anything. Thanks. > > I have one question, does it work without breaking anything if I mark > the old directories with a hidden atribute instead of some file > manager specific configuration? If that type of mark is possible in your environment, then no, this shouldn't break anything. However, as far as I'm aware, there is no non-file-manager-specific "hidden" attribute for an *nix filesystem. The traditional way to make most *nix programs treat a file as hidden is to rename the file so that it starts with a '.' character - and renaming any of these directories would, of course, bring back in the "existing programs can't find what they expect" problem. The need to introduce, or take advantage of, a file-manager-specific "hidden" attribute is exactly the reason why I think a specialized file manager for the purpose would probably be needed. -- 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 signature.asc Description: OpenPGP digital signature
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
to...@tuxteam.de wrote: > > To whomever tries that approach, my advice would be to have a long look > at all the botches common destop environments managed to do while trying > to internationalise directories beneath a user's home. > > I mean: those things like "Desktop", which, if you do a German installation > are "Schreibtisch". And those aren't "standard Unix" directories, that means > that little software knows them, ergo they had the chance to start off a > relatively clean slate. The XDG conventions are a good thing to look at. https://wiki.debian.org/XDGBaseDirectorySpecification The wonderful thing about standards is that there are so many to choose from! -dsr-
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
On Wed, Mar 10, 2021 at 07:03:00PM -0500, The Wanderer wrote: [...] > Well, if all you want is to be able to have more "newbie-friendly" > descriptive names of the directories, it might be possible to achieve > something like that by the simple addition of a collection of symlinks; > just symlink e.g. "/Configuration" to '/etc', '/Programs' to '/bin', > "/System Programs" to '/sbin', '/User Files' to '/home', et cetera. To whomever tries that approach, my advice would be to have a long look at all the botches common destop environments managed to do while trying to internationalise directories beneath a user's home. I mean: those things like "Desktop", which, if you do a German installation are "Schreibtisch". And those aren't "standard Unix" directories, that means that little software knows them, ergo they had the chance to start off a relatively clean slate. And oh, please: drop those whitespaces off file and directory names. This makes teaching shell scripting to newbies a really #@%*&$¡~ chore. Unless you want newbies to not learn scripting [1]. Cheers [1] The generic "you". You (this time the personal) are the last person I would suspect of this! - t signature.asc Description: Digital signature
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
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 signature.asc Description: Digital signature
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
On Wed, Mar 10, 2021 at 07:35:58PM -0400, Cmdte Alpha Tigre Z wrote: > > Here's one source of breakage I encountered a few times because of this [good example of collateral damage from usrmerge] > Yes, before every possible bug derived from that change is corrected, > you could use some sort path translation program > that takes paths from the caller program and translates it > to some path the called program can understand. Fighting complexity with complexity. Thar sounds like a recipe for an exponential runaway. What could possibly go wrong ;-) > Just thinking. Just musing :) Cheers - t signature.asc Description: Digital signature
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
Cmdte Alpha Tigre Z wrote: > I think too that it could be better than both Debian and Windows are > today. In Windows, if you look under C:\Windows\System32\ it becomes > scary. Same when you open the hood of your car, no? Not to mention aircraft engine ... so to put it short - in life a lot of things are based on conventions (for example language, driving rules, keyboard etc.). You learn those conventions and go along. The conventions help us understand each other. Example: Europe/USA driving on the right side. England/Japan driving on the left side. "Scary" means you have no idea - learn, and it will become clear what is what and why is there. Once a convention was established, it is very hard to change it, because it needs re-consolidation of the knowledge of all the people following the convention. There must be a good reason for this effort and I do not see any. This topic is obsolete.
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
On Thu, 11 Mar 2021 at 14:52, David Wright wrote: > On Wed 10 Mar 2021 at 17:45:48 (-0500), Stefan Monnier wrote: > > dpkg -S =foo > Sorry, but we're not all familiar with the construct "=foo" > as interpreted by zsh, oops, Zsh. Can you elaborate on what > dpkg itself is being fed by this command line. I searched > man dpkg and man dpkg-query for = but that didn't help. It appears to be a Zsh feature, nothing to do with dpkg. During procrastination, I found this [1]: ''' The companion of `~' is `=', which again has to occur at the start of a word or assignment to be special. The remainder of the word (here the entire remainder, because directory paths aren't useful) is taken as the name of an external command, and the word is expanded to the complete path to that command, using $PATH just as if the command were to be executed: % print =ls /bin/ls ''' [1] http://zsh.sourceforge.net/Guide/zshguide03.html#l58 So the above dpkg command seems to be the equivalent of dpkg -S $(type -p foo) in Bash.
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
On Wed 10 Mar 2021 at 17:45:48 (-0500), Stefan Monnier wrote: > > I just read this: > > https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ > > It seems as a good idea that merge of /usr. > > I was wondering what would happen if some program used filesystem paths > > as its input data for some processing task. He he, yes, changing status quo > > is not easy > > Here's one source of breakage I encountered a few times because of this > /usr merge (which I generally welcome, BTW): > > dpkg -S =foo > > this (using the Zsh shell) should give me the name of the Debian package > which provides the command `foo`. It works well for most commands, but > it fails for `ifconfig` because `ifconfig` was actually installed in > /sbin/ifconfig (but the /usr merge makes this same /sbin directory > available under the name /usr/sbin so Zsh thinks that `ifconfig` comes > from `/usr/sbin/ifconfig` whereas `dpkg` doesn't have any record of > installing a `/usr/sbin/ifconfig` file). Sorry, but we're not all familiar with the construct "=foo" as interpreted by zsh, oops, Zsh. Can you elaborate on what dpkg itself is being fed by this command line. I searched man dpkg and man dpkg-query for = but that didn't help. bash: $ dpkg -S ifconfig net-tools: /sbin/ifconfig net-tools: /usr/share/man/de/man8/ifconfig.8.gz net-tools: /usr/share/man/man8/ifconfig.8.gz net-tools: /usr/share/man/pt_BR/man8/ifconfig.8.gz net-tools: /usr/share/man/fr/man8/ifconfig.8.gz $ dpkg -S =ifconfig dpkg-query: no path found matching pattern *=ifconfig* 1 $ Cheers, David.
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
> I don't see why that would come up in this case. > > In the model I described, the original paths which you found confusing > are all still there, and anything which wants to find things under them > can continue to use them. > > All this model does is give those paths an additional name each, and > maybe go out of its way to hide the original names from you. Just > because there are new names, and you can't see the old ones when you use > one specific way of looking, doesn't mean that they aren't there or that > other things can't see them. Oh, now I understand what you mean, instead of doing it like the merge of /usr, you would make the new paths and not the old ones to be symbolic links. Yes, it should not break anything. Thanks. I have one question, does it work without breaking anything if I mark the old directories with a hidden atribute instead of some file manager specific configuration?
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
> In one of the Apple frameworks they have a class called > "INGetAvailableRestaurantReservationBookingDefaultsIntentResponse" Well, I have to say that it is too much even for modern PCs. There should be a limit.
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
>
>
> The ergonomics and aesthetics of the command line are not always reflected
> in programming languages, because the environments are not the same.
> Commands needed to be typed on a teletype console in the middle of the
> night to fix problems. Programs could be developed at leisure, with
> fancy non-paper-spewing terminals, and with editors that would let you
> move the cursor back to previous lines at will to make corrections before
> finally submitting the program for compilation.
>
Yes, but with 300 bits terminal you probably want to type "execv" instead
of "CreateProcess"
(the latter is roughly equivalent of "fork+exec" from the Windows API)
For some reason "old" languages like "C" do not use long names and "modern"
languages like C# and Java do.
Compare "time()" with "System.currentTimeMillis()" :)
> As such, the greater concerns with a programming language are making it
> easy to express your algorithm, and easy to understand existing code.
>
I agree. This is why functional-like syntax-sugar becomes more and more
popular:
In "Kotlin" you can write ``someArray.sortedArray().joinToString(",")`` and
it will take lots of lines to rewrite it in imperative style.
> Conciseness gives a much smaller benefit, and is not prized nearly as
> highly, except among bored kids.
>
I believe this is because we now have smart IDEs with code completion (even
for "vim" we have "ectags"!).
But 45 years ago conciseness was much more important.
In one of the Apple frameworks they have a class called
"INGetAvailableRestaurantReservationBookingDefaultsIntentResponse"
Imagine someone typing it manually on a slow connection and 80x25 screen.
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
On 2021-03-10 at 19:31, Cmdte Alpha Tigre Z wrote: > Written by The Wanderer > >> Well, if all you want is to be able to have more "newbie-friendly" >> descriptive names of the directories, it might be possible to >> achieve something like that by the simple addition of a collection >> of symlinks; just symlink e.g. "/Configuration" to '/etc', >> '/Programs' to '/bin', "/System Programs" to '/sbin', '/User Files' >> to '/home', et cetera. >> >> That wouldn't get rid of the existing names, but it would be simple >> to implement as a single nearly-empty package. >> >> I imagine one could also set up a custom configuration of some >> file browser such that it would hide displaying the "real" names, >> and then ship a sort of micro-distro (installer task, maybe?) which >> installs the symlinking package and that file browser as part of >> its standard UI setup. It wouldn't be perfect, but it might meet >> the described want. > > I was thinking about that, but something could go wrong with that: > > Written by me. > >>> I was wondering what would happen if some program used filesystem >>> paths as its input data for some processing task. He he, yes, >>> changing status quo is not easy I don't see why that would come up in this case. In the model I described, the original paths which you found confusing are all still there, and anything which wants to find things under them can continue to use them. All this model does is give those paths an additional name each, and maybe go out of its way to hide the original names from you. Just because there are new names, and you can't see the old ones when you use one specific way of looking, doesn't mean that they aren't there or that other things can't see them. That would mean that you'd probably still see the original names in e.g. program error messages - but you could continue to use the new ones when navigating through the filesystem, and the circumstances in which it could lead to something breaking would be relatively rare (and maybe even nonexistent). That said, I repeat, I don't think the benefit from this would be remotely worth the effort that implementing it would require. If you happen to think it would, then you are entirely free to implement it. Doing the first part (creating the new names) locally on a per-machine basis is a trivial matter of setting up a handful of symlinks. Anyone with much *nix experience could do this casually, if given root access on the relevant computer. Doing the second part is a complex and nontrivial matter of A: finding a file-browser program which can be configured to hide files without having to rename them and creating a suitable configuration for the names you don't want to see, B: finding a file-browser program which can't be configured to do that and modifying it so that either it can or it just automatically hides them without configuration, or C: writing a file-browser program with those capabilities, entirely from scratch. If the type of file-browser program required for option A already exists, option A could probably be done in a week or less by someone with enough *nix experience to know how to search out programs and learn to configure them. Option B would probably take weeks at least, for someone who already has skill with programming. Option C would probably take months at least, for a reasonably expert programmer. Doing the third part (the "micro-distro") is probably not as hard as the second part, but presents an entirely distinct kind of challenge, and I don't even know how to estimate how long it might take. -- 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 signature.asc Description: OpenPGP digital signature
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
Weaver wrote: There is nothing `unfriendly' concerning the filesystem heirarchy. What negative experiences have you had with it, so far, that inclines you to this point of view? I too find the old-fashioned Unix common folder names and filesystem organization to be unfriendly, inconvenient, and I find them to be needlessly hard to understand to me. And I'm familiar with their origins in Unix. Friendliness and convenience strike me as subjective. I don't know precisely what a different hierarchy would be but it's not hard for me to imagine what would puzzle the uninitiated. It seems to me something that could simultaneously work technically and facilitate easier at-a-glance understanding without need for a decades-old history lesson. As for negative experiences, I think merely understanding one's own Debian system with a shallowed learning curve is a sufficient reason to warrant exploring the topic and experimenting with alternatives.
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
> As such, the greater concerns with a programming language are making it > easy to express your algorithm, and easy to understand existing code. > Conciseness gives a much smaller benefit, and is not prized nearly as > highly, except among bored kids. Yes, every approach has its pros and cons: its readability vs conciseness. If I wanted to write a common path the short way, I would rather use a variable.
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
Written by The Wanderer > Well, if all you want is to be able to have more "newbie-friendly" > descriptive names of the directories, it might be possible to achieve > something like that by the simple addition of a collection of symlinks; > just symlink e.g. "/Configuration" to '/etc', '/Programs' to '/bin', > "/System Programs" to '/sbin', '/User Files' to '/home', et cetera. > > That wouldn't get rid of the existing names, but it would be simple to > implement as a single nearly-empty package. > > I imagine one could also set up a custom configuration of some file > browser such that it would hide displaying the "real" names, and then > ship a sort of micro-distro (installer task, maybe?) which installs the > symlinking package and that file browser as part of its standard UI > setup. It wouldn't be perfect, but it might meet the described want. I was thinking about that, but something could go wrong with that: Written by me. > >> I was wondering what would happen if some program used filesystem paths > >> as its input data for some processing task. He he, yes, changing status quo > >> is not easy Written by Stefan Monnier > > Here's one source of breakage I encountered a few times because of this > > /usr merge (which I generally welcome, BTW): > > > > dpkg -S =foo > > > > this (using the Zsh shell) should give me the name of the Debian package > > which provides the command `foo`. It works well for most commands, but > > it fails for `ifconfig` because `ifconfig` was actually installed in > > /sbin/ifconfig (but the /usr merge makes this same /sbin directory > > available under the name /usr/sbin so Zsh thinks that `ifconfig` comes > > from `/usr/sbin/ifconfig` whereas `dpkg` doesn't have any record of > > installing a `/usr/sbin/ifconfig` file). Written by me > Yes, before every possible bug derived from that change is corrected, > you could use some sort path translation program > that takes paths from the caller program and translates it > to some path the called program can understand. > Just thinking. It could happen again.
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
On Thu, Mar 11, 2021 at 02:56:16AM +0300, IL Ka wrote: > They also had small CRTs and slow dot matrix printers. > > Every single letter matters: open() has "O_CREAT" flag, not o_create. But: Ken Thompson was once asked what he would do differently if he were redesigning the UNIX system. His reply: "I'd spell creat with an e." - Kernighan, Brian W.; Pike, Rob (1984). The UNIX programming environment. That one refers to creat(2) rather than O_CREAT, of course. It's possible that the spelling of O_CREAT was derived from creat(2) for consistency, but I don't know whether that's true. The ergonomics and aesthetics of the command line are not always reflected in programming languages, because the environments are not the same. Commands needed to be typed on a teletype console in the middle of the night to fix problems. Programs could be developed at leisure, with fancy non-paper-spewing terminals, and with editors that would let you move the cursor back to previous lines at will to make corrections before finally submitting the program for compilation. As such, the greater concerns with a programming language are making it easy to express your algorithm, and easy to understand existing code. Conciseness gives a much smaller benefit, and is not prized nearly as highly, except among bored kids.
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
On 2021-03-10 at 16:04, Andrei POPESCU wrote: > On Mi, 10 mar 21, 15:26:41, Cmdte Alpha Tigre Z wrote: >> Thanks for your encouragement. I hope someday it becomes real, and >> only with the installation of one meta-package. > > Based on Debian's experience with usr-merge I'm guessing it's *much* > more involved than that. > > Paths are likely hard coded in a *lot* of places (besides the usual > suspects, like shebangs). > > https://wiki.debian.org/UsrMerge Well, if all you want is to be able to have more "newbie-friendly" descriptive names of the directories, it might be possible to achieve something like that by the simple addition of a collection of symlinks; just symlink e.g. "/Configuration" to '/etc', '/Programs' to '/bin', "/System Programs" to '/sbin', '/User Files' to '/home', et cetera. That wouldn't get rid of the existing names, but it would be simple to implement as a single nearly-empty package. I imagine one could also set up a custom configuration of some file browser such that it would hide displaying the "real" names, and then ship a sort of micro-distro (installer task, maybe?) which installs the symlinking package and that file browser as part of its standard UI setup. It wouldn't be perfect, but it might meet the described want. Then again, I seriously doubt the result would be remotely worth the amount of effort which would have to be invested to implement it. Also, I don't think it's terribly likely that such a package would be accepted into Debian proper, although one could certainly make use of it locally if one so desired; it would be unlikely to depend on anything which changes enough for it to be able to break, so this is one case where maintaining a local .deb (or even downloading and installing one created by someone else) probably wouldn't hurt. -- 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 signature.asc Description: OpenPGP digital signature
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
> > > [ 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.
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
> 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.
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
> Here's one source of breakage I encountered a few times because of this > /usr merge (which I generally welcome, BTW): > > dpkg -S =foo > > this (using the Zsh shell) should give me the name of the Debian package > which provides the command `foo`. It works well for most commands, but > it fails for `ifconfig` because `ifconfig` was actually installed in > /sbin/ifconfig (but the /usr merge makes this same /sbin directory > available under the name /usr/sbin so Zsh thinks that `ifconfig` comes > from `/usr/sbin/ifconfig` whereas `dpkg` doesn't have any record of > installing a `/usr/sbin/ifconfig` file). Yes, before every possible bug derived from that change is corrected, you could use some sort path translation program that takes paths from the caller program and translates it to some path the called program can understand. Just thinking.
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
> > 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. :)
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
>> [ 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
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
> PS: And of course, if you want something better you may want to > challenge some of the assumptions as well, such as the fact that it > needs to be a hierarchy. Thanks, I did not realized that possibility. There are tags too made to identify files or directories in a non-hierarchical manner. For the filesystem, though, I think that a hierarchy is very organized, and if well designed, you should be able to find there whatever you want without knowing where it is, just starting at the root directory. I think too that it could be better than both Debian and Windows are today. In Windows, if you look under C:\Windows\System32\ it becomes scary.
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
> I just read this: > https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ > It seems as a good idea that merge of /usr. > I was wondering what would happen if some program used filesystem paths > as its input data for some processing task. He he, yes, changing status quo > is not easy Here's one source of breakage I encountered a few times because of this /usr merge (which I generally welcome, BTW): dpkg -S =foo this (using the Zsh shell) should give me the name of the Debian package which provides the command `foo`. It works well for most commands, but it fails for `ifconfig` because `ifconfig` was actually installed in /sbin/ifconfig (but the /usr merge makes this same /sbin directory available under the name /usr/sbin so Zsh thinks that `ifconfig` comes from `/usr/sbin/ifconfig` whereas `dpkg` doesn't have any record of installing a `/usr/sbin/ifconfig` file). Stefan
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
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
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 OpenPGP_signature Description: OpenPGP digital signature
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
> 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
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
> While I was making my research before installing Debian > I saw that the filesystem hierarchy is not so friendly > (I'm new to GNU/Linux operating systems). "Not friendly" indicates that you see a problem with it, but doesn't really say what problem it was and even less how to fix it. I personally don't know what a "friendly" filesystem hierarchy might look like. I'm sure we can do better than what Debian has (and what Windows has as well), but until someone has a very clear idea of that should look like, it's unlikely we'll see much change. Stefan PS: And of course, if you want something better you may want to challenge some of the assumptions as well, such as the fact that it needs to be a hierarchy.
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
> 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
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
> Joe wrote: > > There was a time when 'software' and 'applications' were two different > > and distinct things, when applications were user programs and software > > was the set of programs that made the computer work, today called system > > software. A computer as delivered contained both hardware and software, > > and it was up to the owner to write the applications. OK, that's going > > back a bit... > > > Once upon a time there were programmers. Frequently they had to > build the hardware that they programmed -- indeed, it was a bit > of a luxury to only be a programmer, and not also have > responsibility for hardware maintenance (or design). > > Then there were systems programmers and application programmers. > Systems programmers wrote operating systems and utilities for > them. Applications programmers wrote applications. There was a lot of crossover. > > Then there were operators, systems programmers and application > programmers. Operator was a junior position that did physical > things (mount tapes, plug in cables) and ran commands to do > things on the systems. They usually moved up to being -- > > Systems administrators, who did some programming in service to > the systems, but not too much. The more senior a sysadmin was, > the more time they spent programming and the less time they > spent doing physical things, unless they wanted to do that. > > Sysadmins started to specialize. People who configured switches > and routers and talked to telephone companies became > "network engineers". People who spent time working on > firewalls and security policies and thinking about that became > "security engineers". Junior people who read scripts to > end users became the helpdesk. And so forth. > > Then we noticed that a bunch of people were doing things > manually when they should be automated. This was especially bad > in places where there were no senior sysadmins or systems > programmers. But we did have the internet, and senior sysadmins > got together and started writing tools to make their lives > easier: infrastructure automation. Current tools for that > include chef, puppet, ansible, salt... > > (all of this is largely quoting myself circa April 2016) > > -dsr- Wow, it is very impressive how things evolve. Since this thread is about this filesystem hierarchy debate, I would like to add this post I just read: http://lists.busybox.net/pipermail/busybox/2010-December/074114.html Looks like Wikipedia is right: many years ago, /usr meant "user", and there was no /home
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
Joe wrote: > There was a time when 'software' and 'applications' were two different > and distinct things, when applications were user programs and software > was the set of programs that made the computer work, today called system > software. A computer as delivered contained both hardware and software, > and it was up to the owner to write the applications. OK, that's going > back a bit... Once upon a time there were programmers. Frequently they had to build the hardware that they programmed -- indeed, it was a bit of a luxury to only be a programmer, and not also have responsibility for hardware maintenance (or design). Then there were systems programmers and application programmers. Systems programmers wrote operating systems and utilities for them. Applications programmers wrote applications. There was a lot of crossover. Then there were operators, systems programmers and application programmers. Operator was a junior position that did physical things (mount tapes, plug in cables) and ran commands to do things on the systems. They usually moved up to being -- Systems administrators, who did some programming in service to the systems, but not too much. The more senior a sysadmin was, the more time they spent programming and the less time they spent doing physical things, unless they wanted to do that. Sysadmins started to specialize. People who configured switches and routers and talked to telephone companies became "network engineers". People who spent time working on firewalls and security policies and thinking about that became "security engineers". Junior people who read scripts to end users became the helpdesk. And so forth. Then we noticed that a bunch of people were doing things manually when they should be automated. This was especially bad in places where there were no senior sysadmins or systems programmers. But we did have the internet, and senior sysadmins got together and started writing tools to make their lives easier: infrastructure automation. Current tools for that include chef, puppet, ansible, salt... (all of this is largely quoting myself circa April 2016) -dsr-
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
On Mi, 10 mar 21, 15:26:41, Cmdte Alpha Tigre Z wrote: > > You're not only allowed to think that, you're allowed to get > > people together and do it. > > > > All the code in Debian proper has free licenses, and you're > > welcome to create a Debian derivation that conforms to your idea > > of what is proper. > > > > It's going to be a lot of work, though. You should probably > > start with investigating the FHS and debootstrap to figure out what you > > want. > > > > -dsr- > > Thanks for your encouragement. I hope someday it becomes real, > and only with the installation of one meta-package. Based on Debian's experience with usr-merge I'm guessing it's *much* more involved than that. Paths are likely hard coded in a *lot* of places (besides the usual suspects, like shebangs). https://wiki.debian.org/UsrMerge Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
On Wed, 10 Mar 2021 16:19:42 -0400 Cmdte Alpha Tigre Z wrote: > > if you want to see an example of what it takes to > > make changes to this sort of layout google "Debian > > merged /usr" and read those threads. :) > > I just read this: > https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ > It seems as a good idea that merge of /usr. > I was wondering what would happen if some program used filesystem > paths as its input data for some processing task. He he, yes, > changing status quo is not easy > Something happened. Prior to this it wasn't unusual to put /usr on a separate partition, sometimes making it read-only for a bit of extra security. Today, software on /usr is required during boot, and I think that came as a bit of a surprise to the separate-/usr people. It is still possible to keep /usr separate if really desired, but the initramfs needs to know how to mount it at boot time. There was a time when 'software' and 'applications' were two different and distinct things, when applications were user programs and software was the set of programs that made the computer work, today called system software. A computer as delivered contained both hardware and software, and it was up to the owner to write the applications. OK, that's going back a bit... -- Joe
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
Cmdte Alpha Tigre Z wrote: > > if you want to see an example of what it takes to > > make changes to this sort of layout google "Debian > > merged /usr" and read those threads. :) > > I just read this: > https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ > It seems as a good idea that merge of /usr. I'm just going to point out, since you probably don't know this: there are certain topics which inspire religious-level disagreements. One of them is the choice of text editor. Yes, really. However, that one is now, forty five years later, nearly extinct as long as at least the major contenders are all available on an equal footing. Another is, effectively, any software system led by Lennart Poettering, which includes PulseAudio and systemd. That one isn't dead, and isn't resolved. -dsr-
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
> if you want to see an example of what it takes to > make changes to this sort of layout google "Debian > merged /usr" and read those threads. :) I just read this: https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ It seems as a good idea that merge of /usr. I was wondering what would happen if some program used filesystem paths as its input data for some processing task. He he, yes, changing status quo is not easy
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.
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
> You're not only allowed to think that, you're allowed to get > people together and do it. > > All the code in Debian proper has free licenses, and you're > welcome to create a Debian derivation that conforms to your idea > of what is proper. > > It's going to be a lot of work, though. You should probably > start with investigating the FHS and debootstrap to figure out what you want. > > -dsr- Thanks for your encouragement. I hope someday it becomes real, and only with the installation of one meta-package.
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
* 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 signature.asc Description: PGP signature
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
Le 10/03/2021 à 04:08, Cmdte Alpha Tigre Z a écrit : > > Hello. > > While I was making my research before installing Debian > I saw that the filesystem hierarchy is not so friendly > (I'm new to GNU/Linux operating systems). > I saw there was a distribution called GoboLinux which > addressed that inconvenience, but according to a DistroWatch review, > it is not usable at all. > > In my opinion, I think there would be no need to make another distro > to make such customizations to the system, it would be better > if it were implemented at a package level on an existing distro. > > So, my question is: Is there a way to put another, more friendly, > filesystem hierarchy to Debian, like the one of GoboLinux? > > Thanks in advance for your answers. > Your question is equivalent to saying "is there a way to put commands in mly car a more friendly way". It is important that people find thiungs where they are used to find them. Every placement will need some learning for the beginners, and changing things won't help beginners and will confuse experienced users. At the beginiing of minitel in France (a terminal allowing to access directories and other networking services) builders chose to have an alphabetic keyboard "more friendly". Second version had the traditional french AZERTY Keyboard, for this exact reason : it did not help beginners and confused people who knew to use a keyboard.
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
Cmdte Alpha Tigre Z wrote: > 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. You're not only allowed to think that, you're allowed to get people together and do it. All the code in Debian proper has free licenses, and you're welcome to create a Debian derivation that conforms to your idea of what is proper. It's going to be a lot of work, though. You should probably start with investigating the FHS and debootstrap to figure out what you want. -dsr-
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
> Think of it as a vocabulary shift when moving from one section of the country to another. I felt I had to learn a new language when moving from very urban New York to rural Missouri. You get used to it ;} Yes, it is my only option for now. Well, thank you all for your help. Have a good day everyone.
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
> As above, there's no inherent reason this naming convention *couldn't* > be changed, but doing so would be a vast and invasive thing, which would > probably break at least a few things that one might not notice. Doing it > at all would basically require you to design the entire distribution > around the new naming model - and so far, AFAIK, nobody with the > resources to put together a distro has found doing this to be worth the > bother. Yes, you're right there. It is not easy to make such changes. On practical terms: very difficult. But, if you use some path translation mechanism to bring compatibility between the two systems, they could work together without breaking anything... just thinking. It looks like if I want it, I will have to do it by myself, since today no one has made it a reality.
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
> 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...
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
On 03/10/2021 09:01 AM, songbird wrote: Cmdte Alpha Tigre Z wrote: ... Well, yes, as I said, my problem is quite trivial. I was just thinking it could be a little improvement. understand the complexity involved of managing 51,000 packages already established procedures and tools set up to work with things as they currently are. add in that this is all for multiple hardware types from embedded systems up to mainframes. if you want to see an example of what it takes to make changes to this sort of layout google "Debian merged /usr" and read those threads. :) Keeping in mind "cruel" [c.f. https://en.wikipedia.org/wiki/Cruel_and_unusual_punishment] N.B. Tongue *ONLY* slightly "in cheek".
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
Cmdte Alpha Tigre Z wrote: ... > Well, yes, as I said, my problem is quite trivial. > I was just thinking it could be a little improvement. understand the complexity involved of managing 51,000 packages already established procedures and tools set up to work with things as they currently are. add in that this is all for multiple hardware types from embedded systems up to mainframes. if you want to see an example of what it takes to make changes to this sort of layout google "Debian merged /usr" and read those threads. :) songbird
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
* On 2021 10 Mar 07:20 -0600, Cmdte Alpha Tigre Z wrote: > > i wouldn't bother. really it is just a huge waste of time > > for no real gain. > > > > the problem is that you are new to linux/unix type system > > and so you don't understand the history or layout as it is. > > > > learn what is there as it is. you rarely need to work > > outside /home/ for most things as a normal > > user. when i install a new system i like to have /home > > in a different partition from the rest of the system. > > > > as root you may need to understand more but it isn't > > that often you should be having to do a whole lot of > > changes once you have a stable install set up. > > > > > > songbird > > Well, yes, as I said, my problem is quite trivial. > I was just thinking it could be a little improvement. As noted, either approach has positive and negative attributes. For Debian, the system is curated in such a way so that "dependency hell" is minimized. Problems can arise when one installs packages from outside of the Debian packaging system. One key thing to remember is that Debian is not a bug-for-bug replacement for MS Windows, it is its own system. May I suggest the Debian Reference manual as a good starting point: https://www.debian.org/doc/user-manuals#quick-reference - 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 signature.asc Description: PGP signature
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
> > > but it could have been "Shared" or "Resources". > You see what I mean? > > > A bit of history: https://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/usr.html Initial idea was to put everything that is essential for the system to boot to the root filesystem (/bin, /sbin etc). While user homes, docs and useful tools (like "vi") were installed in "/usr". Apps in the root were compiled statically not to depend on anything. Some OSes (especially BSDs) used different filesystem options for the root (noatime, no soft updates (it was before journaling filesystems were created)) Some Windows users install the system to "C:" and all applications, docs and files to the "D:". "D:" was like "/usr" here. But things changed, at least in the Linux world (AFAIK OpenBSD still uses "classical" hierarchy): https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ Debian now merges several folders inside of "usr": https://wiki.debian.org/UsrMerge
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
On 03/10/2021 07:07 AM, songbird wrote: Cmdte Alpha Tigre Z wrote: ... While I was making my research before installing Debian I saw that the filesystem hierarchy is not so friendly (I'm new to GNU/Linux operating systems). I saw there was a distribution called GoboLinux which addressed that inconvenience, but according to a DistroWatch review, it is not usable at all. In my opinion, I think there would be no need to make another distro to make such customizations to the system, it would be better if it were implemented at a package level on an existing distro. So, my question is: Is there a way to put another, more friendly, filesystem hierarchy to Debian, like the one of GoboLinux? Thanks in advance for your answers. i wouldn't bother. really it is just a huge waste of time for no real gain. the problem is that you are new to linux/unix type system and so you don't understand the history or layout as it is. learn what is there as it is. you rarely need to work outside /home/ for most things as a normal user. when i install a new system i like to have /home in a different partition from the rest of the system. as root you may need to understand more but it isn't that often you should be having to do a whole lot of changes once you have a stable install set up. Think of it as a vocabulary shift when moving from one section of the country to another. I felt I had to learn a new language when moving from very urban New York to rural Missouri. You get used to it ;}
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
On 2021-03-10 at 08:09, Cmdte Alpha Tigre Z wrote: > It's what I'm trying to say, it looks like something, because someday > ago it was, but it is something else. > > With whole respect to UNIX, do we really need backward compatibility > with it, or something alike? Absolutely need? No. Does it make sense to retain it, in the absence of reason to use another naming standard? Yes. Given the need to be compatible with software that already exists out there, trying to change this is likely to involve breaking enough things that it's just not remotely worth the effort. > I saw another directory called "etc" that sounds like "etcetera" but > appears to be "configurations". What does "etc" mean? Again, I'm > not trying to be destructively critical, just asking. It does stand for "et cetera", yes. It's not inherently exclusively configuration files, that's just the primary thing that gets kept there by standardized convention. To understand the reason for the name, you'd again have to look back into the history of UNIX. As above, there's no inherent reason this naming convention *couldn't* be changed, but doing so would be a vast and invasive thing, which would probably break at least a few things that one might not notice. Doing it at all would basically require you to design the entire distribution around the new naming model - and so far, AFAIK, nobody with the resources to put together a distro has found doing this to be worth the bother. -- 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 signature.asc Description: OpenPGP digital signature
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
> i wouldn't bother. really it is just a huge waste of time > for no real gain. > > the problem is that you are new to linux/unix type system > and so you don't understand the history or layout as it is. > > learn what is there as it is. you rarely need to work > outside /home/ for most things as a normal > user. when i install a new system i like to have /home > in a different partition from the rest of the system. > > as root you may need to understand more but it isn't > that often you should be having to do a whole lot of > changes once you have a stable install set up. > > > songbird Well, yes, as I said, my problem is quite trivial. I was just thinking it could be a little improvement.
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
Hi, Cmdte Alpha Tigre Z wrote: > > By the way, what does "usr" mean? The Wanderer wrote: > I can't completely rule out a derivation from "user", but I don't think > that's usually considered likely. My german translation of S.R. Bourne's The Unix Syistem of 1983 states: "Der Katalog /usr enthaelt Kataloge des Systems und der Benutzer." Back translated: "The directory /usr contains directories of the system and the users." https://en.wikipedia.org/wiki/Unix_filesystem#Conventional_directory_layout states /usr The "user file system": originally the directory holding user home directories, but already by the Third Edition of Research Unix, ca. 1973, reused to split the operating system's programs over two disks (one of them a 256K fixed-head drive) so that basic commands would either appear in /bin or /usr/bin. So it was the usual effect of the system oozing out of the hardware capacity. Nowadays its KDE and 1 GB of RAM. Back then it was /bin and a 256K disk. Have a nice day :) Thomas
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
Cmdte Alpha Tigre Z wrote: ... > While I was making my research before installing Debian > I saw that the filesystem hierarchy is not so friendly > (I'm new to GNU/Linux operating systems). > I saw there was a distribution called GoboLinux which > addressed that inconvenience, but according to a DistroWatch review, > it is not usable at all. > > In my opinion, I think there would be no need to make another distro > to make such customizations to the system, it would be better > if it were implemented at a package level on an existing distro. > > So, my question is: Is there a way to put another, more friendly, > filesystem hierarchy to Debian, like the one of GoboLinux? > > Thanks in advance for your answers. i wouldn't bother. really it is just a huge waste of time for no real gain. the problem is that you are new to linux/unix type system and so you don't understand the history or layout as it is. learn what is there as it is. you rarely need to work outside /home/ for most things as a normal user. when i install a new system i like to have /home in a different partition from the rest of the system. as root you may need to understand more but it isn't that often you should be having to do a whole lot of changes once you have a stable install set up. songbird
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
> Wikipedia [1] leans towards the derivation from "user": > > usr The "user file system": originally the directory holding > user home directories,[15] but already by the Third Edition > of Research Unix, ca. 1973, reused to split the operating > system's programs over two disks [...] > > ...and as usual they have references to follow, which I'm too lazy to > do now (as usual ;-) > > Cheers > > [1] https://en.wikipedia.org/wiki/Usr > > - t It's what I'm trying to say, it looks like something, because someday ago it was, but it is something else. With whole respect to UNIX, do we really need backward compatibility with it, or something alike? I saw another directory called "etc" that sounds like "etcetera" but appears to be "configurations". What does "etc" mean? Again, I'm not trying to be destructively critical, just asking.
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
> I've traditionally understood it to stand for "UNIX Shared Resources", > but V.E.R.A. (the Virtual Entity of Relevant Acronyms) doesn't list that > as a definition; the nearest definition it does have which looks like it > might be related is "User Service Routines". So it is an acronym then. Thanks for your answer, it gives me some light about everything. I think it would be better if it was called "USR" at least to reflect the fact it is an acronym, but it could have been "Shared" or "Resources". You see what I mean? > -- >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 > Hmm, very interesting this quote.
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
On 10/03/2021 12:52, to...@tuxteam.de wrote: > On Wed, Mar 10, 2021 at 07:45:16AM -0500, The Wanderer wrote: >> On 2021-03-10 at 07:27, Cmdte Alpha Tigre Z wrote: >> >>> By the way, what does "usr" mean? I thought it was "user" untill I >>> took a look inside. Just asking. >> I've traditionally understood it to stand for "UNIX Shared Resources", >> but V.E.R.A. (the Virtual Entity of Relevant Acronyms) doesn't list that >> as a definition; the nearest definition it does have which looks like it >> might be related is "User Service Routines". >> >> I can't completely rule out a derivation from "user", but I don't think >> that's usually considered likely. > Wikipedia [1] leans towards the derivation from "user": > > usr The "user file system": originally the directory holding > user home directories,[15] but already by the Third Edition > of Research Unix, ca. 1973, reused to split the operating > system's programs over two disks [...] > > ...and as usual they have references to follow, which I'm too lazy to > do now (as usual ;-) 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 OpenPGP_signature Description: OpenPGP digital signature
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
On Wed, Mar 10, 2021 at 07:45:16AM -0500, The Wanderer wrote: > On 2021-03-10 at 07:27, Cmdte Alpha Tigre Z wrote: > > > By the way, what does "usr" mean? I thought it was "user" untill I > > took a look inside. Just asking. > > I've traditionally understood it to stand for "UNIX Shared Resources", > but V.E.R.A. (the Virtual Entity of Relevant Acronyms) doesn't list that > as a definition; the nearest definition it does have which looks like it > might be related is "User Service Routines". > > I can't completely rule out a derivation from "user", but I don't think > that's usually considered likely. Wikipedia [1] leans towards the derivation from "user": usr The "user file system": originally the directory holding user home directories,[15] but already by the Third Edition of Research Unix, ca. 1973, reused to split the operating system's programs over two disks [...] ...and as usual they have references to follow, which I'm too lazy to do now (as usual ;-) Cheers [1] https://en.wikipedia.org/wiki/Usr - t signature.asc Description: Digital signature
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
On 2021-03-10 at 07:27, Cmdte Alpha Tigre Z wrote: > By the way, what does "usr" mean? I thought it was "user" untill I > took a look inside. Just asking. I've traditionally understood it to stand for "UNIX Shared Resources", but V.E.R.A. (the Virtual Entity of Relevant Acronyms) doesn't list that as a definition; the nearest definition it does have which looks like it might be related is "User Service Routines". I can't completely rule out a derivation from "user", but I don't think that's usually considered likely. -- 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 signature.asc Description: OpenPGP digital signature
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
On 03/09/2021 23:54, "Weaver" wrote: > What negative experiences have you had with it, so far, that inclines > you to this point of view? On 03/10/2021 05:08, "Darac Marjal" wrote: > How is the filesystem "unfriendly"? It's a filing system. It's purpose > is to make it easier to find files. > Perhaps this is something that could be implemented by the base > operating system, but then we come back to the original question of WHY? > What's WRONG with the current filesystem hierarchy, in your opinion? You > stated that it's "unfriendly", but without backing up that assertion. Well, I just said "unfriendly" because the directories' names don't tell you with much clarity what is in there. Of course, since you are accustomed to it, it would look totally normal for you. > Neither approach is inherently better than the other. And both > approaches allow for some usage the other way. On Linux, you can make > /opt/some-external-program and dump all of that external programs > binaries, libaries, data files there. On Windows, it's not unheard of > for applications to drop libraries into C:\Windows\System32, knowing > that that's a shared folder which anyone can reach. Hmm, it doesn't necessarily means another philosophy. Perhaps on Windows, programs have they own libraries to avoid compatibility issues. I don't think it would be a good idea to let third-parties programs modify your system at will. If Windows provided that libraries by itself as Debian does, things would have been different (although compatibility issues could arise without a mix of both approaches). > I think you're wrong here, though. It WOULD be necessary to make another > distro. If you say to developers "you can put your libraries into > /usr/lib *or* /Program/$pkgname/Libraries/", then you're going to have > problems. Look at the issues currently happening because Debian has said > "You can uses SysV *or* systemd": not every package is at the same level > of parity there. Perhaps you're right here, but some experimenting could help to see if it would work. Please, let me explain better allowing you to read this: https://github.com/gobolinux/Documentation/wiki/The-GoboLinux-Filesystem-Hierarchy That hierarchy is not perfect: for example, the Index is a very weird approach to solve some problems, although it is not so bad; but at least is a starting point. You could put libraries on /System/Libraries instead of /usr/lib. It looks more descriptive. He he, yes, my problem is a little trivial one, but I just wanted to see there was a solution already. By the way, what does "usr" mean? I thought it was "user" untill I took a look inside. Just asking.
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
On 10/03/2021 03:08, Cmdte Alpha Tigre Z wrote: > > Hello. > > While I was making my research before installing Debian > I saw that the filesystem hierarchy is not so friendly > (I'm new to GNU/Linux operating systems). > How is the filesystem "unfriendly"? It's a filing system. It's purpose is to make it easier to find files. > > I saw there was a distribution called GoboLinux which > addressed that inconvenience, but according to a DistroWatch review, > it is not usable at all. > Looking briefly at the GoboLinux website, it groups files by program (so you get paths like /Programs/GTK+/1.2.10/lib/libgtk-1.2.so.0.9.1). What you have there is a difference in philosophy (you might want to read "The Cathedral and the Bazaar" by Eric S Raymond for a good primer on some of the philosophy behind Linux). GoboLinux (and Microsoft Windows) are espousing the philosophy that libraries "belong" to a program. "This is *my* GTK library. No, no you can't use it!". But the UNIX (and, by extension, Linux) philosophy is that libraries are fundamentally shared. "Here's a library for drawing doodads. If anyone wants to draw doodads, they can use it". So, the filesystem on Linux reflects that. Libraries go here, binaries (applications which the user actually calls) go over there and so on. Neither approach is inherently better than the other. And both approaches allow for some usage the other way. On Linux, you can make /opt/some-external-program and dump all of that external programs binaries, libaries, data files there. On Windows, it's not unheard of for applications to drop libraries into C:\Windows\System32, knowing that that's a shared folder which anyone can reach. > In my opinion, I think there would be no need to make another distro > to make such customizations to the system, it would be better > if it were implemented at a package level on an existing distro. > I think you're wrong here, though. It WOULD be necessary to make another distro. If you say to developers "you can put your libraries into /usr/lib *or* /Program/$pkgname/Libraries/", then you're going to have problems. Look at the issues currently happening because Debian has said "You can uses SysV *or* systemd": not every package is at the same level of parity there. Perhaps this is something that could be implemented by the base operating system, but then we come back to the original question of WHY? What's WRONG with the current filesystem hierarchy, in your opinion? You stated that it's "unfriendly", but without backing up that assertion. > So, my question is: Is there a way to put another, more friendly, > filesystem hierarchy to Debian, like the one of GoboLinux? > > Thanks in advance for your answers. > OpenPGP_signature Description: OpenPGP digital signature
Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.
On 10-03-2021 13:08, Cmdte Alpha Tigre Z wrote: > Hello. > > While I was making my research before installing Debian > I saw that the filesystem hierarchy is not so friendly > (I'm new to GNU/Linux operating systems). Yes, you are. There is nothing `unfriendly' concerning the filesystem heirarchy. What negative experiences have you had with it, so far, that inclines you to this point of view? > I saw there was a distribution called GoboLinux which > addressed that inconvenience, but according to a DistroWatch review, > it is not usable at all. Again, there is no inconvenience. > In my opinion, I think there would be no need to make another distro > to make such customizations to the system, it would be better > if it were implemented at a package level on an existing distro. > > So, my question is: Is there a way to put another, more friendly, > filesystem hierarchy to Debian, like the one of GoboLinux? If Gobolinux is not usable, as you say, why do you seek to emulate it? The current file system set up is far from `unfriendly', in my experience. Cheers! Harry. -- `The World is not dangerous because of those who do harm but because of those who look on without doing anything'. -- Albert Einstein
