Unnecessary or not is very debatable in this case, all those extra read and write have a very real benefit, the question is if it’s worth it to you or not.
And yes, it has the downside of temporarily using more disk space, but if there’s enough can be checked since how much space a package takes once installed can be known in advance and once the update is done, it doesn’t use any extra space anymore.
That process could also be made optional for those who don’t want the extra safety, it’s the great thing about linux, how configurable it is.
I guess the issue was the lack of notification about what that daemon was doing then, since you’d assume the GUI would be aware its own daemon is still busy once I launched it the 2nd time.
You have to put in some effort, yes, but reading everything is not realistic. I don’t think I’ve ever read a manual from cover to cover in my entire life and that wouldn’t include the entire knowledge base of that product users either.
Even if I had read everything before using it, I would have forgotten most of it.
I’ve been using linux to some degree for about 3 decades now so I know a fair bit, but there’s also a lot I don’t know as well.
Does proprietary UNIX have a GUI? I didn’t even know it still existed, but with companies behavior, it’s not that surprising I guess.
I feel linux has evolved to become more than simply what its root was though.
I picked manjaro for my desktop because I’ve been using it as a secondary server for apps that are problematic to install on my freebsd server for a few years now and I liked it the best out of all the different distro I’ve tried over the years.
I don’t quite fit in everything your thread says, but close enough, nothing is perfect in life.
So far I still don’t regret that choice, I was expecting issues since it is linux, but this problem behavior I really did not expect out of a product this mature(but I covered that in length already).
It depends on whether it’s installed on a workstation or on a server. I’m not sure whether HP/UX is used on workstations — Tru64 (formerly DEC Unix and Compaq Unix) was, but Hewlett-Packard killed it off in favor of HP/UX. The main reason was that True64 was BSD-based, while HP/UX is System-V-based.
Then there is IBM’s AIX, which exists in both workstation and server versions, but it’s primarily being used in the latter style now, as IBM lost interest in the desktop and simply recommends GNU/Linux for that role.
SGI IRIX was a desktop-oriented System V Unix from Silicon Graphics, and it also existed as a server version, but it has been discontinued in favor of GNU/Linux.
The desktop workstation versions of the above all came with CDE as their desktop environment.
Oracle Solaris — originally created by Sun Microsystems, which was sold to Oracle — does come with a graphical user interface for workstations. As the matter of fact, they use GNOME as their GUI.
The thing with the proprietary UNIX versions is that they are mostly bound to proprietary hardware designs which themselves are too expensive for the masses and therefore restricted to corporate environments.
GNU/Linux has begun supplanting some of them already — it’s the only operating system on the planet that supports all 32-bit and 64-bit hardware architectures — but some of those systems are still around because there are companies and services depending on them. You have to keep in mind that these are machines that never get rebooted — think: mainframes, et al. They stay up 24/7.
But what you seem to fail to grasp is that this is not an actual problem with GNU/Linux or even with Arch/Manjaro. It’s a user problem.
I misspoke, I meant the deleting of those boot file(the behavior of the updating relating to my problem), not the problem I created for myself.
I did expect problems from an interrupted update so I wasn’t surprised I broke my system when I realized that’s what had happened. Pamac is not reliable, lesson learned.
I did not expect it would be normal behavior to render the system unbootable for longer than replacing a file takes as part of the standard update process.
But that’s just it: it is not just the replacement of a file.
The vmlinuz and initramfs must be created on your local system — they do not come from the repositories — based upon all of the driver modules installed on your system, and what your system needs in terms of those driver modules. That’s what the autodetect and (to some extent) systemd hooks in mkinitcpio.conf are for — at least, on account of the initramfs, because a vmlinuz must also be created for every kernel you have, from the vmlinux files, which are the actual runtime kernel images before compression.
Another thing to keep in mind are the microcode files. So the update process has to clean out /boot first in order to make sure that everything gets properly installed and files no longer needed are removed. That is why the cleaning of /boot happens at the start of the update process — note: after all packages have been downloaded first — and the recreation of the correct entries in /boot comes last, before the boot loader itself is then updated to point at the correct kernels and initramfs.
Anyway, as I said, if you do not like the way this works — and it’s not pamac’s fault, because this is how pacman was designed to work by Arch — then please direct your feature requests and bug reports at the pacman maintainers over at Arch.
From the man page for pacman…
This is not anything Manjaro can change. And unless one interrupts the update process — which one is not supposed to do — then nobody should have any problem with it.
I’m aware, we covered this already. I was simply saying that was the amount of time I expected the system to be unbootable for. It was simply my expectation, nothing else.
My problem has been very well resolved(thanks everyone) so we’re just having a conversation now.
I am simply expressing my opinion on the way updating the stuff in that boot folder works, I know manjaro is not responsible for it and I don’t expect it to be changed which is why I said very early:
(I also complained about how much I hate the Discourse forum software, it just wiped my draft because of a 2nd popup I seemingly wrongly interpreted the wording of after I said to ignore another tabs change to the draft, which I had to open to search this thread for my quote since it wouldn’t keep the whole thread loaded even after scrolling through it all, sigh)
I haven’t heard anything that changed my mind about it being possible to make this safe. At the very least it could wipe the kernels and their matching files one at a time.
Doesn’t sound like it would be an easy fix though from how things were made to work as they currently do and there are much more important things to work on, but it is certainly not impossible to make it much safer.
It’s not just about making it idiot proof, it’s about reducing the time you waste dealing with or avoiding creating problems.
Indeed, the pamac issue is something entirely different. Its unawareness of what it was doing is what pushed me to create my own problem, since I assumed wrongly it would be better aware of it.
It is a fairly common thing because of how modular linux is so I should have known better, but linux as come such a long way that I got my expectations too high.
