WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki

Author Topic: would /usr merge be advantageous for TCL in any way?  (Read 2858 times)

Offline GNUser

  • Wiki Author
  • Hero Member
  • *****
  • Posts: 1525
would /usr merge be advantageous for TCL in any way?
« on: February 28, 2024, 04:25:23 PM »
Several *nixes (Debian, Devuan, Arch, Fedora, Solaris, possibly others) either have already implemented or will soon be implementing "merged /usr" where /{bin,sbin,lib,lib64} are just symlinks to /usr/{bin,sbin,lib,lib64}

Supposed advantages of this filesystem hierarchy are outlined here.

I know that in TCL there is the convention of /usr/local/{bin,sbin,lib} being reserved for extensions. A merged /usr would not interfere with this.

Would a merged /usr in TCL be more trouble than it's worth? More elegant but not actually beneficial? No trouble to implement and potentially beneficial in the long term?

I'd be curious to know the TCL developers' opinion about merged /usr. I admire you guys and greatly value your opinions because they have proven to lead to the best result (Tiny Core Linux).

Offline mocore

  • Hero Member
  • *****
  • Posts: 647
  • ~.~
Re: would /usr merge be advantageous for TCL in any way?
« Reply #1 on: February 28, 2024, 04:38:39 PM »

Supposed advantages of this filesystem hierarchy are outlined here.
related (coincidentally i was just reading about this topic @ )
https://www.devuan.org/os/announce/excalibur-usrmerge-announce-2024-02-20.html
... i guess Debian adaptation would affect any future? dcore.

Offline GNUser

  • Wiki Author
  • Hero Member
  • *****
  • Posts: 1525
Re: would /usr merge be advantageous for TCL in any way?
« Reply #2 on: February 28, 2024, 11:32:15 PM »
FYI - I remastered TCL15's corepure64.gz with merged /usr as an experiment. Steps were completely naive:
1. Put all of /bin contents into /usr/bin. Then repeat for /sbin and /lib
2. Delete the now-empty /bin, /sbin, and /lib directories
3. In terminal:
Code: [Select]
# for i in bin sbin lib; do ln -s /usr/$i /$i; done

I'm happy to report that a remaster created in this way 100% Just Works.

Not that I'd use such a TCL mod as daily driver, of course--only vanilla TCL is acceptable to me. I just wanted you guys to know that if it would be advantageous for the TCL project to jump on this merged /usr bandwagon at some point in the future, it would be a trivial change with no breakage as far as I can tell.

Offline patrikg

  • Wiki Author
  • Hero Member
  • *****
  • Posts: 718
Re: would /usr merge be advantageous for TCL in any way?
« Reply #3 on: February 29, 2024, 02:38:05 AM »
Funny facts about this issue you can see this part of video with Rob Landley explain the funny way why!!

https://youtu.be/Sk9TatW9ino?t=4768

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 11048
Re: would /usr merge be advantageous for TCL in any way?
« Reply #4 on: February 29, 2024, 02:52:49 AM »
My opinion is that it doesn't matter either way for TC. No advantages and no downsides, and as you found, symlinking just works.
The only barriers that can stop you are the ones you create yourself.

Offline gadget42

  • Hero Member
  • *****
  • Posts: 806
Re: would /usr merge be advantageous for TCL in any way?
« Reply #5 on: February 29, 2024, 03:12:59 AM »
i would like to see all the previously written documentation/textbooks/tutorials/etc stay as accurate and relevant as possible for as long as possible
(and in my honest humble dinasour opinion the systemd/windowsification crowd believes it cannot sever these links fast enough to suit whatever change-agents they serve)
The fluctuation theorem has long been known for a sudden switch of the Hamiltonian of a classical system Z54 . For a quantum system with a Hamiltonian changing from... https://forum.tinycorelinux.net/index.php/topic,25972.msg166580.html#msg166580

Offline patrikg

  • Wiki Author
  • Hero Member
  • *****
  • Posts: 718
Re: would /usr merge be advantageous for TCL in any way?
« Reply #6 on: February 29, 2024, 03:41:20 AM »
I like this idea a lot, you can then remove some search path's, in the PATH.

To throw some wood on the fire, so how do we approach the /opt directory.
Maybe we should also talk a little about it too.
« Last Edit: February 29, 2024, 03:44:55 AM by patrikg »

Offline polikuo

  • Hero Member
  • *****
  • Posts: 744
Re: would /usr merge be advantageous for TCL in any way?
« Reply #7 on: February 29, 2024, 04:03:11 AM »
This idea is new to me and I like it.
I write awk script a lot, it annoys me that the paths across distros are not consistent.
Just a quick example to show you all.

