It is quite possible that I am missing something big here, but I don’t see the point of “kernel managers”. Just install the kernel. On EndeavourOS we have nice pacman post-transaction hooks that update the grub, it’s all very nice and simple.
Yeah, but it’s the same for any package. How would such a user even install this “kernel manager”?
If he is comfortable running:
sudo pacman -S akm
to install a program that installs kernels, why wouldn’t he be comfortable running
sudo pacman -S linux-lts linux-lts-headers
to install a kernel?
It’s the same thing, except the former requires one additional step!
Besides, “kernel managers” require maintenance, and can break or not work properly (either due to some dependency update, or due to user’s carelessness). Isn’t it a hundred times more difficult to troubleshoot on a newbie’s computer this “kernel manager” than to explain to him how to install a kernel?
It is all about how the individual prefers to consume information.
Personally, I agree with you. I would never want a tool like akm.
However, many people prefer to consume information via a gui and akm provides a simple way to see the kernels and some info about the kernels. Then you can remove or add them via point and click.
I get that there is such a preference, but why not then have a manager for every thematic class of packages imaginable? Why not, for example, have an “office suite manager”, where the user can pick LibreOffice or OpenOffice or Calligra, or whatever other office suite exists in the repos? Why not have a “text editor manager” with checkboxes for every text editor in the repos? A “drawing program manager”? Does it not sound absurd when you think about it that way?
But then, what makes kernels such a special class of packages that they need their own manager?
As a matter of fact, one installs kernels much less frequently than most user applications, so if anything, they are some of the packages that deserve the least their own special manager application…
True True but one decides to create that app and is maintaining it.
I am not a fan of such too, but as I mentioned it is about freedom of choice.
In my first years on Arch I loved GUI helper apps a lot, not because i was not able to use commandline tools more because i was simple thinking everything should be a GUI and not a command to type.
After getting used to commandline usage i feel much more in control of what exactly i am doing … like directly open the engine and using tools to repair and change stuff.
And i agree that these helper GUIs are helpers to get into something and not all are what should be the default choice.
Sam for simple-mirrors application … i do love it for the ease of use, it comes in handy for myself and also for helping users, but in the end if you know how it works you can just create an alias or a timer or what ever fits your needs. And it shows a lot from inside the engine like the command it creates and the list that comes out… what makes it a softlanding into mirror ranking procedure.
I appreciate and use the information function of akm. I would only use the command line to (un)install kernels (or any software), but having version numbers etc. at a glance is useful to me.
I don’t see any issue with having akm. First of all the user has to install it to use it so they are already making that first choice whether they want it or not. It’s not up to me to decide what they do or don’t do. It’s about freedom of choice. Don’t make me go Stallman here!
But why not have an “office suite manager”, a “text editor manager”, etc? See my post above.
What makes kernel packages so special to deserve their own manager?
If the user has to install if first, then what’s the point of it? Why not just install the kernel? If it were available by default, I’d somewhat understand it (but I’d complain about bloat): it’s there for people who don’t know how to use pacman but need a different kernel (a rather small subset of people, but okay )… But if you need to use pacman to install it, then you have already passed the test of being able to install a kernel.