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.
A couple of years ago, I posted a new thread regarding LILO, and why it still is the best option for me and apparently, quite a few others as well. In my opinion, concerning LILO being a supposedly abandoned project, 3 things stand out:
There are no outstanding bugs to be quashed;
There are no features to be added; and
It continues to work as well as it always has.
My system is of the older variety (read: UEFI with CSM) and it continues to work with LILO. I like LILO because it is simple to work with, and does the job I ask of it with aplomb. I abide by the old saying:
And bang goes my printer! Its driver won't work without 32-bit glibc.
Well, there's saying: the desperate times justify desperate measures.
I for one, I would use a network or wifi print server made from a small PC or even a mini-PC - there are also x86 variants, to which will be connected that particular printer with 32bit only software.
You may choose also a LXC container running a minimalist 32bit Slackware of a previous version, and exposed locally as a network print server.
There are ways to fix this issue, if the Slackware 32bit and multilib are no more available...
BTW, I never used multilib in Slackware, and I never missed it. I have either 32bit or 64bit systems.
Last edited by LuckyCyborg; 07-01-2020 at 10:36 AM.
I agree, but learning from mistakes with newer or more popular things is more valuable than learning from mistakes with obsolete or ugly garbage which can be easily replaced with something newer and/or better.
I don't care a whit whether something is popular or not. In fact I see popularity as common denominator junk more often than not. As for newer, that's a crap shoot. Things aren't automatically better because they are newer... or because they are older for that matter. Things are good because they do a job well. Ugly is entirely subjective, and really, so is "better". Better just really means "different". We each must decide if those differences are useful to us individually.
I don't care a whit whether something is popular or not. In fact I see popularity as common denominator junk more often than not. As for newer, that's a crap shoot. Things aren't automatically better because they are newer... or because they are older for that matter. Things are good because they do a job well. Ugly is entirely subjective, and really, so is "better". Better just really means "different". We each must decide if those differences are useful to us individually.
Speaking of which, I was a little bemused when I pulled my Casio solar pocket calculator out of a cardboard box and found it still working (just). That's a 35 year old calculator. With the original silver oxide battery. The battery had barely even leaked. And yet my wife's Nexus 5X went into a bootloop after 3 years and despite our attempts to revive it including sticking it in the freezer for a few days we still had to bin it.
I have two AMD Phenom systems that I'm somewhat reluctant to update even though one of them is my media center and struggling to play x265, because I know whatever I get is likely to give me all kinds of problems. It's not about money. I've got plenty to spend on new kit, I'm just reluctant because there is so much junk around.
Multilib is not officially supported. A lot of useful things are somewhere else, so 32bit support could be there too.
32bit support wouldn't be a side project. It would be a full blown (and most likely unofficial) port (even if it is continuing where Pat left off).
Quote:
Originally Posted by I.G.O.R
Short story how I switched to -current. I bought new laptop almost 2 years ago (not today or yesterday, not even a year ago). Kernel of 14.2 version brought me a lot of troubles with recognizing hardware, so I built newer kernel and replaced the old one (from patches).
So, after "buying a tank", I had to replace its turret immediately. If this is stability, I don't know what instability is.
You bought a computer 2 years after 14.2 came out and expected it to be fully supported? Stable releases means that the system doesn't break with updates, not that it will work on the latest and greatest hardware. That has nothing
Quote:
Originally Posted by I.G.O.R
Absolutely! There are a lot of things to add indeed. But they will say go to SBo.
Slackware development is handled by one man (with helpful input from a few on his dev team). Pat can't feasibly support everything that everyone wants in Slackware. Why is it bad to have packages in SBo rather than add extra burden on Pat?
Quote:
Originally Posted by I.G.O.R
May be because lilo project is itself abandoned?
Quote:
Originally Posted by I.G.O.R
And? It's abandoned.
Some people will say it's not abandoned, it's just perfect and there is no need to improve perfect things.
It is abandoned by the previous developer, but Pat has been pushing updates as needed... you can see the Slackware ChangeLog for details.
Code:
+--------------------------+
Mon May 18 19:17:21 UTC 2020
a/lilo-24.2-x86_64-9.txz: Rebuilt.
Enable the "compact" option by default.
liloconfig: correctly set the root partition.
+--------------------------+
Thu Mar 1 23:24:54 UTC 2018
a/lilo-24.2-x86_64-7.txz: Rebuilt.
liloconfig: prevent extraneous Windows partitions from being added
to lilo.conf. Thanks to allend.
liloconfig: display a notice when the script is scanning for partitions
(which may take some time) so that it doesn't appear to be stalled.
+--------------------------+
Mon Feb 26 21:32:03 UTC 2018
a/lilo-24.2-x86_64-6.txz: Rebuilt.
Support NVMe devices. Thanks to timsoft.
+--------------------------+
Sun Jul 9 20:38:08 UTC 2017
a/lilo-24.2-x86_64-5.txz: Rebuilt.
liloconfig: support /dev/vda in QEMU. Thanks to Robby Workman.
+--------------------------+
Thu Mar 23 21:38:23 UTC 2017
a/lilo-24.2-x86_64-4.txz: Rebuilt.
Issue a warning rather than a fatal error for colons in /dev/disk/by-id/
device names. Thanks to alex14641 on LQ.
+--------------------------+
Tue Jul 12 03:48:34 UTC 2016
a/lilo-24.2-x86_64-3.txz: Rebuilt.
In liloconfig: Skip the menu asking if the user wants a UTF-8 virtual
console, and use the kernel default (currently this is UTF-8 active).
Quote:
Originally Posted by I.G.O.R
I also don't like grub and I use syslinux instead. And here is the strange thing. Slackware provides grub, lilo and syslinux, but installer gives you two options: lilo or skip and do it yourself (like this slur "GoToSBo").
What's wrong with having a default bootloader? The others are installed and available if people want to use them, it's just not supported in the installer (which also doesn't support adding users *gasp*). And if you boot using EFI, the installer will prompt you to skip lilo and use elilo.
Quote:
Originally Posted by I.G.O.R
Yes, it's really funny. However, there is one thing which is not funny at all. Emacs and TCL are still in seperate groups. In 2020. It's just unbelievable.
The groups are meaningless. Pat doesn't take much thought in where packages will go.
Quote:
Originally Posted by volkerdi
Arguing about which series any particular package belongs in is even more pointless than having separate package series in the first place. Really, everything should just be dumped in one big package directory so that people don't get carried away with the idea that the divisions actually mean something.
Quote:
Originally Posted by I.G.O.R
Not literally copies for sure. It's enough to have a quick look at logic of package creation and especially source preparation stage in order to figure out that plenty of SlackBuild scripts are directly mapped from Arch's PKGBUILD scripts. School teachers would not believe in such coincidents.
WHAT?!? Do you realize that the same piece of software is likely to be compiled similarly between multiple distros? I'll be the first to admit that I've gone to AUR for some more difficult programs to see how my implementation compared to the one on there. Sometimes they have a PKGBUILD I can compare, and sometimes they don't have the package on there. There's nothing wrong with checking out what others did so you aren't reinventing the wheel. But ultimately, since the same program on multiple distros will use the same build system, how the program is built will be very similar no matter what distro you use. There are probably some difficult packages that maintainers have cross-referenced AUR, Gentoo's ebuild, or a few other sites that host methods for building packages. But the vast majority of scripts on SBo are simple enough that you don't need any reference beyond using SBo's template.
Quote:
Originally Posted by I.G.O.R
I didn't call it slur. I meant "Go to SBo" as universal answer on everything.
As said above, what's the other option? Make the Slackware installation image 30GB to hold everyone's desired packages? If there is a good reason to include something in the main distro and not on SBo, ask for it in the Requests for -current thread.
Quote:
Originally Posted by I.G.O.R
I heard PulseAudio had been on SBo for many years before 14.2. If I would be younger and tried Slackware 5 years ago, I would throw it away immediately after discovering that Slackware doesn't provide PulseAudio and people say me "go to SBo".
Did you know that Slackware doesn't contain systemd? Or jack? Or any other number of various programs? 14.1 and earlier worked perfectly fine without pulseaudio. When it became a hard dependency, Pat added it during the development of 14.2 and made it optional during the development of 15.0.
If you feel that Slackware not including pulseaudio until 14.2 was a reason to not use it, you may want to consider switching to another distro. It seems like the principles that Pat follows while developing future versions doesn't match to the ideals that you want in a distro.
I heard PulseAudio had been on SBo for many years before 14.2. If I would be younger and tried Slackware 5 years ago, I would throw it away immediately after discovering that Slackware doesn't provide PulseAudio and people say me "go to SBo".
We get it. You don't like Slackware.
Nothing anyone can say will change your mind, so please leave and please stop antagonising the people who do like it.
The point is: If I want to buy a new car, I expect to buy a good car, but not a tank able to resist at a nuclear bombing.
OT: As a former tanker, I am unaware of any tanks capable of resisting a nuclear bombing unless said bombing is relatively distant; I'll admit that for other than neutron bombs, you'd be better off in a tank than a car at any given distance (although "better off" may mean that you got a few more microseconds of life). Depending upon said nuclear bomb, you may well be worst off being in a tank when the nuke goes off (neutron bombs were more deadly to people in metal boxes than people in underground shelters, after all).
Some tanks are better at operating in a contaminated environment (nuclear, chemical, or biological) than others.
This could rapidly become political, so if anyone answers in a way that will lead us down that particular rat hole, I'll willingly throw up my hands and surrender.
That hopelessly obsolete, abandoned lilo just worked. Amazing.
Yes. LILO does the job for me on all of my Slackware64-current desktops and laptops. Many thanks to Mr. Volkerding and the Slackware Team of developers.
Code:
bash-5.0$ uname -a
Linux thor.darkstar.home 5.4.50 #1 SMP Wed Jul 1 13:27:59 CDT 2020 x86_64 Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz GenuineIntel GNU/Linux
I've always been a great fan of LILO and I don't like GRUB. I can just about tolerate it in its LFS form (no scripts, just a handwritten grub.cfg) but I'd still rather use LILO. And the GRUB most distros use, festooned with complex scripts is definitely a nono.
One of the many thing I like about Slackware is that it still uses LILO (or at any rate gives you the choice of using it). As I use native UEFI now, my bootloader is ELILO but it still has the same reassuringly familiar interface. What's wrong with sticking to what you know and like?
KDE4 also just works. So, there is no reason to pay much attention to KDE5.
If you don't like the way Slackware is run or the packages it does or doesn't include, you are more than welcome to switch to another distro more to your liking. Bellyaching to people who like Slackware and what it is and does is highly unlikely to win you any points. Really, it comes down to what works for you versus what works for us. No one here is going to tell you what you should run on your machine(s). We run Slackware on our machines and love it, and make no apologies for loving it.
As I see it, Slackware is a classical distro (similar to classical music) in that it sticks to what works. Classical music will always have a devoted fan base, as will (I suspect) Slackware for the foreseeable future. Slackware owns this status for 3 distinct reasons:
It still uses an ncurses-style installer;
It still uses LILO; and
It still uses BSD-style init scripts. As an added bonus:
I like the installer, I am fond of lilo and I am more than happy with the init scripts. The package management may get a little bit tough sometimes, but I value the flexibility and freedom it grants me.
So, yes. I love Slackware and that's why I use it.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
