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.
Why don't we actually rebuild _everything_ to just use /usr/lib?
And politely ask AlienBOB to use /usr/lib32/ for multilib.
I've been running multilib for, I guess, a decade now, and but recently I'm finding that the only 32 bit program I'm using is Wine. And even Wine is now implementing "native wow64", which should make it possible to run 32-bit Windows programs with pure 64bit Wine.
Why don't we actually rebuild _everything_ to just use /usr/lib?
And politely ask AlienBOB to use /usr/lib32/ for multilib.
I've been running multilib for, I guess, a decade now, and but recently I'm finding that the only 32 bit program I'm using is Wine. And even Wine is now implementing "native wow64", which should make it possible to run 32-bit Windows programs with pure 64bit Wine.
OK, since we're on this point we might as well go from the sublime to the ridiculous.
/lib, /usr/lib and /usr/local/lib should now be renamed as...
32bit systems should have only /lib32, /usr/lib32 and /usr/local/lib32
64bit systems should have only /lib64, /usr/lib64 and /usr/local/lib64
That was before we found a super easy solution to keep some sanity. Now we will have some x64 libs in /usr/lib and some in /usr/lib64, which is not consistent and it doesn't make any sense.
It's not even the case of arguing that python is architecture agnostic, because it's not: there are many x64 .so files inside python[version]/site-packages.
Not to mention that many people are having serious problems with this change.
I can imaging that Patrick is getting sick-n-tired of requests to "move this here or move that there"
and he might be getting close to following through with what he mentioned way back here.
IMO, the only 2 that really make sense are 'kde' & 'xfce'
For my own systems, all of 'xfce' is installed but only 5 programs
along with their required libs from 'kde'.
(ark, k3b, kate, kfind, ktorrent)
I did a test-install with all of 'kde' installed as-well and it took only an additional 3GB of disk space.
By today's standards... that ain't much at-all.
(Heck, I have individual MP4 video files that are 21GB)
I never considered categories to be about size, but rather about security, dependencies, and installation speed. I would like to be able to install only /a/ into a docker container, which I rebuild fairly often, so that 5 minutes mean something. And I didn't want to have X or a compiler on a server, for security reasons, so I skip x, xap, and kde.
l is ”something needed to run everything that is not in a".
Any chance we can get docker and docker-compose added to the official images? A lot of things come on this format lately, not only help avoiding OS duplicates and compatibility, but increasing security by abstracting applications from the underlying OS.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.