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.
Yes exactly. As awesome as AlienBob is (and he is truly awesome) he does not directly represent Slackware.
I'd like to thank AlienBob for providing the history as well.
If I'd known it would start this much of a flame-fest, I never would have brought it up.
However, I think you got your response as well. There:
Quote:
Originally Posted by Alien Bob
The "design" of 64bit Slackware was the result of a discussion between me and Pat and to some extent, the rest of the team. I wanted multilib out of the box, Pat wanted pure 64bit and we ended up in the middle where the 64bit Slackware is "multilib-ready" i.e. it is 64bit out of the box but a multilib sub-system is easily bolted on. Hence the "lib64" directories for instance.
I understand that Slackware64 is suppossed to be pure 64bit out of the box, as Patrick Volkerding wants, and "multilib-ready", with a multilib sub-system easy to bolt in, as Eric Hameleers wants.
And I hope now is clear for you why multilib exists in Eric Hameleers' repositories and it is a separate sub-system instead to be a part of Slackware64.
Well, at least these past few pages of drivel have resulted in no posts about PAM or systemd, so that brings a level of comfort.
Well, most of those who need PAM, Kerberos, systemd gave up on Slackware. Except for a few who maintain their own solutions and don't care about your level of comfort. Most likely those who really need 32-bit in Slackware64 will do the same. I think I'll reach my breaking point when the [removed] of bloat from ktown pours into Slackware and turns it into Alienware or Plasmaware or Bloatware or [removed]... So with no Linux users left your level of comfort will be high enough
BTW, if I remember well there was 64-bit Slackware (Slamd64, Bluewhite64) long before Slackware64-13.0
I think I'll reach my breaking point when the [removed] of bloat from ktown pours into Slackware and turns it into Alienware or Plasmaware or Bloatware or [removed]... So with no Linux users left your level of comfort will be high enough
Um, last I checked, AlienBob didn't write KDE5. Excuuuse him for volunteering his time to provide his own repo to allow Slackers to test the latest version of, you know, the only flagship DE that Slackware ships.
Jeez laweez.
I personally don't run KDE5 on Slackware as yet, but I've used it on Fedora, Kubuntu and Arch, and it's more polished than KDE4 at this point in so many ways. It is ready for prime time. If people don't like it, that's their prerogative. But KDE4 is EOL, and it can't stick around in Slackware forever. As the saying goes, don't come with a problem unless you have a solution.
Um, last I checked, AlienBob didn't write KDE5. Excuuuse him for volunteering his time to provide his own repo to allow Slackers to test the latest version of, you know, the only flagship DE that Slackware ships.
I think you're forgetting about Xfce, which is the one that I use.
The "design" of 64bit Slackware was the result of a discussion between me and Pat and to some extent, the rest of the team. I wanted multilib out of the box, Pat wanted pure 64bit and we ended up in the middle where the 64bit Slackware is "multilib-ready" i.e. it is 64bit out of the box but a multilib sub-system is easily bolted on. Hence the "lib64" directories for instance.
an other nice example story that a creator of something can not foresee and understand all use cases of his creation, and I mean in this case Pat as the creator of Slackware, not you as the creator of 64/multilib.
It is very unfortunate that I have to notice a little bit of stubbornness in insisting of the continuation on wrong idea, without taking the next possible change to fix it.
like the multilib decision, or an other one where a 'strong opinion' has been stated years ago to something I will not mention now, but some know what it is.
And all this even if the consequence is a massive drop of of users like we have seen it in the past and a devaluation of someones own creation.
I asked Mr. Hameleers for a statement about the requested merge of multilib in Slackware64.
I think my question is on-topic, considering the last several pages of this thread.
I think differently.
The statement has been made multiple times, that 64bit Slackware is created as pure 64bit from its inception, and that is not going to change. I am maintaining multilib add-on separately, nothing is going to change there either. Slackware has a 32-bit variant, nothing is going to change there either.
The two people who continuously derail this thread (being you, and Darth Vader) seem to have skulls so thick that no information is able to travel across. I pity you for that, but it should not degrade the quaility of this topic (requests for -current 14.2 --> 15.0).
Your posts continue to be off-topic. The request to add multilib was actually on-topic but by now it should be clear that that is not going to happen, period. Anything that follows is therefore off-topic. You could open a separate thread for the continued discussion of multilib, the future of 32bit OS-es and whatnot. It is a valid topic in itself and I assume many people will have opinions about it. This thread here, is however not the place to discuss it.
an other nice example story that a creator of something can not foresee and understand all use cases of his creation, and I mean in this case Pat as the creator of Slackware, not you as the creator of 64/multilib.
It is very unfortunate that I have to notice a little bit of stubbornness in insisting of the continuation on wrong idea, without taking the next possible change to fix it.
like the multilib decision, or an other one where a 'strong opinion' has been stated years ago to something I will not mention now, but some know what it is.
And all this even if the consequence is a massive drop of of users like we have seen it in the past and a devaluation of someones own creation.
Perhaps you are looking at this the wrong way.
Slackware is not meant to be a dogma. If it is created as pure 64bit, then no one prevents you from adding multilib, or to create a 32bit LXC container inside, or whatever.
Slackware provides a platform on which you can build. Slackware does not make assumptions about what its users are going to do with it. The 'pure 64bit' decision was a very good one. It gives you an expandable core. The worst you can have is a Slackware OS that is multilib by default and then having to decide some years into the future that "32bit is a dead end" and you have to strip the 32bit subsystem from the OS. That would be a real bummer.
I think you're forgetting about Xfce, which is the one that I use.
Point taken, but that was why I said "flagship" DE. I guess I have considered XFCE to be a lightweight/alternative DE as opposed to a flagship DE, but perhaps that has changed in recent years.
Agreed. Plasma5 is ready for prime time. AlienBob already has 5.12 LTS in ktown, and it works really well. It is time to push it to current IMHO. KDE4 and Qt4 are deprecated and EOL.
Agreed. Plasma5 is ready for prime time. AlienBob already has 5.12 LTS in ktown, and it works really well. It is time to push it to current IMHO. KDE4 and Qt4 are deprecated and EOL.
Did you want to provoke another flamewar?
I am not pro or against Plasma5, but apparently the flagship DE of Slackware is Xfce and we do not know yet even if Mr. Volkerding will not just choose to remove the "deprecated" KDE4 without providing any replacements. He done that with Gnome in the past, it is not excluded to happen again.
To stay on the thread topic, I would like to ask if is possible to ship in /testing packages for kernel 4.17.x for those who need more recent kernels for whatever reasons.
The DUSK's 4.17.4 packages works exceptionally well in my boxes.
It is about using a linker flag '--as-need', which tells to it to link in the produced binary only the libraries containing symbols actually used by the binary itself. This binary can be either a final executale or another library.
Apparently, this linker flag improve the memory comsuption and the speed, because are loaded in memory exactly the needed libraries.
It is about using a linker flag '--as-need', which tells to it to link in the produced binary only the libraries containing symbols actually used by the binary itself. This binary can be either a final executable or another library.
Apparently, this linker flag improve the memory comsuption and the speed, because are loaded in memory exactly the needed libraries.
Let's quote the linked to wiki page:
Quote:
No real tests on Fedora has been made ...
mass rebuild is desired after this change...
Nice idea, but maybe let first the Fedora guys essuyer les plâtres[1]
[1]Untranslatable, but in this context means "do the testing and debugging"
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
