SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Does this work on Slackware? I'm seeing a lot of pacman commands in the script.
Personally, if this does work on Slackware, I believe it would be a better fit on SBo as Pat is pretty good about ensuring the proper packages are updated when a dependency is updated.
I delete cause i see is specific archlinux tool , sounds interesting but probably not work for us.
Honestly, I think that the situation would be even worst in future regarding this, because today all the major distributions uses since long time an "unified layout" where the /bin, /sbin, /lib{,64} are just symlinks to the /usr counterparts, then the developers usually makes their programs with (and within) this particular layout.
I believe that we will be lucky if Slackware 16.0 would not adopt this layout too, for compatibility with the bigger distros.
I for one, for the systems where I have the /usr in a separate squashfs file (to minimize to space occupied by Slackware), I use a custom "mkinitrd" package, which I keep in sync with the official one, BUT which ships a modified /init script, which does the mounting of /usr near of its final stage.
This solution I strongly suggest also for you, because is the most convenient and consistent way, until Slackware would make really customizable its initrd - with plugins or ability to run custom scripts. Or, even better, just stop using a separate /usr at all, if you can.
Because I seriously doubt that Slackware will ever do (again) a consistent /usr split in the future. After all, is too much work for so less gain.
The trend of /usr merge in GNU/Linux distributions seemed to be started by Fedora in 2012, and then, we can see that many well-known and popular distributions, including Debian and Arch Linux, have made the move. It was similar to the wide adoption of systemd in GNU/Linux distributions, both of which were started by Red Hat’s desire to shape all modern Linux-based systems at their discretion and Lennart Poettering’s support, then made their debut in Fedora, and finally accepted by other distributions.
Gentoo, being one of the few distributions that still do not use systemd as the default init system, is also absent from the group of distributions that have completed the /usr merge. By default, in the root file system of a Gentoo installation, /bin, /lib, /lib64 and /sbin are still standalone directories instead of symbolic links. But judging from a split-usr global Portage USE flag, there might have already been plans to merge /usr in Gentoo. As of the current revision of this post was published, the USE flag was forcibly declared, to indicate that /bin, /lib, /lib64 and /sbin were still split from /usr; in the future, the USE flag might become optional when Gentoo is fully ready for the /usr merge.
f... Poettering..
Quote:
Merging /usr and / was always a bubble-headed scheme, and as much as I admire Sun Microsystems and its history I really don't care if Sun started this insanity. Most important installed suns are expensive enough and critical enough that they have ample system backup resources which are utilized every day. The average linux system doesn't have that kind of capital investment, especially home and small business users.
Therefore, the default configuration should err on the side of safety and minimizing data loss by isolating the majority of filesystem writes by separating out those directories which have the most activity on their own filesystem, rather than unifying the entire filesystem and spreading the problem to the most valuable files (1. user data, followed by executable and directories required for system boot up and damage evaluation and repair (fsck, and dump and restore type programs, and in the event of storage hardware failure, mkfs, mkswap, and a few other useful programs like grep, etc, and of course all of the hardware and some virtual (like RAID) device drivers)
Userland applications tend to be upgraded and bug-fixed much more frequently than the "system essentials" that are traditionally in /bin and /sbin. Keeping that filesystem small and RARELY WRITTEN TO reduces the opportunity for corruption. I don't care much if things traditionally found in /usr gets corrupted, but I absolutely DO care if mount and fsck are on a filesystem that gets corrupted.
Even if you're using a single storage technology (Like a single 1 TB hard disk), it STILL makes more sense have /usr on a separate partition, for the simple reason of keeping the root partition as small with as few writes to it as possible.
As far as "having stuff mounted sooner"... most boot up configurations, as soon as the kernel is loaded, the / filesystem is fsck'ed and then mounted... followed by fsck and mount of each of the other filesystems in the fstab that are configured to mount at boot time, so "quicker availability" isn't an issue. Besides, 10 small filesystems, fsck'ed sequentially can be fsck'ed faster than a single filesystem, because the back and forth head movement of the read-write head are kept to narrower bands, thereby making head-seeks of shorter duration, followed by a slightly longer head-seek to the next partition, whereas filesystem covering the entirety of a single disk can be seeking from inner tracks to far outer tracks and back thousands of times.
The only real disadvantage of dividing up a single disk into multiple filesystems is if you have the majority of write activity on the first and last partitions, rather than on a series of partitions in the middle, and that when a disk does a head seek from a filesystem on one partition to that of another partition, it has to traverse more empty blocks than if it were all in a unified, single filesystem.
All in all, the advantages of a single filesystem are still outweighed by the advantages of dividing a single storage device into several filesystems. And from a reliability and data safety aspect, multiple filesystems, each on its own device, is the preferred (although most expensive) method. Back when parallel SCSI was still common, I used to buy used SCSI disks for cheap... one for /, one for /usr, one for /home, and the smallest (and usually oldest) for /tmp, /var/tmp, and /var/log. That device being typically the smallest, and most likely to fail, with files which are of relatively low value (programs don't store results in /tmp unless the user specifies as such... so /tmp and /var/tmp have disposable data, as they are "scratchpad" areas. And a single /tmp directory can be shared by multiple hosts via NFS. /var/tmp is for the tmp files that can't be on a shared /tmp.
Poettering is really trying to dumb-down Linux into MS-WINTENDO.
unified layout? a very bad idea, https://www.freedesktop.org/wiki/Sof...orTheUsrMerge/ i read this and i still think the same, why dont you use those bigger distros and be happy?
if all you want is compatibility with those bigger distros and want Slackware to be like them, isn t easier to use those distros? you have Fedora, Arch Linux, Debian to choose.
The only problem would be that if you go there no one will listen to you and your ego will suffer.
pd: i agree on mpv nice and very good player.
Buddy, you put too much effort by not realizing something: I do NOT advocate for the usage of unified layout on Slackware, because honestly I do NOT care about them. So, I will leave to the Linux distro maintainers the choice of it.
I for one, I'm convinced that I will adapt, even they will decide to have on the root filesystem just /boot , /linux and /users - believe or not, I participated at Linux conferences where was advocated layouts like this, so ideas like this exists.
In fact, what I advocate is for improving initrd, which is today as customizable as a wood log, in my humble opinion. And to leave the Slackware as it's today - struggling to make it to support natively /usr split by software setup, is like fighting with wind mils.
In other hand, I've never hidden that I am an Ubuntu and openSUSE user since longer time than of Slackware, even now I have over 12 years of slacking.
Did you know what's nice on using multiple distributions? It's like living on multiple countries, learning their particular "way of life" and making you harder to bite on the "state propaganda" from any of them.
Meanwhile, you act like ol'good Soviet Political Commissars: our way or the highway. Seriously?
You really believe that everybody should be regimented on your True Way and to march singing Slava Unixyi or to go away?
Sorry, but I for one, I just use the operating systems and the software I like, and I do NOT care about those "true ways" on software.
Quote:
Originally Posted by adcdam
if all you want is compatibility with those bigger distros and want Slackware to be like them, isn t easier to use those distros? you have Fedora, Arch Linux, Debian to choose.
Who told you that "all I want is compatibility with those bigger distros" ?
Honestly, I do not care if Slackware is compatible (or not) with the other Linux distributions. I have no money in Slackware, buddy!
BUT, I am NOT stupid enough to not understand that without the compatibility, the software designed for "Linux distributions" would work badly or will not work at all in Slackware.
That's WHY the Slackware will change too, if wants to remain a functional platform, no matter of my opinion and no matter how many radical activists like you will roll in the floor.
BTW, why did you invite me so badly to use another distros? You are afraid of me? You will not perceive me as a danger for your True Way, unless what I say is right and you are afraid that the people will realize that in fact all your saga is just, well... saga.
Quote:
Originally Posted by adcdam
pd: i agree on mpv nice and very good player.
I know, I know and I'm not even surprised. Everybody loves MPV, right?
Last edited by LuckyCyborg; 02-26-2022 at 04:17 AM.
* Noteworthy changes in release 1.21.3 (2022-02-26)
** Fix computation of total bytes downloaded during FTP trasnfers (#61277)
** Add option to select TLS 1.3 on the command line
** Fix HSTS build issues on some 64-bit big-endian systems
** Hide password during status report in --no-verbose
** Remove a sprurious print statement that showed up even during --quiet
** Some more cleanups and bug-fixes
Is there any support / interest from the Slackware community to move the i3 window manager from SBo to /xap in a future release? (15.1, 15.5, 16.0,...)
Is there any support / interest from the Slackware community to move the i3 window manager from SBo to /xap in a future release? (15.1, 15.5, 16.0,...)
I use it so would like that. Quite. In fact I use i3-gaps...
And it's not so hard to compile it with dependencies and addons (what bar if one ? ).
And what about sway ?
All in all I think it's not going to happen soon...
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
