SoylentNews is people
SoylentNews
from the 640k-is-more-memory-than-anyone-will-ever-need dept.
Linux x86/x86_64 Will Now Always Reserve The First 1MB Of RAM - Phoronix:
The Linux x86/x86_64 kernel code already had logic in place for reserving portions of the first 1MB of RAM to avoid the BIOS or kernel potentially clobbering that space among other reasons while now Linux 5.13 is doing away with that "wankery" and will just unconditionally always reserve the first 1MB of RAM.
[...] The motivation now for Linux 5.13 in getting that 1MB unconditional reservation in place for Linux x86/x86_64 stems from a bug report around an AMD Ryzen system being unbootable on Linux 5.13 since the change to consolidate their early memory reservations handling. Just unconditionally doing the first 1MB makes things much simpler to handle.
The change was sent in this morning as part of x86/urgent. "Do away with all the wankery of reserving X amount of memory in the first megabyte to prevent BIOS corrupting it and simply and unconditionally reserve the whole first megabyte."
no more wankery
(Score: 2) by RS3 on Monday June 07 2021, @04:14PM (2 children)
Thank you. I wasn't aware of musl. I've only installed Alpine and its apps, and was completely unaware of (ignorant of) musl. It looks very interesting, and may be why Alpine is so stable and efficient... I'll have to study it some more.
So do you have problems when installing 3rd-party applications (which were compiled against whatever the standard glibc is)?
Alpine comes with xen- could you use Alpine as your hypervisor + server and install another distro as guest vm for your glibc apps?
(Score: 1, Interesting) by Anonymous Coward on Tuesday June 08 2021, @01:38AM (1 child)
Yes, there can be problems using a libc that the person didn't test against. Most people use glibc but usually stick to the standard, which means that problems don't happen even if they switch to another. However within the libc arena, you have behaviors that are not dictated by the specification and developers may expect the behavior they got in testing. There are also things that musl doesn't implement or does erroneously that can also cause problems. Additionally, there are things that glibc, the most common libc, does wrong but developers may also wrongly depend on that behavior without realizing it is technically a bug in glibc.
There are ways around it. You can statically compile, using virtualization, using a compatibility layer, root separation or sandboxing, compiling it yourself, fixing the problematic code, and probably more that don't immediately come to mind. But not all of those are options in every situation; and not all are a solution in every situation, And others require extra work on top of using Alpine that can be fixed in the same or less work by not using Alpine in the first place as your distro.
As I said, we'd love to love alpine, but having been "fooled" before we are not looking forward to being fooled again because then it is our fault.
(Score: 2) by RS3 on Wednesday June 09 2021, @02:43AM
Thank you so much. Very interesting perspective. It's interesting that you feel "fooled". I've found Alpine to be so good, stable, fast, efficient, that for me, it's the standard of excellence. But I understand what you mean. It's certainly a learning (eye-opening) experience.
Again, I have not tried to run any apps outside of what you can get from Alpine.
But I've had your problem with many applications for many distros, and I'm trying to think about what I've done with other distros. I think I usually get the distro-specific apps. If I need something that isn't available for the OS platform, I've probably gotten source and compiled. But that doesn't always work, and although I've done some SW development, I usually don't have the patience to figure it out and fix it. All depends on what the bug is, of course.