LinuxQuestions.org
View the Most Wanted LQ Wiki articles.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices



Reply
 
Search this Thread
Old 01-31-2012, 08:23 AM   #16
tronayne
Senior Member
 
Registered: Oct 2003
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,121

Rep: Reputation: 819Reputation: 819Reputation: 819Reputation: 819Reputation: 819Reputation: 819Reputation: 819

I'm one of those old-fashioned fuddy-duddy types that believes in separating "system" and "utility" binaries (and shell programs) in /bin and /usr/bin -- and /usr/local/bin too. Sort of the rule that system software (necessary to boot) gets put in /bin and /sbin on the root partition and everything else in the /usr tree, including /usr/sbin nowadays. I'm pretty sure that the "s" means "system binary," but that could be way off base. I have, literally for decades, kept the usr tree on a separate disk drive or on a separate disk partition and use a separate partition for "local" (so there's a partition or drive for /usr and an additional partition for /usr/local). One reason that got started was that user accounts used to go in /usr (long, long time ago in a galaxy far, far away before /home got created and I make /home a mounted partition too).

I try to keep the distribution directories pristine; i.e., when I add software -- from SlackBuilds or source from somewhere -- I build it to be installed in /usr/local. If for no other reason than to not overwrite something important if I or the developer had not paid attention to names.

Much of this is based on the Unix way; I learned on System 3 and learned a lot more on System V (and later Solaris) and just can't give up on the concepts. I still think it terms of 50M disk drives and software that does one thing and does it well. Drives me crazy that software developers seem to think that a behemoth that will scratch your nose and rub your feet and, oh, by the way, do word processing while it's at it (and not do any of that particularly well) is a goal worth reaching, the click-'n'-drool school does not especially appeal.

If it ain't broke don't mess with it.
 
1 members found this post helpful.
Old 01-31-2012, 11:16 AM   #17
gnashley
Amigo developer
 
Registered: Dec 2003
Location: Germany
Distribution: Slackware
Posts: 4,775

Rep: Reputation: 481Reputation: 481Reputation: 481Reputation: 481Reputation: 481
"click-'n'-drool" - I love it!!
 
Old 01-31-2012, 07:46 PM   #18
rkelsen
Senior Member
 
Registered: Sep 2004
Distribution: slackware
Posts: 1,808

Rep: Reputation: 234Reputation: 234Reputation: 234
Quote:
Originally Posted by saulgoode View Post
I am very much opposed to conflating the /usr subdirectories with their top-level counterparts.
+1
Quote:
Originally Posted by tronayne
I'm pretty sure that the "s" means "system binary," but that could be way off base.
This says you're right:

http://www.pathname.com/fhs/pub/fhs-2.3.html

As far as I'm aware, Slackware has always tried to follow the Filesystem Hierarchy Standard.

The reasons for the existence of all of the separate bin and sbin directories are clearly spelt out in that document. They are all sound reasons which ensure consistency, and should continue to be followed by all major Linux distributions, IMNSHO.

Last edited by rkelsen; 02-01-2012 at 12:53 AM.
 
1 members found this post helpful.
Old 01-31-2012, 09:27 PM   #19
saulgoode
Member
 
Registered: May 2007
Distribution: Slackware
Posts: 257

Rep: Reputation: 121Reputation: 121
Quote:
Originally Posted by T3slider View Post
saulgoode, the whole point is that your initrd will take the place of mandatory non-usr /bin etc. In a pinch, you can boot to /bin/sh using the initrd, which allows you to run busybox utilities (which should suffice for most pre-system maintenance tasks) and mount /usr if you need more.
A fair point, but then what are the ramifications of this approach from a maintenance standpoint? Wouldn't it mean that an update to any one of your system utilities requires a rebuilding of your initfs, thus losing direct package management of those utilities?

I am also wondering about switching to the "equivalent" of runlevel 1 (as opposed to rebooting to the initfs). Would it be accomplished by loop mounting the initfs and then pivot_root/chroot'ing to it? Or is there a simpler approach?
 
Old 01-31-2012, 09:47 PM   #20
T3slider
Senior Member
 
Registered: Jul 2007
Distribution: Slackware64-14.1
Posts: 2,298

Rep: Reputation: 722Reputation: 722Reputation: 722Reputation: 722Reputation: 722Reputation: 722Reputation: 722
Quote:
Originally Posted by saulgoode View Post
A fair point, but then what are the ramifications of this approach from a maintenance standpoint? Wouldn't it mean that an update to any one of your system utilities requires a rebuilding of your initfs, thus losing direct package management of those utilities?
Most initrds (Slackware's included) just use busybox, which is one single binary with a lot of functionality that acts differently depending on how it's called (ie. a symlink of /bin/ls to /bin/busybox will cause it to list output). There are enough functions in busybox to examine/mount/fix things. If you need more, you can always mount /usr and use those binaries. If you upgrade a system utility it will not affect busybox (which actually doesn't exist outside of the initrd on Slackware).
Quote:
Originally Posted by saulgoode View Post
I am also wondering about switching to the "equivalent" of runlevel 1 (as opposed to rebooting to the initfs). Would it be accomplished by loop mounting the initfs and then pivot_root/chroot'ing to it? Or is there a simpler approach?
The system enters runlevel 1 only after / is mounted read-write -- ie after the initrd hands power over to the installed system. init in the initrd just mounts / read-only, but it is remounted in rc.S. Booting to runlevel 1 would still boot to the real installed system, just as it does now.
 
Old 02-01-2012, 05:43 AM   #21
GazL
Senior Member
 
Registered: May 2008
Posts: 3,503

Rep: Reputation: 1026Reputation: 1026Reputation: 1026Reputation: 1026Reputation: 1026Reputation: 1026Reputation: 1026Reputation: 1026
Slackware's /bin isn't standalone clean anyway as the following shows (and this is an example of one of the justifications that they cite as a reason for the merge.

Code:
root@slack:~# cd /bin
root@slack:/bin# for file in `find . -type f` ; do   ldd $file | grep /usr/; done
        libntfs.so.10 => /usr/lib64/libntfs.so.10 (0x00007f85e988b000)
        libntfs.so.10 => /usr/lib64/libntfs.so.10 (0x00007fa34588d000)
        libntfs.so.10 => /usr/lib64/libntfs.so.10 (0x00007f24ab6ef000)
        libntfs.so.10 => /usr/lib64/libntfs.so.10 (0x00007f0cc1d9e000)
        libntfs.so.10 => /usr/lib64/libntfs.so.10 (0x00007f4308a17000)
        libreadline.so.5 => /usr/lib64/libreadline.so.5 (0x00007f3704c9f000)
        libgdbm.so.3 => /usr/lib64/libgdbm.so.3 (0x00007f7fb6eeb000)
        libntfs.so.10 => /usr/lib64/libntfs.so.10 (0x00007f9663a7a000)
        librpmbuild.so.1 => /usr/lib64/librpmbuild.so.1 (0x00007ffbc1e50000)
        librpm.so.1 => /usr/lib64/librpm.so.1 (0x00007ffbc1be3000)
        libmagic.so.1 => /usr/lib64/libmagic.so.1 (0x00007ffbc19c6000)
        librpmio.so.1 => /usr/lib64/librpmio.so.1 (0x00007ffbc17a2000)
        libsqlite3.so.0 => /usr/lib64/libsqlite3.so.0 (0x00007ffbc1517000)
        libnss3.so => /usr/lib64/seamonkey/libnss3.so (0x00007ffbc08cf000)
        libz.so.1 => /usr/lib64/libz.so.1 (0x00007ffbc04b0000)
        libnssutil3.so => /usr/lib64/seamonkey/libnssutil3.so (0x00007ffbbfac6000)
        libplc4.so => /usr/lib64/seamonkey/libplc4.so (0x00007ffbbf8c1000)
        libplds4.so => /usr/lib64/seamonkey/libplds4.so (0x00007ffbbf6be000)
        libnspr4.so => /usr/lib64/seamonkey/libnspr4.so (0x00007ffbbf480000)
 
Old 02-01-2012, 08:46 AM   #22
saulgoode
Member
 
Registered: May 2007
Distribution: Slackware
Posts: 257

Rep: Reputation: 121Reputation: 121
Quote:
Originally Posted by T3slider View Post
Most initrds (Slackware's included) just use busybox, ...
Perhaps you can educate me, but none of my Slackware installations use initrds.

I don't have anything against initrds, they just seem to be a work-around for not having a kernel with the appropriate driver for the root filesystem. I've always considered it preferable (KISS) to ensure the filesystem used by / is supported by the kernel.

Quote:
Originally Posted by T3slider View Post
The system enters runlevel 1 only after / is mounted read-write -- ie after the initrd hands power over to the installed system. init in the initrd just mounts / read-only, but it is remounted in rc.S. Booting to runlevel 1 would still boot to the real installed system, just as it does now.
But if I wish to modify my /usr configuration and all of the utilities that let me do so are on /usr, then I've got a problem. Not an insurmountable problem, but it does make Mr Poettering's proposal less favorable to me.

Quote:
Originally Posted by GazL View Post
Slackware's /bin isn't standalone clean anyway as the following shows (and this is an example of one of the justifications that they cite as a reason for the merge.
I would submit that the problem exhibited in those examples is either that the utility program does not belong in /bin, or that its dependencies do not belong in /usr. I understand that symlinking to /usr directories works around this problem, but it seems to me a rather kludgy approach.

If the idea were to eliminate /usr and move all of its subdirectories to / -- or to eliminate the top level directories and rely on their counterparts in /usr -- then that would at least represent a simplification of things (to offset the disadvantages). Merely symlinking such that the top level directories still exist is to my mind little more than obfuscation.

Last edited by saulgoode; 02-01-2012 at 08:49 AM.
 
Old 02-01-2012, 09:25 AM   #23
GazL
Senior Member
 
Registered: May 2008
Posts: 3,503

Rep: Reputation: 1026Reputation: 1026Reputation: 1026Reputation: 1026Reputation: 1026Reputation: 1026Reputation: 1026Reputation: 1026
Quote:
Originally Posted by saulgoode View Post
I would submit that the problem exhibited in those examples is either that the utility program does not belong in /bin, or that its dependencies do not belong in /usr. I understand that symlinking to /usr directories works around this problem, but it seems to me a rather kludgy approach.
I agree. These errors are easily corrected without having to merge /bin into /usr/bin, but the point that the proponents of this change are making is that these errors do occur and they couldn't if there was only a single location.

The symlinks are only intended to provide backward compatibility, the idea is not to need them at all, so if that is a kludge then it's no more a kludge than any of the other symlinks that slackware already includes because other standard locations for things have changed over time.


The way I look at it is this: If you were starting with a clean slate, why would you want to put a few odds and ends in /bin and /lib when you could just have a single location for system related stuff under /usr and not have to worry about trying to figure out where to place things? So far I've not come up wit a good reason.

Whether it is worth the trouble of retrofitting to an existing system is a different question.
 
Old 02-01-2012, 10:07 AM   #24
Cedrik
Senior Member
 
Registered: Jul 2004
Distribution: Slackware
Posts: 2,140

Rep: Reputation: 242Reputation: 242Reputation: 242
I think problems can start from merging /lib and /usr/lib

That means rebuild great number of packages and rethink lib organization, no ?
For example, in my system:
Code:
ls -l /usr/lib/modules
/usr/lib/modules -> xorg/modules

ls /lib/modules
2.6.37.6  2.6.37.6-smp  3.0.4
 
1 members found this post helpful.
Old 02-01-2012, 11:01 AM   #25
GazL
Senior Member
 
Registered: May 2008
Posts: 3,503

Rep: Reputation: 1026Reputation: 1026Reputation: 1026Reputation: 1026Reputation: 1026Reputation: 1026Reputation: 1026Reputation: 1026
Yes, that's an interesting one. I wonder whether fedora has those in the same place as slackware. I wouldn't be surprised if that modules link is historical and no longer used though.

Last edited by GazL; 02-01-2012 at 11:07 AM.
 
Old 02-01-2012, 06:59 PM   #26
T3slider
Senior Member
 
Registered: Jul 2007
Distribution: Slackware64-14.1
Posts: 2,298

Rep: Reputation: 722Reputation: 722Reputation: 722Reputation: 722Reputation: 722Reputation: 722Reputation: 722
Quote:
Originally Posted by saulgoode View Post
Perhaps you can educate me, but none of my Slackware installations use initrds.
I don't have anything against initrds, they just seem to be a work-around for not having a kernel with the appropriate driver for the root filesystem. I've always considered it preferable (KISS) to ensure the filesystem used by / is supported by the kernel.
Yes, I agree with that (which is why I stated their claim about the feasibility of booting without an initrd was at least false on Slackware). It's a valid point, but irrelevant to *me* since I use LUKS encryption anyway (and therefore need an initrd regardless of what I do with the kernel). Most Slackers who don't compile their own kernel are probably used to an initrd with the generic kernels already, but merging /usr would make initrds a requirement (whereas they are merely a suggestion when using default kernels presently).
 
Old 02-01-2012, 07:20 PM   #27
GazL
Senior Member
 
Registered: May 2008
Posts: 3,503

Rep: Reputation: 1026Reputation: 1026Reputation: 1026Reputation: 1026Reputation: 1026Reputation: 1026Reputation: 1026Reputation: 1026
Quote:
Originally Posted by T3slider View Post
but merging /usr would make initrds a requirement
Only if you want to keep it as a separate filesystem. Merging /usr would have no impact on the need for an initrd if /usr is left in the rootfs, and as that is a limitation/requirement of systemd anyway its clearly what the Fedora guys who proposed this are thinking about.

IMO merging /bin into /usr/bin only makes sense if /usr is left as part of the rootfs anyway.
 
Old 02-02-2012, 02:54 AM   #28
wildwizard
Member
 
Registered: Apr 2009
Location: Oz
Distribution: slackware64-14.0
Posts: 755

Rep: Reputation: 227Reputation: 227Reputation: 227
Quote:
Compatibility: The Longer Version

A unified filesystem layout (as it results from the /usr merge) is more compatible with UNIX than Linux’ traditional split of /bin vs. /usr/bin. Unixes differ in where individual tools are installed, their locations in many cases are not defined at all and differ in the various Linux distributions. The /usr merge removes this difference in its entirety, and provides full compatibility with the locations of tools of any Unix via the symlink from /bin to /usr/bin.
In Linux we have a set layout for where tools should be installed perhaps the author of this has heard of it?

The specifications can found here
http://www.pathname.com/fhs/

Quote:
Example

/usr/bin/foo may be called by other tools either via /usr/bin/foo or /bin/foo, both paths become fully equivalent through the /usr merge. The operating system ends up executing exactly the same file, simply because the symlink /bin just redirects the invocation to /usr/bin.
Who or what is calling tools via a hard coded path, if it is OSS then fix the code to not do that if it is proprietary code than include compatibility links with it when packaging it and tell the devs to fix it.

Hard coded paths should not be used that is what a search path is for.

Quote:
The historical justification for a /bin, /sbin and /lib separate from /usr no longer applies today. (More on the historical justification for the split, by Rob Landley) They were split off to have selected tools on a faster hard disk (which was small, because it was more expensive) and to contain all the tools necessary to mount the slower /usr partition. Today, a separate /usr partition already must be mounted by the initramfs during early boot, thus making the justification for a split-off moot. In addition a lot of tools in /bin and /sbin in the status quo already lost the ability to run without a pre-mounted /usr. There is no valid reason anymore to have the operating system spread over multiple hierarchies, it lost its purpose.
If anything can be taken from this paragraph it is this little nugget, some tools have been allowed to be developed that are critical for the system but are using data from outside /. Fixing this is not done by lumping everything in the same place it is fixed by fixing the utilities that have been allowed to place data outside of the areas listed in the FHS.

Quote:
Solaris implemented the core part of the /usr merge 15 years ago already, and completed it with the introduction of Solaris 11. Solaris has /bin and /sbin only as symlinks in the root file system, the same way as you will have after the /usr merge: Transitioning From Oracle Solaris 10 to Oracle Solaris 11 - User Environment Feature Changes.
Solaris != Linux

Or did I miss a memo?

Quote:
Not implementing the /usr merge in your distribution will isolate it from upstream development. It will make porting of packages needlessly difficult, because packagers need to split up installed files into multiple directories and hard code different locations for tools; both will cause unnecessary incompatibilities. Several Linux distributions are agreeing with the benefits of the /usr merge and are already in the process to implement the /usr merge. This means that upstream projects will adapt quickly to the change, those making portability to your distribution harder.
Again we are talking about how hard it is but with reference to hard coded paths, stop hard coding paths and use the system the way it was intended to be used.

Splitting of directories is given as a complaint with project development but your still going to have split directories or are we going to lump everything into the same directory? (bin lib and docs)

Overall this current trend of development make me think of this famous saying :-
Those who don't understand UNIX are condemned to reinvent it, poorly.
 
Old 02-02-2012, 03:25 AM   #29
wildwizard
Member
 
Registered: Apr 2009
Location: Oz
Distribution: slackware64-14.0
Posts: 755

Rep: Reputation: 227Reputation: 227Reputation: 227
Quote:
Originally Posted by GazL View Post
Slackware's /bin isn't standalone clean anyway as the following shows (and this is an example of one of the justifications that they cite as a reason for the merge.

Code:
root@slack:~# cd /bin
root@slack:/bin# for file in `find . -type f` ; do   ldd $file | grep /usr/; done
        libntfs.so.10 => /usr/lib64/libntfs.so.10 (0x00007f85e988b000)
        libntfs.so.10 => /usr/lib64/libntfs.so.10 (0x00007fa34588d000)
        libntfs.so.10 => /usr/lib64/libntfs.so.10 (0x00007f24ab6ef000)
        libntfs.so.10 => /usr/lib64/libntfs.so.10 (0x00007f0cc1d9e000)
        libntfs.so.10 => /usr/lib64/libntfs.so.10 (0x00007f4308a17000)
        libntfs.so.10 => /usr/lib64/libntfs.so.10 (0x00007f9663a7a000)
ntfs progs - could be fixed by moving the lib out of /usr

Quote:
Code:
        libreadline.so.5 => /usr/lib64/libreadline.so.5 (0x00007f3704c9f000)
ftp - does ftp really need to be /bin ? or maybe readline is in the wrong place?

Quote:
Code:
        libgdbm.so.3 => /usr/lib64/libgdbm.so.3 (0x00007f7fb6eeb000)
zsh? does it really need this?

Quote:
Code:
        librpmbuild.so.1 => /usr/lib64/librpmbuild.so.1 (0x00007ffbc1e50000)
        librpm.so.1 => /usr/lib64/librpm.so.1 (0x00007ffbc1be3000)
        libmagic.so.1 => /usr/lib64/libmagic.so.1 (0x00007ffbc19c6000)
        librpmio.so.1 => /usr/lib64/librpmio.so.1 (0x00007ffbc17a2000)
        libsqlite3.so.0 => /usr/lib64/libsqlite3.so.0 (0x00007ffbc1517000)
        libnss3.so => /usr/lib64/seamonkey/libnss3.so (0x00007ffbc08cf000)
        libz.so.1 => /usr/lib64/libz.so.1 (0x00007ffbc04b0000)
        libnssutil3.so => /usr/lib64/seamonkey/libnssutil3.so (0x00007ffbbfac6000)
        libplc4.so => /usr/lib64/seamonkey/libplc4.so (0x00007ffbbf8c1000)
        libplds4.so => /usr/lib64/seamonkey/libplds4.so (0x00007ffbbf6be000)
        libnspr4.so => /usr/lib64/seamonkey/libnspr4.so (0x00007ffbbf480000)
rpm - nuff said

So 4 actual problems that if we look at the actual problems we could fix them properly and be done with it.

1. Move libntfs to /lib as it should be there not /usr/lib
2. Move either ftp or readline (checking other things out (/sbin?) might reveal readline is more critical than we think)
3. Check the compile options on zsh first and then make the decision on moving libgdbm
4. RPM is only there as a compatibility tool and is not a Slackware critical component we could move it or ignore the links to /usr, as far as we are concerned we don't actually need it to work on the system
 
Old 02-02-2012, 05:35 AM   #30
fgcl2k
Member
 
Registered: Jan 2011
Distribution: Slackware 14.1
Posts: 108

Rep: Reputation: 29
Quote:
Not implementing the /usr merge in your distribution will isolate it from upstream development. It will make porting of packages needlessly difficult, because packagers need to split up installed files into multiple directories and hard code different locations for tools; both will cause unnecessary incompatibilities. Several Linux distributions are agreeing with the benefits of the /usr merge and are already in the process to implement the /usr merge. This means that upstream projects will adapt quickly to the change, those making portability to your distribution harder.
When I started using UNIX (and later Linux) many years ago the attitude of the developers towards portability was very different; the tools were primitive (mostly comments in Makefiles and #ifdefs in programs, no autotools) but the developers wanted their programs to run on all possible platforms; I think that the autotools were born from this type of reasoning. Now there is a trend amongst the new generation of developers; your system must adapt to my programs otherwise you'll be left behind. So, for example, support from the BSD's is dropped, next support for distributions that have a different filesystem layout or use different tools. This is exactly the "all the world is like me" mindset for which Linux users criticized Windows (have you ever seen a portable Windows program?)
Let's hope all this will be stopped in Linux before it is too late, or is it already? And, by the way, who gives all this power to these developers?
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
echo $PATH = /home/g3rc4n/bin:/usr/local/bin:/usr/bin:/bin:/usr/games ? i_heart_pandas Linux - Software 7 09-18-2009 09:33 AM
Location of libraries in /usr/lib/ or /usr/lib64/ in Slackware64 niels.horn Slackware 2 06-24-2009 05:25 AM
/usr/bin/ld: skipping incompatible /usr/lib/libXpm.so when searching for -lXpm sqn Linux - Server 2 05-12-2009 04:53 AM
FreeBSD 6.2, no /usr/src/tools and /usr/src/usr.bin, failed to build world. Mr_Shameless *BSD 4 05-16-2008 09:43 AM
making files available in /usr/local/bin and /usr/sbin reakinator Linux - Newbie 1 10-14-2006 06:09 PM


All times are GMT -5. The time now is 12:31 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration