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.
I prefer pkgdiff.
explodepkg, installpkg, makepkg are a combination of verb applied to a single package.
pkgtools, pkgdiff are applied to multiple packages.
Your pedantry may vary
I didn't pretend you said that. I am just saying that it is simpler for most users to be just proposed one tool, but also that I just make a suggestion and am open for discussion.
That's commendable, maybe you could explain the reason behind suggesting a replacement for all users rather than addition for most users, then.
Because it happens to be the one and only point I was trying to make, before you addressed two points I did not make.
This post seems relevant, maybe you could explain it to him, also.
While learning curve challenges are good for us, really all I wanted to do was to start my computer, not fight with alligators.
But, but fighting hungry alligators is so fun!
Honestly, the good side of GRUB is that it can be well automated via scripts.
For example, when you want the package managers to update the boot, like you guys expect from SLACKPKG, the GRUB usage will result in a safer design, thought...
Last edited by Darth Vader; 04-12-2018 at 03:47 AM.
I didn't pretend you said that. I am just saying that it is simpler for most users to be just proposed one tool, but also that I just make a suggestion and am open for discussion.
I'm actually with Didier on using Grub2 rather than lilo/elilo, and it's a good reason...
Grub can target a single disk better for bootloader setup than lilo and elilo can which spams the first main drive in the system /dev/sda or /dev/hda with the bootloader install. Grub can be more easily tuned to target /dev/sdb or any other selected disk in the system to be the bootloader install point of choice for Grub which means if you have Windows installed on /dev/sda and wish to keep the bootloader intact for ntldr, it stays intact which /dev/sdb which would be your Slackware install, would have Grub all to itself.
The argument about Reiser4 is a moot point. Unless I missed the memo, Slackware by default does not support Reiser4, much less does any modern distribution, due to ethics and politics surrounding Hans Reiser.
It would be more work to redraft the script to create the "/boot/grub" directory, run "grub-mkconfig -o /boot/grub/grub.cfg" and then setup "grub-install /dev/sdX" to target the correct disk, but in terms of the bootloader not interfering with other systems, it's a better choice. Sometimes the better choice isn't always the KISS choice. LILO/ELILO can still be offered, just not as the default.
Reaper, you should post more often. I'm certain you know a lot more about this particular subject than D.S.
I use grub loader for 11 years now, but I don't want the prober and configurator, so I will have to fork and rip the installer if it tries to write without permission.
Not that I care about it too much, it's not the first thing I've forked, and not the last either.
I for one, I will not touch this filesystem even it comes with human-level Artificial Intelligence, after learning about the particular way of Hans Reiser understanding of the sense of word "divorce".
That's commendable, maybe you could explain the reason behind suggesting a replacement for all users rather than addition for most users, then.
Well, basically what I propose is to at least offer the choice of using GRUB instead or elilo or lilo at the CONFIGURE step of installation. If lilo and|or elilo are still offered in case the user denied using GRUB, that's fine with me, even though I would see that more like a transitional measure, in case the user had already used lilo or elilo on the same box.
To be clear I never suggested to drop lilo or elilo from Slackware. Additionally it's not difficult for a user acquainted with Slackware to run one of them after installation and before rebooting.
Quote:
This post seems relevant, maybe you could explain it to him, also.
Well let's quote the linked post in full:
Quote:
Grub is a crummy piece of software with a steep learning curve.
While learning curve challenges are good for us, really all I wanted to do
was to start my computer, not fight with alligators.
Relegating Grub to the dustbin would give many of us a feeling of satisfaction.
It is nice that there are alternatives for those who don't like Grub.
I usually don't answer posts that don't bring technical arguments, just feelings. I only agree about the learning curve. But that's fine with me, as I like to learn. This reminds me all the people who said that UEFI was just crap or crummy, who didn't dare to read at least the not too technical parts of the specification.
Anyway I will just point readers to this page from Rod Smith, as if I don't really know what I am speaking about (which I am ready to admit), he does.
Last edited by Didier Spaier; 04-12-2018 at 04:57 AM.
For example, when you want the package managers to update the boot, like you guys expect from SLACKPKG, the GRUB usage will result in a safer design, thought...
That's exactly what leaded me to have a better look to it, as it could be used e.g. after a kernel upgrade provided as a security fix in most cases.
Well, basically what I propose is to at least offer the choice of using GRUB instead or elilo or lilo at the CONFIGURE step of installation. If lilo and|or elilo are still offered in case the user denied using GRUB, that's fine with me, even though I would see that more like a transitional measure, in case the user had already used lilo or elilo on the same box.
To be clear I never suggested to drop lilo or elilo from Slackware. Additionally it's not difficult for a user acquainted with Slackware to run one of them after installation and before rebooting.
Well you did refer to it as "this replacement" here.
Guess it's just semantics then, if you have no problem with presenting a choice I have no problem with your installer, it really is as simple as that.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