Normally, you'd think finding the path with env would be simple enough
Code: [Select]
#/usr/bin/env awk
However, the proper way to invoke an awk script is actually (note the '-f' flag)
Code: [Select]
#/usr/bin/awk -f
If you think appending that flag to the first method would do, you're wrong.
(This won't work)
Code: [Select]
#/usr/bin/env awk -f
The shebang of a linux script is always treated as literal.
Which means, the system will look for an executable called 'awk -f'
Obviously, it won't find anything, the script won't run.

I believe this is the scenario what they are trying to fix.
By putting everything in the same place so nobody has to fix file path again and again.
Come to think of it, it annoys me whenever the downloaded python modules are yelling for file path.
Perhaps they are after this one.

Offline GNUser

  • Wiki Author
  • Hero Member
  • *****
  • Posts: 1525
Re: would /usr merge be advantageous for TCL in any way?
« Reply #8 on: February 29, 2024, 05:40:25 AM »
(This won't work)
Code: [Select]
#/usr/bin/env awk -f
Hi polikuo. I've run into that problem before and it's a pain in the neck.

Dealing with the problem of /usr/bin/foo vs. /bin/foo in hardcoded paths is annoying because the purpose of the distinction is unclear at best. So the main selling point for me is that by merging and providing symlinks at filesystem root for compatibility, we eliminate needless complexity and never have to deal with a broken hardcoded path because of this distinction again because either path works!

Dealing with broken hardcoded paths because of applications that are unaware of the TCL convention of using local for extension-derived executables and libraries is a different story. Here the distinction serves a clear purpose for us.

My opinion is that it doesn't matter either way for TC. No advantages and no downsides, and as you found, symlinking just works.
Hi curaga. Thank you for sharing your thoughts on this. If it's "no advantages and no downsides" from a technical perspective but a small cosmetic advantage (leaner root filesystem) and a small practical advantage for users (fewer broken hardcoded paths), would you consider /usr merge for TCL16?

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 11048
Re: would /usr merge be advantageous for TCL in any way?
« Reply #9 on: February 29, 2024, 09:24:30 AM »
Yes, fine for TC16.
The only barriers that can stop you are the ones you create yourself.

Offline GNUser

  • Wiki Author
  • Hero Member
  • *****
  • Posts: 1525
Re: would /usr merge be advantageous for TCL in any way?
« Reply #10 on: February 29, 2024, 10:03:07 AM »
Well, that's exciting! Thank you. I do think it is a slightly less complex setup, which suits TCL well :)

Offline polikuo

  • Hero Member
  • *****
  • Posts: 744
Re: would /usr merge be advantageous for TCL in any way?
« Reply #11 on: February 29, 2024, 10:21:13 PM »
FYI - I remastered TCL15's corepure64.gz with merged /usr as an experiment.
My opinion is that it doesn't matter either way for TC. No advantages and no downsides, and as you found, symlinking just works.

Just sharing some thoughts, my ideas keep sparking.

It can actually be beneficial for our extensions.

When making extensions for scripting languages such as bash, perl, python, php ...etc,
it's quite often that we have to make symbolic links manually. (usually via startup script)

Code: [Select]
ln -s /usr/local/bin/bash /bin/bash
When doing that again and again across all the architectures, it's inevitable for the maintainers to leave things out when ones get tired. (such as permissions or typos regarding to the startup script)

If we create symbolic links in INITRD instead
Code: [Select]
cd ROOT
mkdir -p usr/bin
for i in bin sbin lib; do ln -s /usr/$i $i; done
ln -fs /usr/local/bin/bash usr/bin/bash

It relieves the pain and prevents unintended omissions.

Offline GNUser

  • Wiki Author
  • Hero Member
  • *****
  • Posts: 1525
Re: would /usr merge be advantageous for TCL in any way?
« Reply #12 on: March 02, 2024, 10:07:03 PM »
Hi curaga. Another thing to consider for TCL16 is "sbin merge". The Gentoo script that does "usr merge" does "sbin merge" at the same time. FWIW Arch adopted both merges in 2013.

I tested "usr merge" + "sbin merge" on TCL15 x86_64. It is trouble-free, as expected. I love the beautiful simplicity of the end result: No need to guess if an executable is in /bin, /sbin, /usr/bin, or /usr/sbin because they all live together in /usr/bin :) The gain in cross-distro compatibility (due to support for any and all hardcoded paths) is just an added bonus.
« Last Edit: March 02, 2024, 10:16:44 PM by GNUser »

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 11048
Re: would /usr merge be advantageous for TCL in any way?
« Reply #13 on: March 03, 2024, 01:54:16 AM »
sbin still has a purpose, root-requiring stuff, so not sure on that one.
The only barriers that can stop you are the ones you create yourself.

Offline GNUser

  • Wiki Author
  • Hero Member
  • *****
  • Posts: 1525
Re: would /usr merge be advantageous for TCL in any way?
« Reply #14 on: March 03, 2024, 06:41:03 AM »
Yes, at least sbin has a purpose. Debian/Devuan did not do sbin merge (i.e., kept /usr/sbin as a real directory).